Effective Version Control

Application development managers and leads should pay attention to how the following practices on their teams can ensure complete control over their development artifacts.  This is not meant as an exhaustive list, but rather as a base framework for version control on a typical development team.

Source Code
One of the most fundamental items in the development team is the source code.  Senior team members should ensure all source code is under version control (leading junior members by example and coaching).  Source code includes the implementation; unit tests; acceptance and regression tests; and all associated files, libraries, and configuration running within the component.

Legacy or Existing Systems
Many teams inherit or obtain existing systems.  The first activity a team should perform is to version control all components of the system and ensure they are able to reproduce that system in a non-production environment.  An unfortunate common issue with existing systems is only binary or executable versions of the implementation exist, and therefore, these artifacts must be version controlled and managed without merges.

Installations and Tools
Version control does not stop with source code.  All tools and components used to produce the source code should be version controlled as well.  Frameworks, libraries, and tools come and go, and a legacy system still needs to be built and packaged well into its lifetime.  Ensure your team does not rely on a vendor to provide tools n number of years into your system's maintenance period.  Risk is managed by your organization, and that risk may very well be accepted after your vendor's support has ended.

Branches
A goal of the development team should be to minimize the use of branches in version control.  A single active development line is much easier to manage than multiple lists of feature, patch, task, and release branches.  As it is not always possible to work directly from a single branch (for technology, schedule, or product version reasons), the team should ensure branches are introduced only for a defined list of reasons (including parallel efforts). 

Issues associated with branching strategies include merge conflicts, changes in schedule for features (feature A is built into branch A, but a schedule change needs the feature in branch B), and other external changes not planned for.

Development Lifecycle
Agile teams have an increasing need for simple and automated development.  Version control systems can be used in the automation of development practices.  Teams transitioning from one development methodology or framework to another should consider the implications on their version control strategies.

Executables
Executable components (latest build, historical builds) should not be version controlled with the implementation.  Issues with keeping the source synchronized with the built components and ease in retrieving specific builds will interfere with the team's effectiveness.  Consider labeling or marking the source at build time, and then either storing the build in a separate area under version control or storing on a build server file system (recommend the file system to your team as the source can always be re-built from the label later if needed).

Configuration Management, Build, & Packaging
As mentioned earlier, all tools used in producing the components should be version controlled.  Specifically, configuration management tools and scripts may contain their own configuration as well.  For example, a continuous integration server may need to be configured to call out to a custom build script.  The configuration of that integration server as well as the custom build script should be version controlled.  The installation package of that integration server should also be version controlled. 

Depending on size and industry, organizations may have third-party groups or units performing configuration or build management.  The development team should ensure that their components' entire value stream is under control and can be reproduced in a non-production environment.

Supporting Documentation
Documentation for the system development as well as release and training should be readily available and reproducible.  Determine the right level of needed documentation, and implement a way to keep versions of that documentation in sync with your application components.  Documents can be stored in the same system as the implementation or in other knowledge bases (depending on your unique requirements with compliance and traceability).


Once your team uses these practices, further practices can follow such as lower-level control of infrastructure and environment configuration, improvements in automation and delivery, tier-specific enhancements and innovations.  Evolving your lifecycle, processes, and value stream should be a continuous process.