The art and magic of manual deployment

Well... I promised myself that I would write a post on this blog at least once per week. I actually tried but always halted on the one question: "Uhm - what to write about - I've only got some 16 hours remaining..."

What is the purpose of such a goal if you have to dig deep to find something remotely interesting to write about? I therefore announce that I will only be writing whenever I feel like it. Heck, nobody of you guys (all three: You, my mom and my parent's dog - I haven't got a clue how many people are actually reading this) even knew that I made a promise to begin with but it sounds pretty good, right? ;o)

I have went from a complete newbie in my new job to actually being able to deliver some kind of work. Slowly I have begun moving tasks from the "Sprint backlog" to the "In progress" and actually some of them have moved to the "Finished" part of the whiteboard without being moved back a few hours later. It feels good to participate in getting a job done. We're releasing March 25 and have loads to do - I haven't got the time to write this but the second option was benchmarking on various Danish newspapers for news I couldn't care less about anyway.

The reason for choosing Option #1 was that yesterday I suddenly realized how much time we spend deploying stuff to our staging enviroment. Everything is done manually so if you have changes in 4 files and you added a new Usercontrol and included a new Javascript file to the solution you will have to _manually_ (yes, manually) find all files and upload them to the staging server. That is as crappy as it can possibly be. Where do we get these files? From the developer's machine, what else? Yes, my boys, everything is left to the man behind the machine with the largest possible margin for human errors to occur. And of course we have no backlog of uploaded files on the staging server so if you accidently overwrite the wrong file with one that will break the stagingserver's build you leave your users f***ed until you correct the error (that is: restore a backup from your own machine or call the server maintenance guy to restore the file for you from yesterdays backup because you haven't got a working backup locally. Yeeeehaaaaaaa!!!).

I have read a bit about how we can use our Continuous Integration enviroment to deliver a clean build for every checkin to be able to make revised deployments. My thoughts are to build the scripts neccessary to let the buildserver create a fully deployable package for every checkin which will enable us to synchronize i.e. revision 1447 of the codebase (stored in it's own folder) with the content on the staging server using robocopy. I have no experience on creating scripts apart from reading on various blogs about related issues but I promise to write a few follow-ups on the matter as we get along. Until then I will be stuck with issues such as deploying files from my machine which I acciddently forgot to check in.... There's nothing but work to do here, I suppose ;o)