Beloved Impediments of Continuous Delivery

If we haven’t yet achieved Continuous Delivery (defined here as automated build and deployment of a build through environments to a ‘Staged’ environment for delivery to Production), we should identify any and all impediments.  At times, those impediments may be those things to which we hold to most firmly. 

There are aspects of software development which we hold firmly to due to habit, comfort, or affinity.  We may hold to some because they were advocated by a mentor in the past, part of an established ceremony, or even a well-documented principle or practice (implemented improperly or out of context).  Regardless, we should always be willing to reconsider them within well-established and supported Principles and Practices (as they were first defined by their authors).

Our session was intended to identify such “beloved impediments”.  We ventured off to any impediments, but still came away with a good list, along with Principles and Practices which, when implemented properly, address them, moving a team closer to successful Continuous Delivery.

 

 

1. Lack of User Test coverage:  The most beneficial practice for addressing this issue is Test-driven Development.  Most often the impediment to a team implementing TDD successfully is two-fold:  pressure to maintain velocity as a team develops proficiency in TDD, and development engineers’ initial sense and belief that taking more time to develop more test code than system code represents wasted time/effort.  There is enough material out there to address those concerns, such as “Clean Coder” by Bob Martin (“Uncle Bob”).
2. Manual Deployments:  The stellar book on continuous delivery, “Continuous Delivery” by Jez Humble and David Farley, makes it very clear it is necessary to make effort to automated absolutely everything (while accepting this may take time, and may never be fully achieved).  There are wise principles and practices on which Continuous Delivery is based.  Begin by following those principles and practices firmly.  Automate deployment steps in simple console scripts if that’s all that is available; don’t wait for someone to first set up a Deployment Server.
3. Manual Configurations:  Again, “Continuous Delivery” includes the principles and practices for addressing manual configuration of systems and environments.
4. Lack of Automated Function Test coverage:  Including only unit tests during development introduces high risk that after deployment to the first environment (often “Dev”), the automated functional tests will fail.  This can be addressed by practicing Comprehensive Test-driven Development, implementing both unit tests and functional tests during development, ensuring all are up to date before merging changes which will be automatically deployed on build success.
5. Poorly Pre-tested Builds:  Comprehensive Test-driven Development will address this, as both unit and integration tests will be executed on a developer’s local environment to ensure they all pass before submitting a merge request.  This does require automated functional testing be implemented in a way which is executable on local environments.
6. Merge Conflicts:  This issue is best addressed by truly following Continuous Integration (as opposed to just using a Continuous Integration tool).  True Continuous Integration is achieved by merging into the main (often the ‘develop’) branch often.  Ideally, when following TDD, this is done after every change following which all tests pass.  The fewer the code changes involved in each merge, the less chance of a merge conflict occurring – and when they do occur, the easier it is to find and address each.  Merging only after a given user story is developed will continue to result in frequent merge conflicts.
7. Environmental Disparities:  Following Continuous Delivery helps with the ‘Configuration’ part of this issue but fails to address the ‘Data’ part of the issue.  We didn’t address this during our session, but the best approach I have found for addressing this issue is implementation of Dynamic Test Data Providers in automated functional tests – this approach results in tests which will pass regardless of the state of the data in the environments.
8. Poorly Written User Stories:  This is another impediment we didn’t address during our session.  However, the session “Evaluating User Story Readiness” may prove helpful in this regard, ensuring that every user story is highly cohesive and test ready.
9. Development and Testing done in Isolation:  Having system development completed and merged separately from automated testing is addressed by practicing Comprehensive Test-driven Development along with Paired- (or Mob-) programming.
10. Merge Request Review/Approval:  Having to wait for code changes to be reviewed and approved by individuals who are already busy developing code for features may seem to be an unavoidable impediment to Continuous Delivery.  However, by practicing Paired- or Mob-programming, code review occurs along with code development.  This is an often over-looked acceleration resulting from this practice.

 

 

Craig A. Stockton | QA Automation Architect - Continuous Testing M 253.241.1598 | cstockto@TEKsystems.com 1601 5th Avenue, Suite #800, Seattle, WA 98101

TEKsystems. Experience the power of real partnership.

 

 

This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic mail or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply e-mail so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you