If your company is just implementing DevOps or CI/CD tools, it might be helpful to familiarize yourself with the most common errors to avoid repeating them and stepping on someone else's rake.
The command translated the article .
Unpreparedness for Cultural and Process Change
Looking at the cyclical diagram , it is clear that in DevOps practices, testing is a continuous effort, a fundamental part of each individual deployment.
Endless Cyclical DevOps Diagram
Testing and quality assurance in the development and delivery process are essential parts of everything developers do. This requires a mindset shift to incorporate testing into every task.
Testing becomes part of the daily work of every team member. Transitioning to continuous testing does not happen easily; one must be prepared for it.
Lack of Feedback
The effectiveness of DevOps depends on continuous feedback. Continuous improvement is impossible without room for collaboration and communication.
Companies that do not organize retrospective meetings struggle to instill a culture of continuous feedback in CI/CD. Retrospective meetings are held at the end of each iteration, where group participants discuss what went well and what went poorly. Retrospective meetings are fundamental to Scrum/Agile, but they are also necessary for DevOps.
This is because retrospective meetings instill the habit of exchanging feedback and opinions. One of the most crucial points at the start is organizing recurring retro meetings so that they become familiar and comfortable for the entire team.
When it comes to software quality, all team members are responsible for its maintenance. For example, developers can write unit tests and also write code with testability in mind, helping to reduce risks from the very beginning.
One of the simplest ways to reflect changes in perceptions about testing is to refer to testers not as QA, but rather as software testers or quality engineers. This change may seem too simple or even foolish. However, calling someone a 'software quality assurance specialist' gives a misleading impression of who is responsible for product quality. In Agile, CI/CD, and DevOps practices, everyone shares responsibility for software quality.
Another important point is understanding what quality means for the entire team and each of its members, the organization, and stakeholders.
Misunderstanding of the definition of done
If quality is a continuous and collective process, there needs to be a shared understanding of the definition of done. How do you know when a stage is complete? What happens when a stage is marked as done on a Trello board or another Kanban board?
The Definition of Done (DoD) is a powerful tool in the context of CI/CD DevOps. It helps clarify the quality standards of what and how the team builds.
The development team must decide what 'Done' means. They need to sit down and create a list of criteria that must be met at each stage for it to 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 pieces of advice, but it bears repeating. For the success of any serious initiative, including the implementation of CI/CD or DevOps, it is essential to set realistic goals and measure performance against them. What are you trying to achieve with CI/CD? Does it allow for faster releases with better quality?
Any set goals must not only be transparent and realistic but also aligned with the company's current activities. For example, how often do your clients need new fixes or versions? There is no need to overload processes and release faster if it does not provide additional benefits for users.
Additionally, you do not always need to implement both CD and CI. For instance, companies with a high degree of regulation, such as banks and medical clinics, may only work with CI.
CI serves as a good starting point for any company implementing DevOps. Its adoption significantly changes software delivery approaches within the company. Once CI is mastered, consideration can be given to enhancing the entire process, increasing rollout speed, and other changes.
For many organizations, a CI alone is sufficient, and CD should only be implemented if it provides additional benefits.
Lack of appropriate monitoring panels and metrics
Once you have set your goals, the development team can create a dashboard to measure KPIs. Before its development, it's worth assessing the parameters that will be tracked.
Different reports and applications are useful for different team members. Scrum Masters are more interested in status and coverage, while senior management may be interested in the burnout rate of specialists.
Some teams also use dashboards with red, yellow, and green indicators to assess the status of CI/CD, helping them understand whether they are on the right track or if an error has occurred. Red means attention is needed.
However, if the dashboards are not standardized, they can be misleading. Analyze what data is needed for everyone, and then create a standardized description of what they mean. Determine what makes more sense for stakeholders: graphs, text, or numbers.
Lack of manual testing
Automated testing lays the foundation for a solid CI/CD pipeline. However, automated testing at all stages does not mean you should skip manual testing.
To build an effective CI/CD pipeline, manual testing is also necessary. There will always be aspects of testing that require human analysis.
Consider integrating manual testing efforts into the pipeline. Once manual testing of certain test cases is complete, you can move on to the deployment stage.
Do not try to improve tests
An effective CI/CD pipeline requires access to the right tools, whether it’s test management or integration and continuous monitoring.
Creating a strong quality-oriented culture focuses on , monitoring customer interactions post-deployment, and tracking improvements.
Here are some practical tips that you can easily implement:
- Ensure that tests are simple to write and flexible enough not to break during code refactoring.
- Development teams should be involved in the testing process — viewing a list of customer issues and requests that are important to verify during CI pipelines.
- You may not have complete test coverage, but always ensure that flows critical to UX and customer interactions are tested.
Last but not least,
the transition to CI/CD is often initiated from the bottom up, but ultimately, it is a transformation that requires leadership involvement, time, and resource investment from the company. After all, CI/CD is a set of skills, processes, tools, and a cultural shift that can only be implemented systematically.
What else to read on the topic:
- .
- .
- .
Source: habr.com
