I earlier mentioned my software deployment goal: Boring Is Good! Over several posts I will cover some of the things that can help accomplish that goal, starting with the very basics.
Basic practice number one, coming up!
Use Source Control
This one seems obvious to many developers but not to all, especially as we change the discussion from standard (Java, c#) code into database schemas and into other technologies where development is done via point-and-click rather than writing code. There’s often a “publish” button in the Integrated Development Tool that looks so tempting…and it’s great for local testing and for small projects, which is what it was intended for. But for larger projects, the first rule is unbreakable: other than on your own machine, the deployment process begins in the source code library. Nothing goes to production that didn’t originate there. That means nothing!
“Do you really mean that if Brad, our technical writer, needs to update our release notes (a .pdf file), he has to email it to someone who can check it into source control before you will deploy it? Isn’t deployment in this case just a file copy to a web server?”
Yes, in this case a file copy to our web servers would work. But it has to come from our code library. If the best we can do is have Brad email you the file so you can check it in, OK, but much better would be to give Brad access to the library and have him check in the source documents he works with. We’ll generate the .pdf file and take it from there.
Note that for some really large operations, specialized source libraries may be in order—one to handle images, or documents, or other non-textual “source” objects.
OK, As I said, this I said, this one was really basic. But even in shops where most stuff was under source control I’ve still found that some portions of the software are not. See if you can find it in your own organization…you might be surprised!