Building Quality by Starting at the Source
Contemporary approaches to source management extend beyond the warehousing and versioning of code. This article argues for viewing Continuous Integration, Continuous Delivery, Continuous Testing and even Continuous Quality as inseparable from ‘source code management’. While such pipeline automation provides a solid foundation for quality, it is not itself the primary guarantor of code quality. Much like how Agile/Scrum advances a culture of change enablement, replete with ceremonies and a cadence around those ceremonies, this document advances critical ceremonies, practices and cadence that drive a culture of code quality.
To that end, this article advances recommendations around automation practices and the code quality ceremony of the Pull Request Review (or ‘PR Review’) that we term the ‘Continuous Gitflow’ model. The Continuous Gitflow model is our baseline recommended best practices for projects, though it can be adapted and revised based on existing client source management practices. This model leverages the Vincent Driessen Gitflow model as the backbone for these automation practices and ceremonies. However, our use of this model should not be taken as central to the recommended best practices. Other source management and flow models can be ‘swapped in’ — the critical concern is the use of automation and the defining of a regular, recurring quality ceremony (e.g. a review) as part of the source code management. As such, this article will focus around defining guidance around CI/CD/CT instrumentation, as well as a formal quality ceremony: the Pull Request Review.
This series of articles is not a series on DevOps, so how to tool and instrument these checks will not be a point of concern. The concern is not to advance a particularly nuanced view of DevOps, rather to present a unification of source management, CI/CD/CT and quality -centric ceremonies.
‘Continuous Gitflow’ Defined
Continuous Gitflow is simply a mobile-adapted Gitflow process leveraging mobile Continuous Integration, Continuous Delivery and Continuous Test instrumentation. In a nutshell, the Gitflow model entails the creation and management of 5 core types of branches within a Git repository. These are:
Master: The primary branch-of-record for deployed code. Code at the HEAD of the master branch should be a snapshot of what is currently in production. If the gitflow model is properly implemented and maintained, this code should be already tested and deploy-ready. Each successive merge to Master represents a production release.
Develop: This is the primary branch-of-record for developing code. Develop represents the current state of developed code, and HEAD should contain all features ready for demonstration to the client stakeholders and/or product owners.
Feature(s): Feature branches are created by checking out the HEAD of develop. A Feature branch is a workspace for the collaborative/iterative development of a feature. This is often a unit of work achieved over many days by a particular developer, however it is not uncommon for multiple developers to work on a feature in parallel. Multiple features may be under development at a particular time, resulting in multiple feature branches. Work is typically merged back into develop as a feature reaches completion. In the Continuous Gitflow model, all merges into develop must be accomplished via a ‘Pull Request’ (or ‘PR’). The PR Review process will be discussed at length here and throughout this document.
Release: Release branches stand between Develop and Master. Even in the case of a mature CI/CD pipeline, consumer store deployment of mobile apps (for example) is a complex and lengthy process that constitutes a significant investment of time and money. Continuing from the mobile perspective, contemporary mobile applications often encapsulate sophisticated, deeply interrelated flows that may take the user through many sequences of rich screens. Given these factors, in order to achieve a seamless app store deployment, it is typically necessary to stabilize and regress a deployment version. This is done by creating a new release branch from the Develop branch, and iterating through successive stabilizing commits. Once a release branch is deemed production ready, it is deployed and merged to Master.
Hotfix: We largely leave this branch undiscussed, as deployment of critical patches and fixes is largely determined by business, product and technology context. In the original Driessen model, Hotfix branches are drawn from Master, critical fixes are iterated and tested, and then the code is merged back to both Develop and Master once deployed.
Basic CI/CD/CT Gates
Using the existing gitflow model, we achieve ‘continuous gitflow’ by instrumenting CI, CD and CT actions triggered by branch commits. Again, this is not a DevOps article, but rather looking to define regular processes and expectations around source management that reinforce quality concerns. As such, we will keep this instrumentation simple.
“This series of articles is not a series on DevOps, so how to tool and instrument these checks will not be a point of concern. The concern is not to advance a particularly nuanced view of DevOps, rather to present a unification of source management, CI/CD/CT and quality -centric ceremonies.”
Feature(s): The CI/CD/CT pipeline for Feature branches should be set up to execute upon every check-in. This pipeline compiles the code, runs Static analysis tools, runs Unit Tests (for CT) and passes only if ALL steps were successful. Errors at any stage will be captured in the pipeline logs with specific information on why and where the failure occurred. A PR can be submitted to merge a Feature branch to Develop only if the pipeline builds successfully, thus installing an automated quality check at the feature level.
Develop: The CI/CD/CT pipeline for the Develop branch works similar to the Feature branch pipeline. Any code check-in or PR merged to the Develop branch will trigger a build including execution of Unit Tests (CT) and Static Analysis tools. Additionally, upon successful build, the pipeline should be configured to deploy the application to an internal app store and notify all the stakeholders (i.e. Scrum team, Product Owner, Client QA team, etc.). It is recommended that the Develop pipelines may be scheduled to run automated UI tests at regular intervals (e.g., nightly) to capture any issues after PR merges, enhancing CT quality checks.
Release: Release branch pipelines run on Beta versions of the code. These should include stringent code inspection configuration rules to highlight any warnings that may have sneaked past the Develop pipelines. The Release branch pipeline must include execution of Unit Tests, Static analysis tools and automated UI tests. This pipeline must focus on continuous regression and should be executed on as many device configurations as possible. A regular scheduled execution of this pipeline is strongly recommended.
Master: Master branch pipelines run on code that has already been submitted to App Stores and hence the goal of these is to pre-emptively capture any issues in Production code. These pipelines should include all stages and must be executed at regular intervals. In the mobile context, this becomes especially salient when there are updates to the backend systems or updates to the APIs consumed by the app versions already available on App Stores.
Using Native Mobile app development as a reference point to put it all together, the ‘Grand Unified Picture’ looks something like this:
Adding Ceremony and Cadence:
As we discussed in our previous article that defined a ‘culture of quality’, we do not take such a culture as ‘just’ people, tools and processes, but also as a shared experience focused around the concern of quality software. Critical in that effort is understanding how a cadence of rituals can create a shared experience. Just as Agile’s cadence of ceremonies (scrums, grooming, planning, etc) helps foster a culture centered around communication and adapting to change, we seek to establish a cadence of ceremonies centered around quality.
In service of that, an enhancement of the Driessen Gitflow model is the formalization and enforcement of a Pull Request (“PR”) review process into a formal, open quality ceremony that happens at a regular cadence. At a minimum, a thorough, open and collaborative review of code prior to its submission to the develop branch is critical as a quality control measure. The PR Review ceremony will be discussed more thoroughly in our next article in this series, however some key attributes of a successful PR process are relevant here. First, PRs must never be approved by the programmer issuing the PR. PRs ideally should be reviewed by the platform Lead Developer, and a successful (reviewed-and-approved) PR should conform to documented standards that include testing, architecture, code quality and documentation. Secondly, PR Reviews should be formal. The reviewer and developer must meet and follow an established set of procedures. Third, PR reviews must be open and communicative, meaning that other members of the scrum team should attend as needed, and the reviewer and developer must be open to an exchange of concerns about the code.
PR Reviews should not be about correcting or professionally reviewing developers. The reviewer and developer must take a collaborative approach that seeks to answer the question — “How can we improve this code so it better reflects our defined standards of quality”.
The next installment in our sequence will expand on the notion of code quality ceremonies. We’ll look at how to structure code-quality ceremonies around the Agile cadence, such as lunch-and-learns and code quality retrospectives.
About The Author
Davin Lafon currently serves as director of ProKarma’s Digital Integration practice, which enables large-scale transformation by bringing together data from across the digital sphere. Davin, whose expertise includes mobility, strategy and enterprise architecture, began his career as an artificial intelligence research engineer at Carnegie Mellon. He went on to found a consulting firm in the mobility space, where he helped Fortune 100 companies and privately held financial sector organizations set mobility strategy and develop their enterprise architecture.
At ProKarma, Davin helps Fortune 500 clients navigate digital transformation and re-engineer themselves through powerful digital platforms, customer engagement and emerging technology. Read more from the ProKarma team on our blog, or connect with us for additional information on our service offerings.
References and Footnotes
 For particularly complex features, the platform lead may request developers merge their code ‘back’ to develop in numerous small, functional chunks — even prior to feature completion.