I'm attending tekx, and while I'm taking notes in all the sessions with Evernote, I'll try to clean up and summarize my notes here as well. One of the session's I attended yesterday was Eli White's session on Code and Release management. It focused more on the techniques, policies, and practices to think about about and implement rather than the nitty-gritty howto details of each version control system. I found that very helpful because oftentimes its difficult to learn how effectively use version control especially as part of a team's workflow. Also, its clear now that distributed version control systems have a lot to offer, primarily, and this was my AHA! moment, because they do not impose any workflow on you. With a central subversion repository, all the developers on a project are forced to work in a certain way. With multiple repos, you could still setup a central repository for everyone to push changes to. However, everyone can also have their own repository which I think encourages them to commit and track local changes more frequently. With SVN, especially as you work on larger teams, its tempting to commit less frequently especially if you don't use branches at all.
- We're talking about managing daily workflow – editing, testing, and releasing
- Have to use version control, there's no way to get by without it.
- It's a core component, with same core concepts across different systems – checkout/commit/merge/concurrency
- Distributed is great when stuff will eventually be thrown away, ie for individual experimentation
- Policies – come up with general rules for your team.
- You need to find rules that fit how you work and how you release code balanced against how you support older code, if at all.
- Use of Tags/Branches/Trunk
- Trunk – contains core codebase
- Branches – used to segment into logical areas of responsibility (release/feature/programmer)
- Tags – mark a specific state of code, a release
- 3 main styles of branching
- Stage Branches
- new work is done against trunk
- branches for staging/production/etc
- when ready for testing, merge into staging
- when ready for live, merge into production
- fixes made into each branch eventually has to be made back into trunk, otherwise your changes may get deleted next time your merge from trunk to a branch
- difficult to do parallel work (multiple people working on multiple features that may not be released together)
- Feature Branches
- New work is done in its own branch. You never commit to trunk.
- Easier to do concurrent development.
- CON – branching might be difficult depending on your VCS. and you have to do a lot of merging.
- Release Branches
- all new work done on trunk
- create a branch for each version when ready for release
- easer maintenance and allows some parallel work
- little merging
- assumes that everyone is working towards a common goal / release
- Pushing code live
- Absolutely want to have a script – especially if you have a lot of servers. Use that exact same script to push changes to testing and staging.
- Have a way to roll it back – scripted and automated. If something fails, better to roll back and debug in another environment.
- Live SVN Checkout
- it works and its simple, so its a very common practice
- encourages conflicts, especially if some has been editing on live/production
- hard to automate and difficult to rollback
- SVN Export & Rsync
- use dcn export to make a copy of the code, use rsync to transfer changed files to live
- simple and easy to scale & automate
- export gets a copy without .svn directories
- rsync is not atomic so some hits might get partiallly updated codebase which is likely to break.
- Stage Branches