How do you manage your code?
I have managed (or not managed) releasing code for as long as I have been writing it, and I must admit I hate it. SCM is a necessary evil, sort of like lawyers and taxes. I was a freelance for years, and my methodology for code releases involved creating a ZIP of the old code base before releasing the new and changed files to the production server. Definitely not ideal, but a workable solution if you are the only developer. Before undergoing a large set of changes I would make the equivalent of a branch by copying the directory targeted for slaughter off to a quiet corner of a hard drive for safe-keeping. I'd even religiously label these copies with the date and it wasn't long before I had a slew of folders with names like "someclientwebsite20001225". So every few months, I would start deleting these folders, and always had this haunting feeling that I had no clue what was in them anymore. I needed SCM back then, but always refused to do it.
Eventually I sought out and acquired gainful employment as a developer. Since then I have had the displeasure of experiencing CVS, VSS, Subversion and Perforce, and have researched just about every other product under the sun to varying degrees (no pun intended). The good news is, they all excel at keeping a revision history. They all excel at check in and out to keep teams from stepping on each others toes. They all support branching and tagging (some better than others of course).
So, how come none of them are any good at releasing a build?
How come I can label files in VSS, but have to use a third party tool or the command line to get the files tagged with those labels?
How come Subversion supports meta-data, but persists that meta-data on every version going forward?
How come Perforce will let me get a label, but insists on blowing it away when I get a second label? (At least there is a command line workaround for this one).
But really, why is this so freaking hard?
For a non-compiled application (like most web sites), this really sucks! You either have to release the whole banana every time, or strangle a subset of files out of the system via the command line.
For database code, it is even worse. Where I work we have 500+ stored procedures in the web-facing database. Should we drop and recreate every single one of them monthly? That's insane!
So enough of the ranting. We have a Dev -> Test -> UAT -> Production release cycle at work, and here's what we do:
- Each developer keeps a record of what they've worked on
- They promote code to Dev regularly throughout the month
- Developers apply labels to files when they are ready for Test
- Some poor sot (usually me), checks everyone's change list, looking for instances where files have multiple labels, and looking for changed files that didn't get their label
- Then the poor sot makes a release sandbox, grabs the labeled versions and promotes them to test (after checking that all the files got to the release sandbox)
- If we're extremely fortunate, the same sandbox makes its way to UAT
- If the planets are aligned in a straight line, the price of gas is below $3, and you can roll snake eyes 12 times in a row, the same sandbox goes to production
To aid me in this quest, I have a small arsenal of snippets that I will post in the near future.
What do the rest of you do?
3-10-2008
3-9-2008
3-7-2008
3-4-2008
3-4-2008