Total ownership
During a previous blog from this series, we discussed what it takes to transform individual ideas, improvements or needs into concrete features. These are descriptions of small pieces of functionality of a digital solution, written from the end user’s perspective.
Then the real delivery phase begins, where functionalities are built, tested and kept in the air. This is where a multidisciplinary product team comes into action. They are responsible for their entire process, from the implementation of new features to the operation of everything already in production. Each team is end-to-end responsible for its deliverables throughout its lifecycle.
This is the basis of the true DevOps mindset: you build it, you run it. This awareness often leads to implicit quality improvements. If you are responsible for any problems at night or at the weekend, you will ensure that the system is very stable and you build as much resilience into the software as possible. This also means that by definition these teams need to be stable and mature. Whether you prefer the DevOps approach or the SRE approach doesn't make much difference to our story. That's why we use the general name "product team'" in this blog post.
Gain efficiency and effectiveness with transversal management
In addition to everyone’s own responsibility, there are also many things that are best set up transversally. Not every team has to re-invent the wheel. DevOps support systems such as Atlassian and Azure DevOps contain essential building blocks to ensure proper operation. Besides source control and pipelines to set up CI/CD (Continuous Integration and Continuous Deployment) systems, there are also integrated collaboration tools to facilitate agile operation. The tooling, along with the processes, provides continuous feedback loops to circulate knowledge and experiences throughout the process. This is how you stay on top of things ("are we building the thing right?") and optimize a team's operation and knowledge.
These kinds of processes and tools are rolled out and maintained transversally across the various DevOps teams, so they can be used easily and really facilitate a team. A balance always has to be found in terms of implementing the actual processes and pipelines. How much can be sent transversally and what is the responsibility of each team? As mentioned above, teams take end-to-end responsibility and they ultimately have the final say. At the same time, a software delivery process is very streamlined and the steps to be taken are fairly fixed. Greater software development maturity often goes hand in hand with more transversal processes and tools.
Testing, testing, testing
The diagram below provides a high-level picture of the various phases and steps we see in an agile software delivery process. In the case of an automatic pipeline, these steps are fully automated.
We are in the phase after the commitment point at which the organization has decided to really get started with the concrete development of a functionality. The user story, which was written in human language, is converted into line code.
As part of Continuous Delivery, the building process (CI) ensures that a binary artifact(1) is made of the code. This is also the ideal time to subject the code to various tests, so that we can get an immediate idea of its quality. For example, automatic unit tests and static code analysis tools such as SonarQube can be used to thoroughly validate the code. Typically, a score is given based on the number of bugs, vulnerabilities, code smells, the success rate of the unit tests, as well as the percentage of the functionality the unit tests cover (code coverage). This is very important feedback that must be dealt with immediately. A build that does not meet the minimum requirements should be stopped in order to guarantee quality. A CI system helps with this because it starts an automatic process when a developer commits their code to the source repository. The system initiates the build and allows the automatic tests to run.
Depending on the technology used, automatic steps can also be taken for the deployment of these artifacts to the various systems. Cloud native systems such as Kubernetes are fundamentally different. In the future, the type of pipeline used will also evolve further. Work is already underway on event-driven systems (Keptn (keptn.sh), for example, uses these) that work perfectly in a Kubernetes environment with more than hundreds of micro-services. Automatic testing during the various stages of the traditional deployment pipeline should also provide implicit and continuous quality improvement.
Explicit performance testing based on load/stress testing is also an integral part of the automatic pipeline. Environments are also monitored for this. This happens at the system level, but mainly at the level of applications (observability) and even at the user level (real user monitoring). By deploying a system such as Dynatrace to the low-level environments (TEST, INT, ACC, etc.), the insights associated with all kinds of testing can be viewed from the inside. This saves a lot of valuable time when troubleshooting bugs and also implicitly improves quality.
In addition, manual tests are and will continue to be extremely important. A multidisciplinary team should ideally include people with testing skills. At the same time, it is very beneficial for some organizations to set up test management and coaching transversally. Security is another such topic. It must be built into a team to a certain extent, but it can also be perfectly facilitated transversally.
Of course, the ultimate goal of all those tests is a technically working whole, but the intended value and practical usefulness always needs to be taken into account. Have we built something that matches the initial expectations? Are the user stories reflected in the result? These feedback loops are very important and characteristic of an agile way of value creation.
(1) binary artifact: from code to machine language, so it can be executed by a machine
This article is part of a blog series covering all the key components of an agile development process. Also be sure to read: