Code Management is usually a mess. Each developer operates a single branch in isolation, which does not include automated or peer-testing. At some point in time the many branches are joined into one ‘trunk’, and the code is assembled, packaged, tested and deployed. Once the build enters production load, stress, concurrency and UAT both automated and manual testing, is performed. Errors are discovered and the entire version is rolled back. An investigation is undertaken to find the source code responsible. It is fixed, redeployed, the testing process begins anew and we hope that there are no more errors with the final build. Everyone hates code deployment and deploying a new version.
The usual chaotic process of code mis-management is devastating in its impracticability, error-ridden deployments, and the ever-rising attendant costs.
Enter the DevOps method of code management of the use of a Single Trunk. Code quality, security and build frequency are vastly improved. No longer will engineers fear deployment day.
1 ) Trunk Requirements
The main requirements to use a Trunk are the following:
- Deploying the same way to every environment: By using the same deployment mechanism for every environment (e.g., development, test, and production), our production deployments are likely to be far more successful, since we know that it has been successfully performed many times already earlier in the pipeline.
- Smoke testing the deployments: During the deployment process, test that we can connect to any supporting systems (e.g., databases, message buses, external services) and run a single test transaction through the system to ensure that our system is performing as designed. If any of these tests fail, we should fail the deployment.
- Ensure we maintain consistent environments: Create a single-step environment build process so that the development, test, and production environments have a common build mechanism. We must continually ensure that these environments remain synchronized. Of course, when any problems occur during deployment we swarm the problem until the problem is resolved, just as we do when our deployment pipeline fails in any of the earlier steps.
- Build: Our deployment pipeline must create packages from version control that can be deployed to any environment, including production.
- Test: Anyone should be able to run any or all of the automated test suite on their workstation or on our test systems.
- Deploy: Anybody should be able to deploy these packages to any environment where they have access, executed by running scripts that are also checked in to version control.
These are the practices that enable deployments to be performed successfully, regardless of who is performing the deployment. This build process should be automated through CI/CD (continuous integration and deployment) tools.
2 ) Embrace the Trunk
Having a single trunk-based development is a large cultural and mental change for developers. It does guarantee however, higher throughput, code stability and lower error rates (especially if unit and code testing is automated for the entire code build process). The Trunk is a vital part of the Continuous Integration (CI) process which automates the building of code (eg. Jenkins-Chef, Jenkins-Puppet, Jenkins-Opsworks). CI is a must to reduce the risks of version deployments. Within the CI process the engineer will use a local branch, push the code to a central branch and via a ‘Pull’ process merge the code into the trunk, only after it has been tested and passed. An example for Github is given below.
3 ) Git hub CI example
GitHub Flow is composed of five steps:
- To work on new code an engineer creates a unique named branch off of master (e.g., “new-oauth2-scopes”).
- The engineer commits to that branch locally, regularly pushing their work to the same named branch on the server.
- When they need feedback or help, or when they think the branch is ready for merging, they open a pull request.
- When they get their desired reviews and get any necessary approvals of the feature, the engineer can then merge it into master.
- Once the code changes are merged and pushed to master, the engineer deploys them into production.
Within this process we will automate unit, code and functional testing, using open source tools (eg S Unit tools, Apache see here), or commercial products from HP and other vendors – SaaS based it is hoped.
In the above example, we can create a platform that provides a shared version control repository with pre-blessed security libraries, a deployment pipeline that automatically runs code quality and security scanning tools, which deploys our applications into known, good environments that already have production monitoring tools installed on them. Ideally, we make life so much easier for Dev teams that they will overwhelmingly decide that using the common Trunk platform is the easiest, safest, and most secure means to get their applications into production.
4 ) Code Reviews within the Trunk process
Automated unit, code, syntax, functional test cases, non-functional test-cases are a must. The more testing and code review is automated the better. The more eyeballs that review the code, the better. Code reviews can be implemented in various forms.
Pair programming: programmers work in pairs. One developer looks over the author’s shoulder as the latter walks through the code.
Email pass-around: A source code management system emails code to reviewers automatically after the code is checked in.
Tool-assisted code review: Authors and reviewers use specialized tools designed for peer code review (e.g., Gerrit, GitHub pull requests, etc.) or facilities provided by the source code repositories (e.g., GitHub, Mercurial, Subversion, as well as other platforms such as Gerrit, Atlassian Stash, and Atlassian Crucible).
Code reviews can facilitate increased code commits and production deployments, and support trunk-based deployment and continuous delivery at scale.
==END
The above are key insights from an important book, ‘The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations’ by Gene Kim, Jez Humble, Patrick Debois, John Willis, and John Allspaw (2016).