Les pràctiques de DevOps funcionen. N'estàvem convençuts nosaltres mateixos quan vam reduir el temps d'instal·lació del llançament en 10 vegades. Al sistema de perfils FIS, que fem servir a VTB, la instal·lació triga ara 90 minuts en lloc de 10. El temps de creació de llançament ha disminuït de dues setmanes a dos dies. El nombre de defectes persistents d'implementació s'ha reduït gairebé al mínim. Per allunyar-nos del "treball manual" i eliminar la dependència del venedor, vam haver de treballar amb crosses i trobar solucions inesperades. A sota del tall hi ha una història detallada sobre com vam crear un desenvolupament intern complet.
Pròleg: DevOps és una filosofia
Durant l'últim any, hem treballat molt per organitzar el desenvolupament intern i la implementació de les pràctiques DevOps a VTB:
- Hem construït processos de desenvolupament intern per a 12 sistemes;
- Vam posar en marxa 15 canonades, quatre de les quals es van portar a la producció;
- 1445 escenaris de prova automatitzats;
- Hem implementat amb èxit una sèrie de versions preparades per equips interns.
Un dels més difícils d'organitzar el desenvolupament intern i la implementació de les pràctiques DevSecOps va resultar ser el sistema de perfils FIS: un processador de productes minoristes en un DBMS no relacional. No obstant això, vam poder crear el desenvolupament, llançar el pipeline, instal·lar paquets individuals sense llançament al producte i vam aprendre a muntar versions. La tasca no va ser fàcil, però interessant i sense restriccions òbvies en la implementació: aquí teniu el sistema: heu de crear un desenvolupament intern. L'única condició és utilitzar el CD abans d'un entorn productiu.
Al principi, l'algoritme d'implementació semblava senzill i clar:
- Desenvolupem experiència en desenvolupament inicial i aconseguim un nivell acceptable de qualitat de l'equip de codi sense defectes greus;
- Ens integrem en els processos existents tant com sigui possible;
- Per transferir codi entre etapes òbvies, tallem una canonada i empenyem un dels seus extrems cap a la continuació.
Durant aquest temps, l'equip de desenvolupament de la mida requerida ha de desenvolupar habilitats i augmentar la quota de la seva contribució a les versions fins a un nivell acceptable. I ja està, podem considerar la tasca completada.
Sembla ser que aquest és un camí completament eficient energèticament cap al resultat requerit: aquí teniu DevOps, aquí teniu les mètriques de rendiment de l'equip, aquí teniu l'experiència acumulada... Però a la pràctica, vam rebre una altra confirmació que DevOps encara es tracta de filosofia. , i no "adjuntat al procés gitlab, ansible, nexus i més avall a la llista".
Després d'haver analitzat una vegada més el pla d'acció, ens vam adonar que estàvem construint una mena de proveïdor d'externalització dins nostre. Per tant, es va afegir la reenginyeria de processos a l'algorisme descrit anteriorment, així com el desenvolupament de l'experiència al llarg de tota la ruta de desenvolupament per aconseguir un paper protagonista en aquest procés. No és l'opció més fàcil, però aquest és el camí del desenvolupament ideològicament correcte.
On comença el desenvolupament intern?
No era el sistema més amigable per treballar. Arquitectònicament, era un gran SGBD no relacional, constava de molts objectes executables separats (scripts, procediments, lots, etc.), que s'anomenaven segons calia i funcionava segons el principi d'una caixa negra: rep una sol·licitud i problemes. una resposta. Altres dificultats que cal destacar són:
- Llenguatge exòtic (MUMPS);
- Interfície de consola;
- Falta d'integració amb eines i marcs d'automatització populars;
- Volum de dades en desenes de terabytes;
- Càrrega de més de 2 milions d'operacions per hora;
- Importància - crític empresarial.
Al mateix temps, no hi havia cap dipòsit de codi font al nostre costat. En absolut. Hi havia documentació, però tots els coneixements i competències clau estaven del costat d'una organització externa.
Vam començar a dominar el desenvolupament del sistema gairebé des de zero, tenint en compte les seves característiques i la seva baixa distribució. Va començar l'octubre de 2018:
- Estudiar la documentació i els fonaments bàsics de la generació de codi;
- Hem estudiat el curs breu sobre desenvolupament rebut del venedor;
- Dominar les habilitats inicials de desenvolupament;
- Hem compilat un manual de formació per als nous membres de l'equip;
- Vam acordar incloure l'equip en mode "combat";
- S'ha resolt el problema amb el control de qualitat del codi;
- Hem organitzat un estand per al desenvolupament.
Vam passar tres mesos desenvolupant experiència i submergint-nos en el sistema, i des de principis del 2019, el desenvolupament intern va començar el seu moviment cap a un futur brillant, de vegades amb dificultat, però amb confiança i intencionalitat.
Migració de repositoris i autotests
La primera tasca de DevOps és el repositori. Ràpidament vam acordar proporcionar accés, però va ser necessari migrar des del SVN actual amb una branca troncal al nostre Git objectiu amb la transició a un model de diverses branques i desenvolupament de Git Flow. També tenim 2 equips amb infraestructura pròpia, més part de l'equip del venedor a l'estranger. Vaig haver de viure amb dos Gits i assegurar la sincronització. En aquesta situació, era el menor dels dos mals.
La migració del repositori es va ajornar repetidament; només es va completar a l'abril, amb l'ajuda de companys de primera línia. Amb Git Flow, vam decidir mantenir les coses senzilles per començar i vam establir l'esquema clàssic amb hotfix, desenvolupament i llançament. Van decidir abandonar el mestre (també conegut com a prod). A continuació us explicarem per què aquesta opció ens va resultar òptima. Com a treballador es va utilitzar un repositori extern pertanyent al venedor, comú per a dos equips. Es sincronitzava amb el repositori intern segons una programació. Ara amb Git i Gitlab era possible automatitzar processos.
El problema de les proves automàtiques es va resoldre amb una facilitat sorprenent: ens van proporcionar un marc ja preparat. Tenint en compte les peculiaritats del sistema, cridar una operació independent era una part comprensible del procés empresarial i, al mateix temps, servia com a prova d'unitat. Només quedava preparar les dades de la prova i establir l'ordre desitjat per cridar els scripts i avaluar els resultats. A mesura que s'omplia la llista d'escenaris, formada a partir de les estadístiques de funcionament, la criticitat dels processos i la metodologia de regressió existent, van començar a aparèixer proves automàtiques. Ara podríem començar a construir el gasoducte.
Com era: el model abans de l'automatització
El model existent del procés d'implementació és una història a part. Cada modificació es va transferir manualment com un paquet d'instal·lació incremental independent. Després va venir el registre manual a Jira i la instal·lació manual en entorns. Per als paquets individuals, tot semblava clar, però amb la preparació del llançament, les coses es van complicar més.
El muntatge es realitzava a nivell de lliuraments individuals, que eren objectes independents. Qualsevol canvi és un nou lliurament. Entre altres coses, es van afegir de 60 a 70 versions tècniques als 10-15 paquets de la composició del llançament principal: versions obtingudes en afegir o excloure alguna cosa del llançament i reflectir els canvis en les vendes fora de les versions.
Els objectes dels lliuraments es superposaven entre ells, especialment en el codi executable, que era menys de la meitat únic. Hi havia moltes dependències tant del codi ja instal·lat com del que s'acabava de planificar la instal·lació.
Per obtenir la versió requerida del codi, calia seguir estrictament l'ordre d'instal·lació, durant el qual els objectes es van reescriure físicament moltes vegades, unes 10-12 vegades.
Després d'instal·lar un lot de paquets, vaig haver de seguir manualment les instruccions per inicialitzar la configuració. La versió va ser muntada i instal·lada pel venedor. La composició del llançament es va aclarir gairebé abans del moment de la implementació, que va comportar la creació de paquets de "desacoblament". Com a resultat, una part important dels subministraments es va traslladar d'alliberament a llançament amb la seva pròpia cua de "desacoblaments".
Ara està clar que amb aquest enfocament, muntant el trencaclosques de llançament a nivell de paquet, una única branca mestra no tenia cap significat pràctic. La instal·lació en producció va requerir d'una hora i mitja a dues hores de treball manual. És bo que almenys a nivell d'instal·lador s'especifiqui l'ordre de processament dels objectes: s'introduïen camps i estructures abans que les dades i els procediments. Tanmateix, això només funcionava dins d'un paquet separat.
El resultat lògic d'aquest enfocament van ser els defectes d'instal·lació obligatoris en forma de versions tortes d'objectes, codi innecessari, instruccions que falten i influències mútues no explicades dels objectes, que es van eliminar febrilment després del llançament.
Primeres actualitzacions: commit muntatge i lliurament
L'automatització va començar transmetent codi a través d'una canonada al llarg d'aquesta ruta:
- Recollir el lliurament acabat de l'emmagatzematge;
- Instal·leu-lo en un entorn dedicat;
- Executar autotests;
- Avaluar el resultat de la instal·lació;
- Truqueu a la canalització següent al costat de l'ordre de prova.
La següent canalització hauria de registrar la tasca a Jira i esperar que les ordres es distribueixin als bucles de prova seleccionats, que depenen del moment de la implementació de la tasca. Activador: una carta sobre la preparació per al lliurament a una adreça determinada. Això, per descomptat, era una crossa òbvia, però havia de començar per algun lloc. El maig de 2019 es va iniciar la transferència de codi amb comprovacions dels nostres entorns. El procés ha començat, només queda posar-lo en una forma decent:
- Cada modificació es realitza en una branca separada, que correspon al paquet d'instal·lació i es fusiona amb la branca mestra de destinació;
- El desencadenant de llançament del pipeline és l'aparició d'una nova confirmació a la branca mestra mitjançant una sol·licitud de combinació, que tanquen els mantenedors de l'equip intern;
- Els dipòsits es sincronitzen un cop cada cinc minuts;
- S'inicia el muntatge del paquet d'instal·lació, utilitzant l'assemblador rebut del venedor.
Després d'això, ja existien passos per comprovar i transferir el codi, per llançar la canonada i muntar al nostre costat.
Aquesta opció es va posar en marxa al juliol. Les dificultats de la transició van provocar una certa insatisfacció entre el venedor i la primera línia, però durant el mes següent vam aconseguir eliminar totes les aspres i establir un procés entre els equips. Ara tenim muntatge per compromís i lliurament.
A l'agost, vam aconseguir completar la primera instal·lació d'un paquet separat en producció mitjançant el nostre pipeline, i des de setembre, sense excepció, totes les instal·lacions de paquets individuals sense llançament es van realitzar mitjançant la nostra eina de CD. A més, vam aconseguir una part de les tasques internes en el 40% de la composició de la versió amb un equip més petit que el venedor; això és un èxit definitiu. La tasca més seriosa restava: muntar i instal·lar el llançament.
La solució final: paquets d'instal·lació acumulats
Enteníem perfectament que l'escriptura de les instruccions del venedor era una automatització tan gran; vam haver de replantejar el procés en si. La solució era òbvia: recollir un subministrament acumulat de la branca de llançament amb tots els objectes de les versions requerides.
Vam començar amb una prova de concepte: vam muntar manualment el paquet de llançament segons el contingut de la implementació passada i el vam instal·lar als nostres entorns. Tot va funcionar, el concepte va resultar viable. A continuació, vam resoldre el problema d'escripturar la configuració d'inicialització i incloure'ls a la confirmació. Vam preparar un paquet nou i el vam provar en entorns de prova com a part de l'actualització del contorn. La instal·lació va tenir èxit, tot i que amb una àmplia gamma de comentaris de l'equip d'implementació. Però el més important és que ens van donar el vistiplau per entrar en producció al llançament de novembre amb el nostre muntatge.
Quan quedava poc més d'un mes, els subministraments escollits a mà indicaven clarament que el temps s'acabava. Van decidir fer la compilació des de la branca de llançament, però per què s'hauria de separar? No tenim cap producte, i les sucursals existents no són bones: hi ha molt de codi innecessari. Necessitem urgentment retallar els productes que m'agradan, i això són més de tres mil commits. Muntar a mà no és una opció en absolut. Hem esbossat un script que s'executa pel registre d'instal·lació del producte i recull commits a la branca. La tercera vegada va funcionar correctament, i després d'"acabar amb un fitxer" la branca estava a punt.
Vam escriure el nostre propi constructor per al paquet d'instal·lació i el vam acabar en una setmana. Després vam haver de modificar l'instal·lador des de la funcionalitat bàsica del sistema, ja que és de codi obert. Després d'una sèrie de controls i modificacions, el resultat es va considerar reeixit. Mentrestant, va prendre forma la composició del llançament, per a la correcta instal·lació de la qual va ser necessari alinear el circuit de prova amb el de producció, i es va escriure un guió separat per a això.
Naturalment, hi va haver molts comentaris sobre la primera instal·lació, però en general el codi va funcionar. I després de la tercera instal·lació, tot va començar a semblar bé. El control de la composició i el control de versions dels objectes es van controlar per separat en mode manual, cosa que en aquesta etapa estava bastant justificada.
Un repte addicional va ser el gran nombre de no llançaments que calia tenir en compte. Però amb la branca semblant a Prod i Rebase, la tasca es va fer transparent.
Primera vegada, ràpid i sense errors
Ens vam acostar al llançament amb una actitud optimista i amb més d'una desena d'instal·lacions d'èxit en diferents circuits. Però, literalment, un dia abans de la data límit, va resultar que el venedor no havia completat el treball per preparar el llançament per a la instal·lació de la manera acceptada. Si per algun motiu la nostra compilació no funciona, el llançament es veurà interromput. A més, gràcies als nostres esforços, que és especialment desagradable. No teníem manera de retirar-nos. Per tant, vam pensar en opcions alternatives, vam preparar plans d'acció i vam començar la instal·lació.
Sorprenentment, tot el llançament, format per més de 800 objectes, va començar correctament, la primera vegada i en només 10 minuts. Vam passar una hora revisant els registres buscant errors, però no n'hem trobat cap.
Tot el dia següent hi va haver silenci al xat de llançament: sense problemes d'implementació, versions tortes o codi "inapropiat". Fins i tot va ser d'alguna manera incòmode. Més tard, van sorgir alguns comentaris, però en comparació amb altres sistemes i experiència anterior, el seu nombre i prioritat van ser notablement inferiors.
Un efecte addicional de l'efecte acumulat va ser un augment de la qualitat del muntatge i les proves. A causa de les múltiples instal·lacions de la versió completa, es van identificar defectes de compilació i errors de desplegament de manera oportuna. Les proves en configuracions de llançament completes van permetre identificar addicionalment defectes en la influència mútua d'objectes que no apareixien durant les instal·lacions incrementals. Sens dubte va ser un èxit, sobretot tenint en compte la nostra contribució del 57% al llançament.
Resultats i conclusions
En menys d'un any hem aconseguit:
- Construeix un desenvolupament intern complet mitjançant un sistema exòtic;
- Eliminar la dependència crítica del proveïdor;
- Llançar CI/CD per a un llegat molt hostil;
- Elevar els processos d'implementació a un nou nivell tècnic;
- Redueix significativament el temps de desplegament;
- Reduir significativament el nombre d'errors d'implementació;
- Declareu-vos amb confiança com un expert líder en desenvolupament.
Per descomptat, gran part del que es descriu sembla una merda, però aquestes són les característiques del sistema i les limitacions del procés que hi ha. En aquests moments, els canvis afectaven els productes i serveis del perfil d'IS (comptes mestres, targetes de plàstic, comptes d'estalvi, depósito en garantia, préstecs en efectiu), però potencialment l'enfocament es pot aplicar a qualsevol SI per al qual s'estableixi la tasca d'implementar pràctiques DevOps. El model acumulatiu es pot replicar de manera segura per a les implementacions posteriors (incloses les que no es publiquen) a partir de molts lliuraments.
Font: www.habr.com