If your company is just implementing DevOps or CI/CD tools, it may be useful for you to get acquainted with the most common mistakes so that you don't repeat them and step on someone else's rake.
Team translated the article .
Unwillingness to change culture and processes
Looking at the cycle diagram , it is clear that in DevOps practices, testing is a continuous work, a fundamental part of each individual deployment.
DevOps Endless Cycle Diagram
Testing and quality assurance during development and delivery is an essential part of everything developers do. This requires a mindset change to include testing in every task.
Testing becomes part of the daily work of every team member. The transition to continuous testing is not easy, you need to be prepared for this.
Lack of feedback
The effectiveness of DevOps depends on constant feedback. Continuous improvement is not possible if there is no room for collaboration and communication.
Companies that do not organize retrospective meetings find it difficult to implement a culture of continuous feedback in CI/CD. Retrospective meetings are held at the end of each iteration, where group members discuss what went well and what went wrong. Retrospective meetings are the foundation of Scrum/Agile, but they are also essential for DevOps.
This is because retrospective meetings instill the habit of exchanging feedback and opinions. One of the most important moments at the start is the organization of recurring retro meetings so that they become understandable and familiar to the whole team.
When it comes to software quality, all team members are responsible for maintaining it. For example, developers can write unit tests as well as code with testability in mind, helping to mitigate risk from the start.
One easy way to reflect the changing perceptions of testing is to call testers not QA but software tester or quality engineer. This change may seem too simple or even stupid. But calling someone a "software quality assurance specialist" gives the wrong idea of ββwho is responsible for product quality. In Agile, CI/CD, and DevOps practices, everyone is responsible for software quality.
Another important point is understanding what quality means for the whole team and each of its members, organization, stakeholders.
Misunderstanding of stage completion
If quality is a continuous and shared process, a common understanding of the completion of a stage is needed. How to understand that the stage is over? What happens when a milestone is marked as completed on a Trello board or other kanban board?
Determining a completed milestone (DoD) is a powerful tool in the context of CD DevOps/CI. It helps to better understand the quality standards of what and how the team builds.
The development team must decide what "Done" means. They need to sit down and make a list of the characteristics that must be met at each stage so that it can be considered complete.
DoD makes the process more transparent and facilitates the implementation of CI / CD, if it is clear to all team members and mutually agreed upon.
Lack of realistic, clearly defined goals
This is one of the most frequently quoted tips, but it is worth repeating. For any serious undertaking to succeed, including implementing CI/CD or DevOps, you need to set realistic goals and measure performance against them. What are you trying to achieve with CI/CD? Does it allow faster releases with better quality?
Any goals set should be not only transparent and realistic, but also consistent with the current activities of the company. For example, how often do your customers need new patches or versions? There is no need to overload processes and release faster if there is no additional benefit to users.
Also, you don't always need to implement both CD and CI. For example, highly regulated companies such as banks and medical clinics may only work with CI.
CI is a good starting point for any company implementing DevOps. When it is implemented in a company, approaches to software delivery change significantly. Once CI is mastered, you can think about improving the whole process, increasing the rollout speed and other changes.
For many organizations, one CI is sufficient, and CD should only be implemented if it adds value.
Lack of relevant dashboards and metrics
Once you have set goals, the development team can create a dashboard to measure KPIs. Prior to its development, it is worthwhile to evaluate the parameters that will be monitored.
Different reports and applications are useful for different team members. Scrum masters are more concerned with status and reach. While senior management may be interested in the rate of burnout of specialists.
Some teams also use dashboards with red, yellow and green indicators to assess the status of CI / CD, to understand whether they are doing everything right or if an error has occurred. Red means that you need to pay attention to what is happening.
However, if dashboards are not standardized, they can be misleading. Analyze what data everyone needs and then create a standardized description of what it means. Find out what makes more sense to your stakeholders: graphics, text, or numbers.
Lack of manual tests
Test automation lays the foundation for a good CI/CD pipeline. But automated testing at all stages does not mean that you should not do manual testing.
To build an efficient CI/CD pipeline, manual tests are also needed. There will always be some aspects of testing that require human analysis.
It is worth considering integrating manual testing efforts into the pipeline. Once the manual testing of some test cases is complete, you can move on to the deployment phase.
Don't try to improve tests
An effective CI/CD pipeline requires access to the right tools, whether it be test management or integration and ongoing monitoring.
Creating a strong, quality-oriented culture aims to , monitor customer experience after deployment, and track improvements.
Here are some practical tips that you can easily implement:
- Make sure the tests are easy to write and flexible enough to not break when the code is refactored.
- Development teams should be included in the testing process - see a list of user issues and requests that are important to test during CI pipelines.
- You may not have full test coverage, but always make sure the flows that are important to UX and customer experience are tested.
Last but not least point
The transition to CI/CD is usually initiated from the bottom up, but in the end, it is a transformation that requires the participation of management, time and resources from the company. After all, CI / CD is a set of skills, processes, tools and cultural restructuring, such changes can only be implemented systematically.
What else to read on the topic:
- .
- .
- .
Source: habr.com