Si la vostra empresa només està introduint eines DevOps o CI/CD, us pot ser útil familiaritzar-vos amb els errors més comuns per no repetir-los i no trepitjar el rastell d'una altra persona.
Equip traduït l'article .
Falta de preparació per canviar la cultura i els processos
Si observeu el diagrama cíclic , està clar que a les pràctiques de DevOps les proves són una activitat contínua, una part fonamental de cada desplegament.
Gràfic de cicles infinits de DevOps
Les proves i la garantia de qualitat durant el desenvolupament i el lliurament són una part essencial de tot el que fan els desenvolupadors. Això requereix un canvi de mentalitat per incorporar les proves a cada tasca.
Les proves esdevenen part del treball diari de cada membre de l'equip. La transició a les proves constants no és fàcil, cal estar preparat per a això.
Manca de comentaris
L'eficàcia de DevOps depèn de la retroalimentació constant. La millora contínua és impossible si no hi ha espai per a la col·laboració i la comunicació.
Les empreses que no organitzen reunions retrospectives tenen dificultats per implementar una cultura de retroalimentació contínua en CI/CD. Al final de cada iteració es fan reunions retrospectives, durant les quals els membres de l'equip discuteixen què ha anat bé i què ha anat malament. Les reunions retrospectives són la base de Scrum/Agile, però també són necessàries per a DevOps.
Això es deu al fet que les reunions retrospectives inculquen l'hàbit d'intercanviar comentaris i opinions. Un dels punts més importants a l'inici és organitzar reunions retro recurrents perquè siguin comprensibles i familiars per a tot l'equip.
Quan es tracta de la qualitat del programari, tots els membres de l'equip són responsables de mantenir-lo. Per exemple, els desenvolupadors poden escriure proves unitàries i també escriure codi tenint en compte la provabilitat, ajudant a reduir el risc des del principi.
Una manera senzilla de reflectir el canvi en la manera de pensar sobre les proves és trucar als verificadors, no a l'AQ, sinó a un verificador de programari o un enginyer de qualitat. Aquest canvi pot semblar massa senzill o fins i tot estúpid. Però anomenar algú "persona que garanteix la qualitat del programari" dóna una idea equivocada sobre qui és responsable de la qualitat del producte. A les pràctiques Agile, CI/CD i DevOps, tothom és responsable de la qualitat del programari.
Un altre punt important és entendre què significa qualitat per a tot l'equip i cadascun dels seus membres, l'organització i els grups d'interès.
Incomprensió de la finalització de l'etapa
Si la qualitat és un procés continu i general, cal una comprensió comuna de la finalització de l'etapa. Com saps quan ha acabat una etapa? Què passa quan un pas es marca com a completat en un Trello o un altre tauler Kanban?
Definition of Done (DoD) és una eina potent en el context de CD DevOps/CI. Ajuda a entendre millor els estàndards de qualitat de què i com es construeix l'equip.
L'equip de desenvolupament ha de decidir què significa "Fet". Cal seure i fer una llista de característiques que s'han de complir en cada etapa perquè es consideri completa.
El DoD fa que el procés sigui més transparent i facilita la implementació de CI/CD si tots els membres de l'equip l'entenen i s'acorden mútuament.
Manca d'objectius realistes i clarament definits
Aquest és un dels consells més citats, però val la pena repetir-ho. Per tenir èxit en qualsevol esforç important, inclosos CI/CD o DevOps, cal establir objectius realistes i mesurar-ne el rendiment. Què estàs intentant aconseguir amb CI/CD? Això permet llançaments més ràpids i de millor qualitat?
Qualsevol objectiu marcat no només ha de ser transparent i realista, sinó que també ha de ser coherent amb les activitats actuals de l'empresa. Per exemple, amb quina freqüència els vostres clients necessiten nous pegats o versions? No cal sobrecarregar els processos i alliberar-los més ràpidament si no hi ha cap benefici addicional per als usuaris.
A més, no sempre cal que implementeu CD i CI. Per exemple, les empreses altament regulades, com ara bancs i clíniques mèdiques, només poden treballar amb CI.
CI serveix com a bon punt de partida per a qualsevol empresa que implementi DevOps. Quan s'implementa, els enfocaments de les empreses pel que fa al lliurament de programari canvien significativament. Un cop dominat el CI, podeu pensar en millorar tot el procés, augmentar la velocitat de llançament i altres canvis.
Per a moltes organitzacions, l'IC només és suficient, i el CD només s'hauria d'implementar si aporta valor.
Manca de taulers i mètriques adequats
Un cop hàgiu establert els vostres objectius, l'equip de desenvolupament pot crear un tauler per mesurar els KPI. Abans del seu desenvolupament, val la pena valorar els paràmetres que es controlaran.
Diferents informes i aplicacions són útils per a diferents membres de l'equip. L'Scrum Master està més interessat en l'estat i l'abast. Mentre que l'alta direcció pot estar interessada en la taxa d'esgotament dels especialistes.
Alguns equips també utilitzen taulers amb indicadors vermells, grocs i verds per avaluar l'estat de CI/CD per entendre si ho estan fent tot bé o si hi ha un error. El vermell significa que cal parar atenció al que està passant.
Tanmateix, si els taulers de control no estan estandarditzats, poden induir a error. Analitzeu quines dades necessiten tothom i, a continuació, creeu una descripció estandarditzada del que significa. Descobriu què té més sentit per a les parts interessades: gràfics, text o números.
Sense proves manuals
L'automatització de proves estableix les bases d'un bon pipeline CI/CD. Però les proves automatitzades en totes les etapes no vol dir que no s'hagin de realitzar proves manuals.
Per crear un pipeline CI/CD eficaç, també necessiteu proves manuals. Sempre hi haurà alguns aspectes de les proves que requereixen anàlisi humana.
Val la pena considerar la integració dels esforços de prova manual al vostre pipeline. Un cop finalitzada la prova manual d'alguns casos de prova, podeu passar a la fase de desplegament.
No intenteu millorar les proves
Un pipeline CI/CD eficaç requereix accés a les eines adequades, ja sigui gestió de proves o integració i supervisió continuada.
L'objectiu és crear una cultura forta i orientada a la qualitat , el seguiment de les interaccions amb els clients després del desplegament i el seguiment de les millores.
Aquí teniu alguns consells pràctics que podeu implementar fàcilment:
- Assegureu-vos que les vostres proves siguin fàcils d'escriure i prou flexibles com per no trencar-se quan refactoritzeu el codi.
- Els equips de desenvolupament s'han d'incloure en el procés de prova: consulteu una llista de problemes i sol·licituds dels usuaris que són importants per provar durant els pipelines CI.
- És possible que no tingueu una cobertura de proves completa, però sempre assegureu-vos que es provein els fluxos que són importants per a l'UX i l'experiència del client.
Últim punt, però no menys important
La transició a CI/CD sol ser impulsada de baix a dalt, però en última instància és una transformació que requereix l'adopció del lideratge, el temps i els recursos de l'empresa. Al cap i a la fi, CI/CD és un conjunt d'habilitats, processos, eines i reestructuració cultural; aquests canvis només es poden implementar sistemàticament.
Què més llegir sobre el tema:
- .
- .
- .
Font: www.habr.com