8 reptes clau en l'adopció de DevOps: part 2: solucions

A la primera part (aquí) d'aquesta sèrie de blocs de dues parts, vaig analitzar els vuit reptes clau que veuen les organitzacions quan adopten DevOps. Ara, mirem algunes solucions.

El canvi és el més difícil al principi, el més desordenat al centre i el millor al final. - Robin S. Sharma

1. Funcionar la cultura segons els principis de DevOps

Els líders i agents de canvi de DevOps hauran de trobar maneres d’educar contínuament equips i persones de l’organització sobre com s’assembla a la cultura DevOps i per què accelera el flux de valor. A continuació, es detallen algunes coses que he intentat:

Aprenentatge i comunitats de pràctiques

El personal de DevOps pot organitzar presentacions de formació o introducció interna per a l'adopció de DevOps i exposar-les a la cultura de DevOps. D’aquesta manera poden promoure i trobar-se cara a cara amb tots els membres de l’organització. Es preferix la col·laboració presencial que l'ús del correu electrònic o la videoconferència, ja que els humans creen confiança més ràpidament, per la qual cosa es recomana emprendre un camí de cara si els equips es dispersen, amb l'objectiu de reunir-se amb tothom almenys un per crear relacions.

Bàsics i preguntes freqüents sobre DevOps

Els equips de DevOps poden crear una base de coneixement o preguntes freqüents (FAQ) i compartir amb totes les persones de l’organització, de manera que tothom sap d’on obtenir informació per relacionar-se amb DevOps on ho necessiti. La visibilitat i l’accés fàcil a la informació que els motiva a cercar-los i llegir-los per ells mateixos i fins i tot contribuir. Aquest tipus d’informació es pot conservar en plataformes col·laboratives com Atlassian Confluence o Microsoft Teams.

Aplicació de pràctiques de cultura de l'organització Westrum

Podem utilitzar la pràctica de la cultura Westrum Organization per fer una cultura generativa que cultivi el flux de dades i la confiança mirant les sis parts del model de cultura jeràrquica de Westrum, concentrant-nos en aquelles pràctiques que es troben en la cultura generativa;

Aquí com es pot crear una cultura generativa;

2.Adreçar la resistència al canvi

Els líders han d’esperar que la gent resisteixi al canvi. Segons DevOpsologist, Philippa Hale, en el seu article sobre les eines de mapeig d’interessats i va parlar de com podem abordar els estats d’ànim i emocions de determinades persones del grup cap als canvis, llavors podem aplicar diferents estratègies de compromís per apropar-les a les iniciatives de DevOps. Hi ha 6 “perfils de comportament” i com podem relacionar-nos amb els que es descriuen a continuació;

Sense compromís

Espectadors

Cínics

Crítics

Entusiastes

Advocats (Campions / Experts)

Per resumir-nos en base a les qüestions anteriors, podem veure tots els enfocaments de participació implicats en la comunicació i mantenir-nos informats sobre l'adopció de DevOps Hem de treballar estretament amb tots els grups i ser visibles per a ells i donar ajuda sempre que en necessitin.

3.Bringing Clarity to the DevOps Vision

La introducció del marc CALMS de DevOps pot ajudar a definir el full de ruta i els objectius de DevOps. CALMS és un marc conceptual per a la integració d'equips, funcions i sistemes de desenvolupament i operacions (DevOps) de desenvolupament dins d'una organització.

Els líders de DevOps han de desenvolupar un full de ruta clar per a l'evolució de DevOps amb fases de millora clares. Han de compartir-ho i fer-lo visible per a tothom de l’organització;

4.Crear la col·laboració entre equips

Els equips de desenvolupament i informàtica necessiten aprendre a col·laborar. Això pot suposar la creació d'equips funcionals que incloguin tant professionals com operadors, però això no funciona en moltes organitzacions. Sovint és massa dramàtic un canvi organitzatiu, o simplement no hi ha prou gent per recórrer-hi. Les instal·lacions tradicionals del departament de tecnologia solen incloure una àmplia experiència en temes en operacions informàtiques al voltant de la seguretat i la creació de xarxes, per exemple, de manera que és difícil veure com compartir aquest tipus de persones entre equips de desenvolupament o productes.

En què consisteix l'ajut de reunir-se regularment els equips de desenvolupament i informàtica? Si els equips de desenvolupament fan gestions diàries com a part de les seves pràctiques àgils, la invitació a les operacions de TI a participar pot ajudar-lo a eliminar els impediments. Convidar-los a la planificació sprint pot assegurar que es consideren requisits no funcionals al sprint, racionalitzant així el procés d’entrega de valors.

Les eines de comunicació entre equips com Slack o Microsoft Teams ajuden realment, ja que fan possible que la col·laboració sigui contínua. El grup o canal de xat “Alerta / Notificació” també s’ha de gestionar adequadament, de manera que els problemes es poden dirigir a l’equip correcte i escalar-se ràpidament mitjançant l’acció correcta que cal dur a terme per resoldre el problema / error.

A continuació es mostren algunes eines de col·laboració que podeu utilitzar i començar a col·laborar dins de l’organització;

5. Ambients normatius

Un entorn és una col·lecció de recursos o llocs orientats que voleu convertir de codi en un producte real mitjançant el pipeline. L’entorn pot incloure màquines virtuals (VM), servidors de bases de dades, serveis de tercers, etc. A continuació, es mostra un exemple d’etapes de l’entorn amb el seu ús, usuari / persona i responsable de mantenir l’entorn;

Els avantatges de tenir un entorn ben definit inclouen els següents;

  1. Registre / historial de desplegament: tots els detalls de l'execució de pipeline es registren en eines de CI / CD per als seus recursos.
  2. Traçabilitat: permet rastrejar si un canvi de codi (commit) o ​​una característica / correcció d'errors (elements de treball) van arribar a un entorn.
  3. Permís / Control: un entorn segur especificant quin usuari està permès i quin entorn destinarà.

El subministrament d'entorn de l'automatització és un factor important d'èxit en un procés de lliurament continu. L’equip de Dev pot sol·licitar un nou entorn ad-hoc i el vostre entorn s’ofereix sota demanda com a implementació d’aplicacions? L’entorn d’aplicacions es pot dividir en tres àrees principals:

1. Infraestructura

2. Configuració

3. Dependències

La infraestructura és el lloc on es desplega l'aplicació o el servei i l'aplicació necessitarà necessitats específiques de configuració. També inclou la forma com les dependències han d’integrar-se amb l’aplicació. A dia d’avui, la infraestructura es pot subministrar per script o bé s’anomenen “Infraestructura com a codi” o en resum IaC. Avui es fa més accessible avui a través d’una àmplia gamma d’eines disponibles per automatitzar tot el procés de subministrament d’entorn.

La configuració és el següent aspecte més conseqüent de l’entorn de l’aplicació. La configuració determina tant com l’aplicació es comprimeix en una infraestructura determinada com com la infraestructura és compatible amb l’aplicació subjacent.

Les dependències són tots els diferents mòduls o sistemes dels quals depèn una aplicació, des de biblioteques fins a serveis o altres aplicacions.

El avantatge d’utilitzar el subministrament d’ambients automatitzat de la següent manera;

  • Redueix la complexitat, permetent que els equips de DevOps treballin a un nivell més alt d’abstracció.
  • Major estabilitat permetent a les aplicacions respondre dinàmicament al seu desplegament.
  • Major flexibilitat desacoblant la gestió de la configuració de l’entorn d’allotjament específic de l’aplicació.

Tenim moltes eines disponibles al mercat, ja sigui de codi obert o empresarial que puguem utilitzar per proveir automatitzadament les tres àrees esmentades anteriorment;

6.Establir l'estructura d'eines de DevOps i proporcionar-lo com autoservei

Un cop definits els objectius i processos d’adopció de DevOps, podem determinar el conjunt d’eines necessari per complir els processos. Assegureu-vos que els equips de desenvolupament i informàtica treballin conjuntament per decidir sobre les eines adequades a l'organització. Amb qualsevol nova eina que s’introdueixi, cal formar els treballadors existents. També és essencial que les eines compleixin els requisits de seguretat i estiguin ben integrades amb els recursos i serveis existents.

** Només heu d'indicar algunes cadenes d'eines disponibles al mercat per a les seccions anteriors.

7. Accelerar la gestió del llançament

Un cop definit el nostre entorn, els líders de DevOps han de crear un pipeline d’alliberament adequat que necessitem un disparador automàtic per al desplegament, quan calgui una porta d’aprovació prèvia a la implementació i quan s’hagi de situar l’etapa QA / testing. La imatge de sota mostra un pipeline de llançament bàsic amb desplegament automàtic combinat i manual;

Un cop tingueu un pipeline d’alliberament adequat, l’automatització de l’edificació, la integració, les proves i el lliurament i altres processos, reduirà les activitats humanes en cada llançament, així com la quantitat de gestió i coordinació necessària.

Com que l’acceleració del desenvolupament s’ha convertit en un avantatge competitiu, l’equip DevOps ha intentat permetre la integració contínua i la distribució contínua (CI / CD). CI / CD ajuda els desenvolupadors i les operacions informàtiques a superar una molèstia important en el procés de desenvolupament i prova de programari. Amb el pas dels anys, el desenvolupament de programari ha migrat des del nivell d’empresa, on hi ha recursos amplis, cap a equips de desenvolupament més reduïts que corren per mantenir el ritme amb la demanda generada de milers de milions de telèfons intel·ligents i altres dispositius i plataformes mòbils de consum. A continuació es mostra un exemple de pipeline CI / CD amb la combinació de cadenes d’eines disponibles;

En el nostre cas, optem per utilitzar una combinació d’eines ja que sembla la millor solució per a les nostres complicades necessitats. La majoria dels equips que desenvolupen productes empresarials es beneficiarien d’un plantejament innovador. La nostra pila d'eines consta de,

  1. Atlassian JIRA: una eina per a la col·laboració entre equips del Product backlog, Sprint Planning i Informe de llançament i el funcionament de l'equip Agile en cada sprint.
  2. Github: un sistema de control de versions distribuït (DVCS) on el desenvolupador es comunica entre ells i col·labora per millorar el codi de característica del producte i la visibilitat dels canvis i versions de codis. Qualsevol canvi ha de ser revisat per altres desenvolupadors o el revisor de codis que ha fet que el codi sigui més net i que tingui menys error / error.
  3. Azure DevOps: és una eina que utilitzem per orquestrar el nostre pipeline CI / CD i també és el lloc on es manté més col·laboració entre DevOps Engineer, Developer, Release Manager i l'equip de QA. També és el lloc on es produeixen integracions per poder lliurar un producte amb bona qualitat, és per això que tenim anàlisis de seguretat i proves de control de qualitat abans de desplegar-nos al medi de producció.
  4. Datadog: és una eina de control que amb Datadog pot supervisar conjuntament els servidors, els núvols, les mètriques, les aplicacions i el equip. És com una parada única per a tot tipus de monitors per al vostre entorn i productes.

Un pipeline CI / CD eficient pot millorar significativament el temps de comercialització i disposar de mantenir l'estabilitat i la qualitat del programari distribuït.

8. Automatització de les proves

DevOps promou l’automatització i els seus objectius són fer la màxima automatització possible de totes les tasques de cada dia que no necessiten intervencions humanes. Afegir experts de QA a la composició de l’equip DevOps ajudarà l’equip a decidir el millor enfocament o les eines de prova que es poden automatitzar. Les eines d’automatització funcionen generalment quan es tracta d’errors d’errors d’aplicació o sistema, però les proves de QA fan un treball molt millor de la prova d’ús i facilitat de llançament.

La integració de proves contínues automatitzades al vostre pipeline CI / CD requereix una aplicació de prova d'aplicació fàcil d'integrar amb els accessoris de creació, automatització de proves i CI / CD que ja utilitzeu i que compta amb una àmplia compatibilitat amb l'API web. El avantatge d’utilitzar proves contínues automatitzades de la següent manera:

Estabilitat. L'ajuda a aplicar els requisits de qualitat i seguretat de forma més coherent. Si enregistreu una prova de seguretat manual i la automatitzeu, es converteix en un requisit de seguretat que podeu aplicar a totes les compilacions.

Velocitat. Amb les proves automàtiques continuades alimentades amb eines escalables, els desenvolupadors poden trobar i ajustar els problemes en temps real durant tot el SDLC. Si ho fa, agilitza el desenvolupament d'aplicacions i evita els errors comuns a les proves manuals.

Escala. Per escalar les proves manuals, cal més provadors manuals. Per escalar les proves automatitzades, només necessiteu més aplicacions i versions per provar-les.

Conclusió

L’adopció de DevOps és un viatge que hauria de començar amb una anàlisi de l’arquitectura i els objectius de l’organització. Resoldre aquests reptes comuns en l’adopció de DevOps farà que la transformació sigui molt més suau. Durant un període, cada equip o persona de l’organització s’acostumarà als canvis DevOps i s’adaptarà als processos d’aprenentatge continu. Una vegada que els equips de desenvolupament, operació i gestió han après a cooperar, s’ajudaran automàticament i col·laboraran estretament amb els objectius d’adopció de DevOps.