Main benefits that a company generally expects and finds in the adoption of culture:
Faster and Cheaper Releases
Since releases will be continuous and frequent, deliverables will turn into small changes with the benefit of increasing speed in the development cycle (delivering always).
Improved Operational support with quick fixed
If there is a failure during delivery, the impact is minimal because the amount of modifications is small, just as the rollback is faster. Having a simple inspection and debugging.
Better Time-to-market (TTM)
The software will be delivered much earlier when it’s still an MVP. Customers will be integrated as part of the development process, bringing insights and feedback to the development team. Thus allowing for a higher launch speed in the market.
Superior quality products
As has been said before, early failures prevent defects from being delivered to production, because:
- Reduces the volume of defects in the product as a whole;
- Increases frequency of new features and releases;
- Appropriate development processes in teams, including automation.
Now we understood WHY, let’s talk about HOW
Continuous releases (integration, delivery, deployment)
Usually follows a code versioning approach (through Git) using specific branches for each environment (e.g.: feature branches with git flow).
Automatic execution of unit tests, integration tests and code quality analysis against a git branch, to ensure that there was no disruption of the modified piece of code.
Packaging the software that is tested and approved, to deliver it somewhere that it is possible to use in a deploy later. Examples are libs delivered in repositories to be integrated into the code during the next update and code deploy.
Once you have completed all of the above steps, you can do automated deployments right in the environments, when the team is more confident about the tools they are testing, as well as the risk they’re taking and also understanding that there is a possibility of failure in a tests environment without worrying that it’s going to be divergent from production.
Configuration (and/or Infrastructure) as code
To be able to test software with assertiveness, and to understand that it will transit between environments without changing behavior, it is essential that the configurations are also expressed in code. This allows the settings to be also versioned, following the code. Also guaranteeing a uniformity among the environments, which enables:
- Reduction in maintenance costs, having a single point to look at and understand the operation of the system;
- Easy to recreate the infrastructure, if it is necessary to move everything to another place, this can happen with a few manual interactions;
- Allows for a code review of infrastructure and configurations, which consequently brings a culture of collaboration in the development, sharing of knowledge and increases the democratization of the infra;
- Documentation as code, helping new team members get a faster warm up.
These points were well-stressed by the Heroku team and gave rise to the famous paper: The Twelve-Factor App. It’s an excellent reading for the explanation of the benefits of configuration management.
Observability, Monitoring, and self-healing
At the end of the delivery process, the software must be monitored. Avoiding to wait for an external report of failures, ensuring that the actions are proactive rather than reactive.
With mature monitoring, it’s possible to create trigger against alerts, creating a self-healing system in which actions (scripts) are performed to fix known failures in the infrastructure so that everyone can sleep peacefully at night, without having to worry about the on-call schedule that makes you read some documentation at dawn. (If you have had experience with this, you know for sure how bad it is).
Scaling up only those cases that are extreme exceptions (mistakes not known/expected) in the process for the employee to act, ensuring higher health in operation.
All processes that cause Muda should be addressed with automation, allowing people to work more quickly. Good examples of processes that are usually automated are:
- Self-healing (system resilience in response to anomalies);
- Renewal of Certificates;
- Execution of tests (unitary, integration, functional, etc.);
- Monitoring (with auto-discovery);
- User Governance;
A combination of tools to facilitate the maintenance and operation of the system, with the flow:
Note: Any similarity to the PDCA is pure certainty.
- Plan: Project planning phase, in which feedbacks are collected for requirements survey, and backlog creation;
- Create: Creation of a deliverable (to validate a hypothesis), such as an MVP;
- Verify: Pass the deliverable to the test phase;
- Package: Package the build to be able to put it in some testing environment;
- Release: Deploy packaged deliverable;
- Configure: Perform the configuration of the deliverable in the testing environment, trying to get as close as possible to the twelve-factor app.
- Monitor: After deploying to the environment, track business metrics and infrastructure to ensure everything is working as expected.
During the implementation of these techniques it is possible to observe improvements in the development process, the most notable gains are:
- Increase in team engagement;
- Knowledge sharing;
- Reduction of bottlenecks;
- More free time to do work that really matters (adds value to the user experience or generates impact);
- Greater confidence in delivering software.