Focus on automation reduces user story waiting times by 90%.
At Devoteam we like to share information about how we help our customers to save time in the IT processes of their organization, through focus on automation. How do we proceed? And what are the benefits?
Devoteam performs numerous Devops implementations for both businesses and governments. This government organization had to deal with a complex IT infrastructure: multiple websites and a backend system that is used to retrieve information. In order to help citizens properly and to provide an optimal service, these different systems also had to exchange information with each other.
Complexity requires innovation
It was, due to the complexity of this underlying infrastructure, possible that certain errors occurred. To prevent this, the organization decided to focus on the innovation of its IT infrastructure. This meant changing and / or automating the way IT teams worked. Two solutions were deployed: improving the current system and they decided to invest in a new system.
Focus on automation and more responsibility for the different teams
It soon became clear that most of the effort was spent on optimizing the current system; for example by adding new features. In improving this system and the process, the focus was on automation and more responsibility for the teams. The requirements to go to production were also higher and more strictly controlled by management. That’s why we began to focus on CI / CD (“Continuous Integration / Continuous Delivery”); to ensure that the developed software is delivered in an automated, repeatable, predictable and secure manner. This minimizes incidents after an update.
In addition to CI / CD, it was the intention that teams could make changes to production themselves without being too dependent on other teams to accelerate delivery to production: the Devops way of working. Projects and activities had to be allocated more precisely to different teams. During this process, we started to automate the software delivery processes by building pipelines (using Microsoft Azure DevOps); the automated ways to production.
Quality control
The code written by developers cannot just immediately go to production. For example, checks are needed to verify that the code meets the functional and safety requirements. By applying these controls, we were able to prove to stakeholders (including management) that the new code could be delivered safely to production. In the Azure DevOps pipelines, various tooling is used to check the code. In addition to performing the usual unit tests (tests that verify individual pieces of the code for functionality), Tricentis Tosca was also used to test the application screens and processes. SonarQube was used to monitor the quality of the code (think of readability and maintainability) by means of best practices and Fortify to monitor the security of the code. The code may only go to production if it passes all checks.
Scripting: PowerShell
Powershell was used to automate tasks if this was not possible in Azure DevOps. One of the biggest and most important tasks was to use it for updating the database. During deployment, the script checked a number of things. First of all, which database has executed the scripts. This prevents errors in the database. After that, we checked whether the script was changed in the meantime, to prevent errors and fraud. Finally, another check was built in to see whether the script complied with the best practices and requirements of the database administrator team. If everything went well, the database was executed and information about this (that the script was executed, by whom and the logging) was kept in a table.
50% less time used for each team in a user story and waiting time decreased to ten minutes
A lot of time has been saved through automation in the entire deployment. For example, there are certain activities that are no longer performed manually, which significantly reduces the time for the entire user story: from 350 minutes to a total of 160 minutes. For example, manual runbooks no longer need to be created on Friday afternoon. In addition, many clear agreements have been made with various stakeholders. Developers and testers now know immediately, through a short feedback loop, whether they are doing the right thing and which changes can be definitively implemented.
Less waiting time on the way to production, more involvement of different teams. The processes of teams have been mapped out through value stream mapping. So it became clear what the different waiting times were and for which teams. This has been reduced enormously; from 100 minutes to just ten minutes per user story. In addition, it is much clearer what the process is and what the minimum requirements are for going to production. Fewer approvals are required and the automation of the process means more ownership within the teams.
The teams are now more in control, have more responsibility and freedom and deliver with higher quality. The internal stakeholders who monitor the processes have less fear of allowing updates to production. In Microsoft Azure DevOps you can always see what, by whom and when something happened. Automation and more responsibility for teams have reduced the previously often demanded checks from stakeholders.
