@eliw starts off laying down his street cred. He’ll be covering how to control the process of version control. As we’ve been going over the past week, use version control. The talk will be focusing on subversion as the technology but the talk will be dealing with the higher level concepts.
Basic Version Control Terminology

• commit/check-in
• branch
• tag
• trunk
• merge

Subversion thinks in terms of a directory structure. Projects are subdirectories of a repository. The mainline (trunk) is a subdirectory of the project. Branches and tags have parallel directories.

Your release management should come up with general rules that you apply.

• will you allow intermediate (non-working) checkins?
• where should you check code in?
• are there places that as less controlled?
• how does this flow into releases?
• what about tags vs branches vs trunks?

I’m not seeing a reason to allow intermediate (non-working) checkins, that seems like a recipe for disaster.

No matter what your style of management, your trunk should contain the ‘core’ codebase. Branches are uses to segment off areas of responsibility. Tags should only be used to mark a specific state of code, a release.

Different Branch methodologies (3 main styles)

• stage branches
• feature branches
• release branches

With stage branches, all work is commited against the trunk. When you’re ready for a release, you merge into staging then after testing, you merge into production. The catch with this strategy is bringing your changes back to trunk. No parallel work, old patches and room for error with this strategy. There is no way to patch old releases. This setup is about moving forward constantly which works for websites but if you have clients on different versions of an application, things will become a bit hairy. Forgetting to merge things back can cause errors.

With feature branches, all new work you are doing, is done in its own branch. You merge the branch back into trunk after you’ve tested it. Trunk then is tagged as needed for phases (for testing/QA,Releasing,etc). Parallel work and long scale work become easy. Downside is that you’re often creating branches (depends on your VCS), there is a lot of merging, no old patches and fixes are complicated.

So far my current release system seems to be a combination of stage and feature branching. I’ll tell you right now that it has been a pain in my ass. Hopefully the next strategy will be my…oh yeah, there is no magic bullet.

With release branches, all new work done on trunk and when ready for realease, creat a versional branch (/branches/v3.0). You can test against the branch and and make bug fixes against the branch. You then tag the branch with a versional tag for release. One of the big pros is that the maintenance work is easy. It is OK with long scale work. There’s some parallel work and very little merging. The only time you merge is when you do a bug fix on the branch, it has to be merged back to trunk. Cons include Branch/Tag creation. The biggie is that this assumes a single goal.

Options for pushing code live:

• have a script
• handle multiple machines
• use for all phases staging/testing
• have a rollback procedure
• multiple ways to accomplish
• incorporate everything together
  • Services, DB, PHP, etc

This is a great talk so far, I’m having a lot of great ideas for my release structure but something tells me that where I work now won’t let me put this in place. D=

Live check out of the server is very simple. Big drawback is conflicts, hard to automate & rollback. As of a year ago, facebook does this. Awesome, I’m doing something that’s facebook is doing so they’re having the same pain in the ass problems just mentioned before that I have had.

Another option is to export and rysnc. The export part is what I’m missing from what I currently do at work. Though I think if I can make a script for pushing, I might be able to cut out the live check out of my current procedure. You’ll have problems with partial updates with rsync. You might have web traffic while codebase is partially updated.

Solutions?

• take website offline
• use symlinks

Rolling back with rsync means you have to rsync again. Using symlinks means you just change the symlinks.

Overall, amazing session that helped out on some issues I was trying to work out recently. Tek has paid for itself twice over and it’s only halfway done!

Related articles by Zemanta

• Distributed Version Control is here to stay, baby (joelonsoftware.com)
• SVN or Git (wknight8111.blogspot.com)
• An Intro to Distributed Version Control (zef.me)