How to multiply your productivity, or why some fail to do so.
Many institutions believe that positive change can be achieved by a reorganization using modern terms like “value streams” and applying new practices and processes. Most companies can’t say when their transformation is complete and cannot quantify the benefits generated. When considering delivery velocity, these are the same institutions that struggle to establish monthly production releases per product team. Meanwhile, some tech companies have established daily production deployments. How can these worlds be so far apart?
We believe that change must start with a goal in mind, an easy-to-validate vision that tremendously improves your organization’s potential. DevOps is one piece of the puzzle with a huge potential impact when followed through to earn benefits.
DevOps Principles
Start strengthening your DevOps capabilities with the following three principles in mind:
Flow
Aggressively automate repetitive activities, so your experts can focus on adding value to your products rather than wasting time with repetitive manual tasks. Do this by improving the repeatability of the build, deploy and test process. Having such a continuous integration will also reduce the efforts to maintain multiple branches of similar code.
Feedback Loop
Improve the quality and speed of feedback to your developers on completed changes. Do this by establishing an automated integration environment that enables you to discover any deployment or environment issue quickly and efficiently. This will reduce the time and resources required to go from functionality complete to releasing the solution to production.
Continuous Improvement
Ensure a continuous improvement practice is established at the enterprise level so senior management will support the set goals by removing identified impediments and addressing dependencies that prevent progress.
“Simply put, things always had to be in production-ready state: if you wrote it, you darn well had to be there to get it running!"
Mike Miller
Five Steps to Continuous Integration
Establishing the five steps below will support setting up your continuous integration and DevOps platform that will fundamentally change how your product teams deliver product increments.
Scripted environments Ensure you can create a new environment based on a predefined script at any time so new environments can be created whenever needed.
Scripted test data Ensure every newly created environment can be enriched with meaningful test data that is automatically ingested. This test data should be managed in a central repository where new test data can be added, or existing data can be modified to cope with software changes.
Code-commit-triggered deployments Every code commit to your versioning system should automatically trigger a build and deployment activity, so new code is deployed quickly to a newly created test environment.
Execution of automated test cases Start developing test cases that cover all necessary test activity levels, from unit tests to integration tests to full end-to-end tests. Ensure every new feature and all identified defects are immediately reflected by new test cases; hence, ensure no identified issue can recur going forward (test-driven development). The test cases should be executed every time new code is deployed to a respective environment.
Automated test reporting Provide a test report to your product team within 24 hours of the code commit on all executed automated test cases. This will ensure developers receive fast feedback on created changes and facilitates a response while implemented code changes are still front of mind for respective experts.
“Programmers don’t burn out on hard work, they burn out on change-with-the-wind directives and not ‘shipping’."
Mark Berry
Why does high deployment velocity matter?
Returning to our initial point, aiming for high-frequency production releases is not only an aspiration but also a game-changer for product teams. It is one of senior management’s most desired cultural changes. It happens when product teams start shifting their focus from “how do we successfully deliver the release” (manage tech processes/ path) to “how can we realize the desired features in the most beneficial way for my customer” (business objective).
Teams with a higher deployment frequency benefit from a faster learning cycle, lower risk due to reduced potential impact of change and working on a close to production code base. The last point is especially true in large solution environments. If ten interlinked product teams work on the production code base of all other teams from the day before, they won’t have to constantly align and integrate other teams’ changes to their development and test environments.
![](https://static.wixstatic.com/media/869877_2930c2ae81414c88ae00cf61c2c4f905~mv2.png/v1/fill/w_875,h_569,al_c,q_90,enc_auto/869877_2930c2ae81414c88ae00cf61c2c4f905~mv2.png)
Graphic 1: Deployment Velocity, see [1]
The accompanying mindset change can be formulated as follows: every developer works on a production-like code base with the understanding that a code commit to the repository will be automatically pushed to test environments and, if successfully tested, will be released to production the same day. At the same time, every code piece must be backward compatible, and some coding practices must be applied, including:
Evolutionary databases
Versioned services/ interfaces
Activation toggle for features
These coding practices allow the separation of the feature release to production from the “activation” moment. Here are some illustrative examples:
Add a new attribute to a database table that will replace an existing one. The switch from the old to the new attribute, however, will happen with a later code change.
Publish a new version of an interface to production, while the “consumers” will switch from the old to the new interface over time.
Push new features to production while keeping them inactive. Only activate a released feature when desired or when sufficiently tested.
Focus on your objectives, not on the path
An automated integration environment allows your workforce to focus on business goals rather than waste time managing code branches, test environments and manual testing activities.
Furthermore, increased traction on value-adding product increments will involve clients/ users more continuously in the delivery process, allowing for faster feedback and learning cycles. This will eventually feed back into an increased business involvement in backlog management and product increment cycle planning with a strong business objective focus.
![](https://static.wixstatic.com/media/869877_5f2b3389d9994f5b884978912f1e80ce~mv2.png/v1/fill/w_718,h_326,al_c,q_85,enc_auto/869877_5f2b3389d9994f5b884978912f1e80ce~mv2.png)
Graphic 2: Management Approach to DevOps, see [2]
Spark Mind has the knowledge, skills, and tools to support you in establishing an understanding of your organization’s situation and providing a gap analysis on how transition can be successfully approached in a setup as discussed in this paper.
Download the PDF version of this article here:
_______________________________________________________
Comentarios