Se a túa empresa só está a introducir ferramentas DevOps ou CI/CD, pode ser útil que te familiarices cos erros máis comúns para non repetilos e non pisar o rake doutra persoa.
Equipo traduciu o artigo .
Falta de preparación para cambiar cultura e procesos
Se observa o diagrama cíclico , está claro que nas prácticas de DevOps as probas son unha actividade continua, unha parte fundamental de cada implementación.
Gráfico de ciclos infinitos de DevOps
As probas e a garantía de calidade durante o desenvolvemento e a entrega son unha parte esencial de todo o que fan os desenvolvedores. Isto require un cambio de mentalidade para incorporar as probas en cada tarefa.
As probas convértese en parte do traballo diario de cada membro do equipo. A transición a probas constantes non é fácil, hai que estar preparado para iso.
Falta de comentarios
A eficacia de DevOps depende dun feedback constante. A mellora continua é imposible se non hai espazo para a colaboración e a comunicación.
As empresas que non organizan reunións retrospectivas teñen dificultades para implementar unha cultura de retroalimentación continua en CI/CD. Reunións retrospectivas realízanse ao final de cada iteración, durante as cales os membros do equipo discuten que foi ben e que foi mal. As reunións retrospectivas son a base de Scrum/Agile, pero tamén son necesarias para DevOps.
Isto débese a que as reunións retrospectivas inculcan o hábito de intercambiar comentarios e opinións. Un dos puntos máis importantes ao comezo é a organización de reunións retro recorrentes para que sexan comprensibles e familiares para todo o equipo.
Cando se trata de calidade do software, todos os membros do equipo son responsables de mantelo. Por exemplo, os desenvolvedores poden escribir probas unitarias e tamén escribir código tendo en conta a probabilidade, o que axuda a reducir o risco desde o principio.
Unha forma sinxela de reflectir o cambio na forma de pensar sobre as probas é chamar aos probadores non ao control de calidade, senón ao probador de software ou enxeñeiro de calidade. Este cambio pode parecer demasiado sinxelo ou mesmo estúpido. Pero chamar a alguén "persoa de garantía de calidade do software" dá unha idea equivocada de quen é o responsable da calidade do produto. Nas prácticas Agile, CI/CD e DevOps, todos son responsables da calidade do software.
Outro punto importante é comprender o que significa a calidade para todo o equipo e para cada un dos seus membros, a organización e as partes interesadas.
Incomprensión da finalización da etapa
Se a calidade é un proceso continuo e xeral, é necesaria unha comprensión común da finalización da etapa. Como sabes cando remata unha etapa? Que ocorre cando se marca un paso como completado nun taboleiro de Trello ou outro Kanban?
Definition of Done (DoD) é unha poderosa ferramenta no contexto de CD DevOps/CI. Axuda a comprender mellor os estándares de calidade do que e como constrúe o equipo.
O equipo de desenvolvemento debe decidir o que significa "Feito". Deben sentarse e facer unha relación de características que deben cumprir en cada etapa para que se considere completa.
DoD fai que o proceso sexa máis transparente e facilita a implementación de CI/CD se todos os membros do equipo o entenden e se acordan mutuamente.
Falta de obxectivos realistas e claramente definidos
Este é un dos consellos máis citados, pero cómpre repetilo. Para ter éxito en calquera esforzo importante, incluíndo CI/CD ou DevOps, cómpre establecer obxectivos realistas e medir o rendemento contra eles. Que estás intentando conseguir con CI/CD? Isto permite lanzamentos máis rápidos con mellor calidade?
Calquera obxectivo marcado non só debe ser transparente e realista, senón que tamén debe ser coherente coas actividades actuais da empresa. Por exemplo, cantas veces necesitan os seus clientes novos parches ou versións? Non é necesario sobrecargar os procesos e liberar máis rápido se non hai ningún beneficio adicional para os usuarios.
Ademais, non sempre precisa implementar tanto CD como CI. Por exemplo, empresas altamente reguladas como bancos e clínicas médicas só poden traballar con CI.
CI serve como un bo punto de partida para calquera empresa que implemente DevOps. Cando se implementa, os enfoques das empresas para a entrega de software cambian significativamente. Unha vez dominado o CI, podes pensar en mellorar todo o proceso, aumentar a velocidade de lanzamento e outros cambios.
Para moitas organizacións, só a CI é suficiente, e o CD só debería implementarse se engade valor.
Falta de paneis e métricas adecuadas
Unha vez que estableza os seus obxectivos, o equipo de desenvolvemento pode crear un panel para medir os KPI. Antes do seu desenvolvemento, convén avaliar os parámetros que se controlarán.
Distintos informes e aplicacións son útiles para os distintos membros do equipo. O Scrum Master está máis interesado no estado e no alcance. Aínda que a alta dirección pode estar interesada na taxa de burnout dos especialistas.
Algúns equipos tamén usan paneis con indicadores vermellos, amarelos e verdes para avaliar o estado de CI/CD e comprender se están a facer todo ben ou se hai un erro. Vermello significa que debes prestar atención ao que está a suceder.
Non obstante, se os paneis non están estandarizados, poden ser enganosos. Analiza que datos necesitan todos e, a continuación, crea unha descrición estandarizada do que significan. Descubra o que ten máis sentido para os interesados: gráficos, texto ou números.
Sen probas manuais
A automatización das probas senta as bases para unha boa canalización de CI/CD. Pero as probas automatizadas en todas as fases non significan que non debas realizar probas manuais.
Para construír unha canalización de CI/CD eficaz, tamén necesitas probas manuais. Sempre haberá algúns aspectos das probas que requiran análise humana.
Paga a pena considerar integrar os esforzos de probas manuais no teu pipeline. Unha vez que se complete a proba manual dalgúns casos de proba, pode pasar á fase de implantación.
Non intentes mellorar as probas
Un pipeline de CI/CD eficaz require acceso ás ferramentas adecuadas, xa sexa xestión de probas ou integración e seguimento continuo.
O obxectivo é crear unha cultura forte e orientada á calidade , supervisando as interaccións dos clientes despois da implantación e realizando un seguimento das melloras.
Aquí tes algúns consellos prácticos que podes implementar facilmente:
- Asegúrate de que as túas probas sexan fáciles de escribir e o suficientemente flexibles como para non romper cando refactoriza o código.
- Os equipos de desenvolvemento deberían incluírse no proceso de probas: consulta unha lista de problemas e solicitudes dos usuarios que son importantes para probar durante os pipelines de CI.
- É posible que non teñas unha cobertura total de probas, pero asegúrate sempre de que se proben os fluxos que son importantes para a experiencia de usuario e a experiencia do cliente.
Último punto pero non menos importante
A transición a CI/CD adoita levarse de abaixo cara arriba, pero en última instancia, é unha transformación que require o compromiso do liderado, o tempo e os recursos da empresa. Despois de todo, CI/CD é un conxunto de habilidades, procesos, ferramentas e reestruturación cultural; estes cambios só poden implementarse de forma sistemática.
Que máis ler sobre o tema:
- .
- .
- .
Fonte: www.habr.com