This article details what I believe is the best way to organize your source code libraries in a multi-developer organization. I do not cover how you need to organize your code within the project, the scope of this is the libraries and environments themselves and the development/release processes that use them. It is based on my own opinions, and what I have observed being done at many organizations. Almost every place I have worked at does this slightly differently, but I do believe that what I am about to lay out is a best practice based on my 30+ years of Software Development.
This is the basic arrangement of the Code Library / Environment relationship:
| Source Code Library | Usage | |
| Production | This is the final release version of the code. | |
| Staging / Integration | This is the environment that contains code that is considered a candidate for release. It is sometimes run in a “Model Office” or “Demo” environment, but the goal is to verify the code works perfectly just as it should in production. This is where Quality Assurance testing will occur. This environment should be very stable. | |
| Development | This is the base production environment and may contain unstable code. It is used by developers to verify that their new code works well with the codebase as a whole. |
Basic Organization Principals
These are the rules that I recommend:
- One library per environment, and pushes to that environment only originate from its associated library.
- Each development team/individual developer is responsible for promoting their own changes into the Staging / Integration library, and ensuring that only their changes are migrated.
- There should be a designated Release manager role that is responsible for managing the Staging / Integration and Production libraries. They give permission to migrate changes into these libraries, and are fully informed as to the contents of these changes.
- Promotion from the Staging / Integration to Production is managed, if not performed by the designated Release Manager role. This is performed after all quality checks in that environment have been passed and is always a complete merge so that Production is an exact copy of what has been tested.
- When the Staging/Integration library has been merged up into the Production library it should also be merged down into the development library. This insures that development is being performed against the production code.
- All work should be done on an individual branches and merged into the appropriate library when complete. Every developer should be working on their own branch so that they may check in at any time without disrupting the work of others. If multiple developers are working on a related feature and need to integrate with each other then there should be a feature level branch, and each developer branches off of that.
Summary
The primary goal should be to have one source code library for each deployment environment such that at any given moment that environment can be refreshed from its library. Release to production always originate from the Production library. Frequent downward merges through the libraries are encouraged in order to detect any merge issues early in the development process.
References
Traditional Development/Integration/Staging/Production Practice for Software Development
How To: Structure Your Source Control Folders in Team Foundation Server