Una vegada vam subministrar un sistema de gestió de documents electrònics a un client en una instal·lació. I després a un altre objecte. I un més. I al quart, i al cinquè. Ens vam deixar portar tant que vam arribar a 10 objectes distribuïts. Va resultar poderós... sobretot quan vam arribar a oferir els canvis. Com a part del lliurament al circuit de producció, 5 escenaris del sistema de proves van requerir finalment 10 hores i 6-7 empleats. Aquests costos ens van obligar a fer lliuraments el més poques vegades possible. Després de tres anys de funcionament, no ho vam aguantar i vam decidir donar vida al projecte amb una mica de DevOps.
Ara totes les proves es fan en 3 hores, i hi participen 3 persones: un enginyer i dos provadors. Les millores s'expressen clarament en números i condueixen a una reducció de l'estimat TTM. Segons la nostra experiència, hi ha molts més clients que poden beneficiar-se de DevOps que els que fins i tot en coneixen. Per tant, per apropar DevOps a les persones, hem desenvolupat un constructor senzill, del qual parlarem amb més detall en aquest post.
Ara t'ho expliquem amb més detall. Una empresa energètica està desplegant un sistema de gestió de documents tècnics a 10 grans instal·lacions. No és fàcil navegar per projectes d'aquesta escala sense DevOps, perquè una gran part del treball manual retarda molt el treball i també redueix la qualitat: tot el treball manual està ple d'errors. D'altra banda, hi ha projectes on només hi ha una instal·lació, però cal que tot funcioni de manera automàtica, constant i sense errors, per exemple, els mateixos sistemes de flux de documents en grans organitzacions monolítices. En cas contrari, algú farà la configuració manualment, s'oblidarà de les instruccions de desplegament i, com a resultat, en producció, la configuració es perdrà i tot es col·lapsarà.
Normalment treballem amb el client mitjançant un contracte, i en aquest cas els nostres interessos divergeixen lleugerament. El client mira el projecte estrictament dins del pressupost i de les especificacions tècniques. Pot ser difícil explicar-li els beneficis de diverses pràctiques de DevOps que no estan incloses a les especificacions tècniques. Què passa si està interessat en llançaments ràpids amb valor comercial afegit o en construir un pipeline d'automatització?
Per desgràcia, quan es treballa amb un cost prèviament aprovat, aquest interès no sempre es troba. A la nostra pràctica, hi va haver un cas en què vam haver de recollir el desenvolupament d'un contractista sense escrúpols i descuidat. Va ser terrible: no hi havia codis font actualitzats, la base de codis d'un mateix sistema era diferent en diferents instal·lacions, la documentació era parcialment absent i parcialment de mala qualitat. Per descomptat, el client no tenia control sobre el codi font, el muntatge, les versions, etc.
Fins ara, no tothom sap de DevOps, però tan bon punt parlem dels seus avantatges, de l'estalvi real de recursos, els ulls de tots els clients s'il·luminen. Així, el nombre de sol·licituds que inclouen DevOps augmenta amb el temps. Aquí, per parlar fàcilment el mateix idioma amb els clients, hem de connectar ràpidament els problemes empresarials i les pràctiques de DevOps que ajudin a construir un pipeline de desenvolupament adequat.
Així doncs, tenim un conjunt de problemes d'una banda, tenim coneixements, pràctiques i eines de DevOps de l'altra. Per què no compartir l'experiència amb tothom?
Creació d'un constructor DevOps
Agile té el seu propi manifest. ITIL té la seva pròpia metodologia. DevOps és menys afortunat: encara no ha adquirit plantilles ni estàndards. Encara que determinar la maduresa de les empreses a partir d'una avaluació del seu desenvolupament i pràctiques operatives.
Afortunadament, la coneguda empresa Gartner el 2014 i va analitzar les pràctiques clau de DevOps i les relacions entre elles. A partir d'això, vaig publicar una infografia:
Ho vam prendre com a base per al nostre . Cadascuna de les quatre àrees té un conjunt d'eines: les vam recopilar en una base de dades, vam identificar les més populars, vam identificar els punts d'integració i els mecanismes d'optimització adequats. En total va resultar 36 pràctiques i 115 eines, una quarta part dels quals són de codi obert o programari lliure. A continuació, parlarem del que hem aconseguit en cada àmbit i, a tall d'exemple, de com es va implantar en el projecte de creació de gestió documental tècnica, amb el qual vam iniciar el post.
Процессы
En el famós projecte EDMS, el sistema de gestió de documentació tècnica es va desplegar segons el mateix esquema en cadascun dels 10 objectes. La instal·lació inclou 4 servidors: servidor de bases de dades, servidor d'aplicacions, indexació de text complet i gestió de continguts. A la instal·lació, operen dins d'un sol node i es troben al centre de dades de les instal·lacions. Tots els objectes difereixen lleugerament en la infraestructura, però això no interfereix amb la interacció global.
Primer, segons les pràctiques de DevOps, vam automatitzar la infraestructura localment, després vam portar el lliurament al circuit de prova i després al producte del client. Cada procés s'ha treballat pas a pas. La configuració de l'entorn es fixa al sistema de codi font, tenint en compte que el kit de distribució està compilat per a l'actualització automàtica. En cas de canvis de configuració, els enginyers només han de fer els canvis adequats al sistema de control de versions, i després l'actualització automàtica es farà sense problemes.
Gràcies a aquest enfocament, el procés de prova s'ha simplificat molt. Anteriorment, el projecte tenia provadors que no feien més que actualitzar manualment els estands. Ara acaben de venir, veure que tot funciona i fer coses més útils. Cada actualització es prova automàticament, des del nivell superficial fins a l'automatització de l'escenari empresarial. Els resultats es publiquen com a informes separats a TestRail.
Cultura
L'experimentació contínua s'explica millor mitjançant l'exemple de disseny de proves. Provar un sistema que encara no existeix és un treball creatiu. Quan escriu un pla de proves, has d'entendre com provar correctament i quines branques seguir. I també trobar un equilibri entre temps i pressupost per determinar el nombre òptim de controls. És important triar exactament les proves necessàries, pensar en com interactuarà l'usuari amb el sistema, tenir en compte l'entorn i els possibles factors externs. És impossible prescindir de l'experimentació contínua.
Ara sobre la cultura de la interacció. Anteriorment, hi havia dues parts oposades: enginyers i desenvolupadors. Els desenvolupadors van dir: "No ens importa com es posarà en marxa. Sou enginyers, sou intel·ligents, assegureu-vos que funcioni sense fallades". Els enginyers van respondre: "Vostès desenvolupadors sou massa descuidats. Anem més amb compte i reproduirem els vostres llançaments amb menys freqüència. Perquè cada vegada que ens doneu un codi amb fuites, no ens queda clar com interactuem".. Aquest és un problema d'interacció cultural que s'estructura de manera diferent des d'una perspectiva de DevOps. Aquí, tant enginyers com desenvolupadors formen part d'un únic equip centrat en el canvi constant, però alhora de programari fiable.
Dins del mateix equip, els especialistes estan decidits a ajudar-se mútuament. Com era abans? Per exemple, s'estaven preparant unes instruccions de desplegament gruixudes, d'unes 50 pàgines, l'enginyer el va llegir, no va entendre res, va maleir i va demanar al desenvolupador a les tres de la matinada que comentés. El desenvolupador va comentar i també va maleir: al final, ningú estava content. A més, naturalment, hi va haver alguns errors, perquè no pots recordar-ho tot a les instruccions. I ara l'enginyer, juntament amb el desenvolupador, està escrivint un script per al desplegament automatitzat de la infraestructura de programari d'aplicacions. I es parlen pràcticament en la mateixa llengua.
Persones
La mida de l'equip ve determinada per l'abast de l'actualització. L'equip es recluta durant la formació del lliurament; inclou aquells interessats de l'equip general del projecte. A continuació, s'escriu un pla d'actualització amb els responsables de cada etapa, i l'equip informa a mesura que avança. Tots els membres de l'equip són intercanviables. Com a part de l'equip, també tenim un desenvolupador de còpia de seguretat, però gairebé mai no s'ha de connectar.
Tecnologia
Al diagrama de tecnologia, es destaquen alguns punts, però a sota hi ha un munt de tecnologies: podríeu publicar un llibre sencer amb les seves descripcions. Així que destacarem el més interessant.
La infraestructura com a codi
Ara, probablement, aquest concepte no sorprendrà ningú, però abans les descripcions d'infraestructures deixaven molt a desitjar. , els entorns de prova eren únics, eren estimats i estimats, les partícules de pols se'n van expulsar.
Avui dia ningú té por d'experimentar. Hi ha imatges bàsiques de màquines virtuals, hi ha escenaris ja preparats per desplegar entorns. Totes les plantilles i els scripts s'emmagatzemen en un sistema de control de versions i s'actualitzen ràpidament. Anteriorment, quan era necessari lliurar un paquet a un estand, apareixia un buit de configuració. Ara només cal afegir una línia al codi font.
A més dels scripts d'infraestructura i pipelines, també s'utilitza l'enfocament Documentation as a Code per a la documentació. Gràcies a això, és fàcil connectar persones noves al projecte, introduir-les al sistema a partir de les funcions descrites, per exemple, al pla de proves, i també reutilitzar casos de prova.
Lliurament i seguiment continus
sobre DevOps, vam parlar de com vam seleccionar eines per implementar el lliurament i el seguiment continus. Sovint no cal reescriure res: n'hi ha prou amb utilitzar scripts escrits anteriorment, crear correctament la integració entre components i crear una consola de gestió comuna. I tots els processos es poden iniciar mitjançant un botó o programació.
En anglès hi ha diferents conceptes, Continuous Delivery i Continuous Deployment. Tots dos es poden traduir com "entrega continua", però de fet hi ha una lleugera diferència entre ells. En el nostre projecte per al flux de documents tècnics d'una empresa d'energia distribuïda, més aviat, s'utilitza el lliurament, quan la instal·lació per a la producció es produeix sota comanda. A Deployment, la instal·lació es fa automàticament. El lliurament continu en aquest projecte s'ha convertit en general part central de DevOps.
En general, en recopilar determinats paràmetres, podeu entendre clarament per què les pràctiques DevOps són útils. I transmetre-ho a la direcció, a qui li agraden molt els números. El nombre total de llançaments, el temps d'execució de les etapes de l'script, la proporció de llançaments reeixits, tot això afecta directament el temps favorit de tothom per sortir al mercat, és a dir, el temps des d'un compromís amb el sistema de control de versions fins al llançament d'una versió en un entorn de producció. Amb la implementació de les eines necessàries, els enginyers reben per correu electrònic indicadors valuosos i el responsable del projecte els veu al tauler. D'aquesta manera podeu avaluar immediatament els beneficis de les noves eines. I podeu provar-los a la vostra infraestructura mitjançant el dissenyador DevOps.
Qui necessitarà el nostre ?
No fingim: per començar, ens va ser útil. Com ja hem dit, cal parlar el mateix idioma amb el client, i amb l'ajuda del dissenyador de DevOps podem esbossar ràpidament les bases d'aquesta conversa. Els especialistes empresarials podran avaluar per si mateixos què necessiten i així desenvolupar-se més ràpidament. Hem intentat que el dissenyador sigui el més detallat possible, afegint un munt de descripcions perquè qualsevol usuari entengui què està escollint.
El format del dissenyador permet tenir en compte els desenvolupaments existents de l'empresa en processos de construcció i automatització. No cal enderrocar-ho tot i reconstruir-lo si només podeu triar solucions que s'integrin bé amb els processos existents i que simplement puguin omplir els buits.
Potser el vostre desenvolupament ja s'ha mogut a un nivell superior i la nostra eina semblarà massa "del capità". Però el trobem útil per a nosaltres mateixos i esperem que sigui útil a alguns dels lectors. Us ho recordem al dissenyador: si alguna cosa, rebeu el diagrama immediatament després d'introduir les dades inicials. Agrairem els vostres comentaris i addicions.
Font: www.habr.com