With DevOps, companies are trying to break the dividing line between two formerly highly isolated divisions: development and operations
The reasons why companies are embarking on this path include the following:
- The pushing back and forth of responsibility is eliminated, for example the eradication of disruptions.
- Developing and improving products is faster than in other companies which rely on traditional software development and operational processes
- At DevOps, developers are responsible for maintaining the infrastructure and the system. The combination of knowledge from development and infrastructure often results in a better solution
- Necessary infrastructure adjustments are easier, as their possibilities (or limitations) are taken into account during development
- Today, companies need to be able to respond more quickly to market adjustments. On the one hand, this requires accelerated development. Moreover, it also has to guarantee that the artefacts can be delivered.
The term DevOps therefore stands for new ways of thinking, practices and tools that can help companies deliver applications and services, both faster and easier.
How to ensure successful DevOps in the company
Teams and the team members have to be technically competent and self-organised. However, the key to successful DevOps is the end-to-end responsibility of each individual. In order to be able to take on responsibility as a team member in a DevOps project, a basis has to be created that is now also part of our company philosophy:
Responsibility is based on trust. Only employees who trust the processes, their skills, tools, other team members and the architecture they develop on can ultimately take responsibility.
We believe in modern and agile development models, which requires building cross-functional teams to increase productivity.
"Never stop learning" and "everyone can do everything" best describes our approach to the training and development of our employees. As a training centre, we can offer our employees both internal and external training opportunities.
A solid and maintainable architecture is essential as a technological basis. Our experience shows that, for example, ROCA (resource-oriented component architecture) is excellently suited for decoupled development. We also follow the "Security by Design" paradigm. At the same time, security standards and measures are taken into account when designing the architecture and processes - and not just towards the end of the project.
Code conventions and patterns, from written code, style sheets, to commit messages into SCM, allow the entire team to track the work of all other team members.
Within our teams, quality control is not an optional building block, but an integral part of a development project. The person responsible for QA is in charge of compliance with the quality guidelines. Therefore, the QA Engineer is an indispensable part of a user story, just like developer. In addition, effective and consistent project work requires a high degree of automation.
How do we bring people, tools, workflows and processes together within DevOps?
We train our employees to be T-shaped Developers. A T-shaped Developer has at least one specialty in which they are outstanding. In addition, they have a broad expertise and can therefore take on different tasks in an agile development project.
We work with an "agile tool-chain" for the automation of our development processes. These tools are strongly integrated with each other and work - mainly virtualized - together seamlessly. For example, it only takes us 15 minutes to set up a defined development environment on a local machine for a colleague.
Workflow and Processes
When implementing software projects, we always focus on integrating software as often and early as possible to reduce errors and maximize quality.
Our ultimate goal is to have a project release-ready status at any time during a software development process.
In doing so, we always try to cut the big project into many small packages, deliver it quickly and obtain customer feedback at an early stage. Our processes are based on best practices from different methods such as Scrum, Kanban, ITIL and CMMI.
How to measure success in DevOps projects?
In DevOps projects, service levels can be defined, from which you can derive the corresponding KPIs. These include, for example, the availability of the team (KPI:%), continuous delivery (KPI: frequency of deployments, successful deployments), system availability (in%), process degree of automation (in%) or the delivery time (in hours or days).
All measured KPIs have an influence on the future process improvements, as empirical values are always incorporated into process improvements.
One challenge is finding the right KPIs and using them as a basis for making decisions for future improvements. The question that always has to be asked is this: Are the identified factors complete and do they have an impact on the KPIs?
Sounds easy. However, it isn‘t always.