Moving to a version controlled build process requires the universal acceptance of key requirements that the development team must adhere to. If any member of the team ignores these requirements, the regime of versioning and its multitude of benefits will begin to break down.
These fundamentals include:
- Moving to a distributed development environment
- Strictly no sharing of workspaces; each developer must have their own development environment.
- Working daily with version control, for example Subversion (SVN).
- Packaging of releases or project builds into discrete versions. The team must commit to building functionally stable releases for both quality assurance and production environments.
Don't underestimate the commitment needed to drag a recalcitrant development team into a new way of working. It only takes one developer to break ranks for the project to quickly unravel. Make a plan and see it through to the end. Give your development team time to learn the tools they need. Be explicit about the code management strategies that you are putting in place. Start simple, and build confidence before attempting to take on more complex code management strategies.
Make sure your plan includes:
- A standard operating environment (SOE) for developers on your team
You don't have to dictate exactly what tools your developers will use for their work, but you do need to ensure they have all the essentials necessary to follow your code management policy. By minimising the number of critical tools you can build better depth of experience amongst your team.
- A robust version control solution
I thoroughly recommend Subversion (SVN). It's free, works on all operating systems, and is already integrated into just about every development set up.
- A clearly defined approach to versioning
Start simple. Get your development team use to version control. Don't start branching and merging until you are confident with the basics.
Related Blog Posts