Imatge:
Hola a tots! Som enginyers d'automatització de l'empresa i donem suport al desenvolupament dels productes de l'empresa: donem suport a tot el pipeline de muntatge, des del compromís d'una línia de codi per part dels desenvolupadors fins a la publicació de productes acabats i llicències en servidors d'actualització. De manera informal, ens diem enginyers de DevOps. En aquest article volem parlar de les etapes tecnològiques del procés de producció del programari, de com les veiem i de com les classifiquem.
A partir del material aprendràs sobre la complexitat de coordinar el desenvolupament multiproducte, què és un mapa tecnològic i com ajuda a racionalitzar i replicar solucions, quines són les etapes i passos principals del procés de desenvolupament, com són les àrees de responsabilitat. entre DevOps i els equips de la nostra empresa.
Sobre Chaos i DevOps
En resum, el concepte de DevOps inclou eines i serveis de desenvolupament, així com metodologies i bones pràctiques per al seu ús. Destaquem el global el propòsit de la implementació de les idees DevOps a la nostra empresa: es tracta d'una reducció consistent del cost de producció i manteniment dels productes en termes quantitatius (hores-home o hores màquina, CPU, RAM, Disc, etc.). La manera més senzilla i òbvia de reduir el cost global de desenvolupament a nivell de tota l'empresa és minimitzant el cost de realitzar tasques típiques en sèrie en totes les etapes de producció. Però quines són aquestes etapes, com separar-les del procés general, en quins passos consisteixen?
Quan una empresa desenvolupa un producte, tot queda més o menys clar: normalment hi ha un full de ruta i un esquema de desenvolupament comú. Però què fer quan la línia de productes s'amplia i hi ha més productes? A primera vista, tenen processos i línies de muntatge similars, i comença el joc de "trobar X diferències" en registres i scripts. Però, què passa si ja hi ha més de 5 projectes en desenvolupament actiu i es requereix suport per a diverses versions desenvolupades durant diversos anys? Volem reutilitzar el màxim nombre possible de solucions en els pipelines de productes o estem preparats per gastar diners en un desenvolupament únic per a cadascun?
Com trobar un equilibri entre la singularitat i les solucions en sèrie?
Aquestes preguntes van començar a sorgir davant nostre cada cop més sovint des del 2015. El nombre de productes va créixer i vam intentar ampliar al mínim el nostre departament d'automatització (DevOps), que donava suport a les línies de muntatge d'aquests productes. Al mateix temps, volíem replicar tantes solucions com fos possible entre productes. Després de tot, per què fer el mateix en deu productes de diferents maneres?
Director de Desenvolupament: "Nois, podem avaluar d'alguna manera què fa DevOps per als productes?"
Nosaltres: "No ho sabem, no vam fer aquesta pregunta, però quins indicadors s'han de tenir en compte?"
Director de Desenvolupament: "Qui sap! Pensar…"
Com en aquella famosa pel·lícula: "Estic en un hotel! .." - "Uh... Em pots indicar el camí?" Reflexionant, vam arribar a la conclusió que primer cal decidir quins són els estats finals dels productes; aquest es va convertir en el nostre primer objectiu.
Aleshores, com analitzeu una dotzena de productes amb equips bastant grans de 10 a 200 persones i determineu mètriques mesurables en replicar solucions?
1:0 a favor del Chaos, o DevOps als omòplats
Vam començar amb un intent d'aplicar diagrames IDEF0 i diversos diagrames de processos empresarials de la sèrie BPwin. La confusió va començar després del cinquè quadrat de la següent etapa del proper projecte, i aquests quadrats per a cada projecte es poden dibuixar a la cua d'un pitó llarg amb més de 50 passos. Em sentia trist i volia udolar a la lluna, en general no encaixava.
Tasques típiques de producció
Modelar processos de producció és una feina molt complexa i minuciosa: cal recollir, processar i analitzar moltes dades de diversos departaments i cadenes de producció. Podeu llegir més sobre això a l'article "».
Quan vam començar a modelar el nostre procés de producció, teníem un objectiu específic: transmetre a tots els empleats implicats en el desenvolupament dels productes de la nostra empresa i als gestors de projectes:
- com els productes i els seus components, a partir de la confirmació d'una línia de codi, arriben al client en forma d'instal·ladors i actualitzacions,
- quins recursos es proporcionen per a cada etapa de producció de productes,
- quins serveis participen en cada etapa,
- com es delimiten les àrees de responsabilitat de cada etapa,
- quins contractes hi ha a l'entrada i a la sortida de cada etapa.
Fent clic a la imatge, s'obrirà a mida completa.
El nostre treball a l'empresa es divideix en diverses àrees funcionals. La direcció de la infraestructura es dedica a l'optimització del funcionament de tots els recursos "ferro" del departament, així com a l'automatització del desplegament de màquines virtuals i de l'entorn en elles. La direcció de la supervisió proporciona un control de rendiment del servei les 24 hores del dia; també oferim monitorització com a servei per als desenvolupadors. La direcció del flux de treball proporciona als equips eines per gestionar els processos de desenvolupament i proves, analitzar l'estat del codi i obtenir anàlisis dels projectes. I, finalment, la direcció webdev proporciona la publicació de versions als servidors d'actualització GUS i FLUS, així com la llicència de productes amb el servei LicenseLab. Per donar suport al canal de producció, configurem i mantenim molts serveis de suport diferents per als desenvolupadors (podeu escoltar històries sobre algunes d'elles a les trobades antigues: и). També desenvolupem eines d'automatització interna, entre elles .
Durant els últims cinc anys, el nostre treball ha acumulat moltes operacions rutinàries i del mateix tipus, i els nostres desenvolupadors d'altres departaments provenen principalment de l'anomenat tasques típiques, la solució de la qual està totalment o parcialment automatitzada, no causa dificultats per als intèrprets i no requereix grans quantitats de treball. Juntament amb les àrees líders, vam analitzar aquestes tasques i vam poder identificar categories individuals de treball, o etapes de producció, les etapes es van dividir en passos indivisibles i se sumen diverses etapes cadena de procés de producció.
L'exemple més senzill de cadena tecnològica són les etapes de muntatge, desplegament i prova de cadascun dels nostres productes dins de l'empresa. Al seu torn, per exemple, l'etapa de compilació consta de molts passos típics separats: descàrrega de fonts de GitLab, preparació de dependències i biblioteques de tercers, proves d'unitats i anàlisi de codi estàtic, execució d'un script de compilació a GitLab CI, publicació d'artefactes al repositori a Artifactory i generació de notes de versió mitjançant la nostra eina interna ChangelogBuilder.
Podeu llegir sobre les tasques típiques de DevOps als nostres altres articles sobre Habré: ""I"».
Es formen moltes cadenes de producció típiques procés de fabricació. L'enfocament estàndard per descriure processos és utilitzar models IDEF0 funcionals.
Un exemple de modelització d'un procés CI de fabricació
Hem prestat especial atenció al desenvolupament de projectes estàndard per a un sistema d'integració contínua. Això va permetre aconseguir la unificació de projectes, destacant els anomenats Esquema de creació de llançaments amb promocions.
Així és com funciona. Tots els projectes semblen típics: inclouen la configuració dels conjunts que cauen al repositori d'instantànies d'Artifactory, després del qual es despleguen i es posen a prova en bancs de proves, i després es promocionen al repositori de llançament. El servei Artifactory és un punt de distribució únic per a tots els artefactes de construcció entre equips i altres serveis.
Si simplifiquem i generalitzem molt el nostre esquema de llançament, inclou els passos següents:
- muntatge de productes multiplataforma,
- desplegament als bancs de proves,
- executar proves funcionals i altres,
- promoció de compilacions provades per alliberar repositoris a Artifactory,
- publicació de versions basades en servidors d'actualització,
- lliurament de muntatges i actualitzacions de producció,
- iniciar la instal·lació i actualització del producte.
Per exemple, considereu el model tecnològic d'aquest esquema de llançament típic (d'ara endavant simplement Model) en forma d'un model IDEF0 funcional. Reflecteix les principals etapes del nostre procés de CI. Els models IDEF0 utilitzen l'anomenat Notació ICOM (Input-Control-Output-Mechanism) per descriure quins recursos s'utilitzen en cada etapa, en funció de quines regles i requisits es realitza el treball, quina és la sortida i quins mecanismes, serveis o persones implementen una etapa concreta.
Fent clic a la imatge, s'obrirà a mida completa.
Per regla general, és més fàcil descompondre i detallar la descripció dels processos en models funcionals. Però a mesura que creix el nombre d'elements, cada cop es fa més difícil entendre alguna cosa en ells. Però en el desenvolupament real, també hi ha etapes auxiliars: monitorització, certificació de productes, automatització del flux de treball i altres. És a causa del problema d'escala que vam abandonar aquesta descripció.
Naixement de l'esperança
En un llibre, ens vam trobar amb mapes soviètics antics que descriuen processos tecnològics (que, per cert, encara s'utilitzen avui dia a moltes empreses i universitats de propietat estatal). Espereu, espereu, perquè també tenim un flux de treball!... Hi ha etapes, resultats, mètriques, requisits, indicadors, etc., etcètera... Per què no intenteu aplicar fulls de flux també als nostres pipelines de productes? Hi havia una sensació: “Això és! Hem trobat el fil adequat, és hora de tirar-lo bé!
En una taula senzilla, vam decidir registrar els productes per columnes i les etapes tecnològiques i els passos del pipeline de productes per files. Les fites són quelcom important, com ara un pas de creació de producte. I els passos són quelcom més petits i detallats, com ara el pas de descarregar el codi font al servidor de compilació o el pas de compilar el codi.
A les interseccions de les files i columnes del mapa, anotem els estats d'una etapa i producte específics. Per als estats, es va definir un conjunt d'estats:
- Sense informació - o inadequat. Cal analitzar la demanda d'una etapa del producte. O l'anàlisi ja s'ha fet, però l'etapa actualment no és necessària o no està justificada econòmicament.
- Posposat - o no rellevant en aquest moment. Cal una etapa en el pipeline, però no hi ha forces per a la implementació aquest any.
- Planificat. L'etapa està prevista per a la seva implantació aquest any.
- Implementat. L'etapa de la canonada s'implementa en el volum requerit.
L'ompliment de la taula va començar projecte per projecte. En primer lloc, es van classificar les etapes i passos d'un projecte i es van registrar els seus estats. Després van agafar el següent projecte, van arreglar-hi els estats i van afegir les etapes i els passos que faltaven en projectes anteriors. Com a resultat, vam obtenir les etapes i els passos de tot el nostre pipeline de producció i els seus estats en un projecte específic. Va resultar una cosa semblant a la matriu de competències del pipeline de productes. Vam anomenar aquesta matriu un mapa tecnològic.
Amb l'ajuda del mapa tecnològic, coordinem metrològicament raonablement amb els equips els plans de treball de l'any i els objectius que volem assolir entre tots: quines etapes afegim al projecte aquest any i quines deixem per a més endavant. A més, en el curs del treball, podem tenir millores en les etapes que hem completat només per a un producte. Després ampliem el nostre mapa i introduïm aquesta millora com una etapa o un nou pas, després analitzem per a cada producte i descobrim la viabilitat de replicar la millora.
Ens poden oposar: "Això està bé, per descomptat, només amb el temps el nombre de passos i etapes es farà de manera prohibitiva. Com ser?
Hem introduït descripcions estàndard i força completes dels requisits per a cada etapa i pas, de manera que tots els entenguin de la mateixa manera a l'empresa. Amb el pas del temps, a mesura que s'introdueixen millores, un pas pot ser absorbit en una altra etapa o pas, i aleshores s'"enfonsarà". Al mateix temps, tots els requisits i matisos tecnològics s'ajusten als requisits de l'etapa o pas de generalització.
Com avaluar l'efecte de la replicació de solucions? Utilitzem un enfocament extremadament senzill: atribuïm els costos de capital inicials per a la implementació d'una nova etapa als costos generals anuals del producte, i després dividim per tots en replicar.
Parts del desenvolupament ja es mostren com a fites i passos al mapa. Podem influir en la reducció del cost del producte mitjançant la introducció de l'automatització per a etapes típiques. Després d'això, considerem els canvis en les característiques qualitatives, les mètriques quantitatives i els beneficis rebuts pels equips (en hores-home o hores-màquina d'estalvi).
Mapa tecnològic del procés productiu
Si fem totes les nostres etapes i passos, els codifiquem amb etiquetes i els expandim en una cadena, serà molt llarg i incomprensible (la mateixa "cua de pitó" de la qual parlàvem al principi de l'article) :
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]Aquestes són les etapes de la creació de productes [Build], el desplegament dels servidors de prova [Deploy], les proves [Prova], la promoció de compilacions per alliberar repositoris basats en els resultats de les proves [Promocionar], la generació i la publicació de llicències [Llicència], la publicació [ Publicar] al servidor d'actualització GUS i lliurament als servidors d'actualització de FLUS, instal·lació i actualització dels components del producte a la infraestructura del client mitjançant Product Configuration Management [Instal·lació], així com la recollida de telemetria [Telemetria] dels productes instal·lats.
A més d'ells, es poden distingir etapes separades: monitorització de l'estat de la infraestructura [InfMonitoring], versions del codi font [SourceCodeControl], preparació de l'entorn de construcció [Prepare], gestió de projectes [Workflow], subministrament als equips d'eines de comunicació [Comunicació], certificació de producte [ Certificació] i garantir l'autosuficiència dels processos de CI [CISelfSufficiency] (per exemple, la independència de les assemblees d'Internet). Ni tan sols es tindran en compte desenes de passos dels nostres processos, perquè són molt específics.
Serà molt més fàcil entendre i veure tot el procés de producció si es presenta en el formulari mapa tecnològic; es tracta d'una taula en què s'escriuen en files les etapes de producció individuals i els passos descomposts del Model, i en columnes una descripció del que es fa en cada etapa o pas. El principal èmfasi es posa en els recursos que ofereix cada etapa, i en la delimitació de les àrees de responsabilitat.
El mapa per a nosaltres és una mena de classificador. Reflecteix les grans parts tecnològiques de la producció de productes. Gràcies a això, va ser més fàcil per al nostre equip d'automatització interactuar amb els desenvolupadors i planificar conjuntament la implementació de les etapes d'automatització, així com entendre quins costos laborals i recursos (humans i maquinari) seran necessaris per a això.
Dins de la nostra empresa, el mapa es genera automàticament a partir de la plantilla jinja com a fitxer HTML normal i després es penja al servidor de GitLab Pages. Es pot veure una captura de pantalla amb un exemple d'un mapa totalment generat .
Fent clic a la imatge, s'obrirà a mida completa.
En definitiva, el mapa tecnològic és una imatge generalitzada del procés productiu, que reflecteix blocs clarament classificats amb una funcionalitat típica.
Estructura del nostre full de ruta
El mapa consta de diverses parts:
- Àrea del títol: aquí hi ha una descripció general del mapa, s'introdueixen els conceptes bàsics, es defineixen els principals recursos i resultats del procés de producció.
- Tauler de control: aquí podeu controlar la visualització de dades per a productes individuals, es proporciona un resum de les etapes implementades i els passos en general per a tots els productes.
- Mapa tecnològic: una descripció tabular del procés tecnològic. Al mapa:
- es donen totes les etapes, passos i els seus codis;
- es fan descripcions breus i completes de les etapes;
- s'indiquen els recursos i serveis d'entrada utilitzats en cada etapa;
- s'indiquen els resultats de cada etapa i un pas separat;
- s'indica l'àrea de responsabilitat de cada etapa i pas;
- s'han determinat els recursos tècnics, com ara HDD (SSD), RAM, vCPU i les hores de treball necessàries per donar suport al treball en aquesta etapa, tant en el moment actual -un fet, com en el futur- un pla;
- per a cada producte, s'indica quines etapes o passos tecnològics per al mateix s'han implantat, previstes per a la seva implantació, irrellevants o no implementades.
Presa de decisions a partir del mapa tecnològic
Després d'examinar el mapa, és possible fer algunes accions, depenent del paper de l'empleat a l'empresa (gerent de desenvolupament, director de producte, desenvolupador o provador):
- entendre quines etapes falten en un producte o projecte real i valorar la necessitat de la seva implementació;
- delimitar les àrees de responsabilitat entre diversos departaments si treballen en diferents etapes;
- acordar els contractes a les entrades i sortides dels escenaris;
- integrar la seva etapa de treball en el procés de desenvolupament global;
- valorar amb més precisió la necessitat de recursos que proporcionen cadascuna de les etapes.
Resumint tot l'anterior
L'encaminament és versàtil, extensible i fàcil de mantenir. És molt més fàcil desenvolupar i mantenir una descripció dels processos d'aquesta forma que en un model IDEF0 acadèmic estricte. A més, una descripció tabular és més senzilla, més familiar i més ben estructurada que un model funcional.
Per a la implementació tècnica dels passos, disposem d'una eina interna especial CrossBuilder: una eina de capa entre sistemes CI, serveis i infraestructura. El desenvolupador no necessita tallar la seva bicicleta: al nostre sistema CI, n'hi ha prou amb executar un dels scripts (l'anomenada tasca) de l'eina CrossBuilder, que l'executarà correctament, tenint en compte les característiques de la nostra infraestructura. .
Resultats de
L'article va resultar ser força llarg, però això és inevitable quan es descriu el modelatge de processos complexos. Al final, m'agradaria arreglar breument les nostres idees principals:
- L'objectiu d'implementar idees DevOps a la nostra empresa és reduir de manera consistent el cost de producció i manteniment dels productes de l'empresa en termes quantitatius (hores-home o hores màquina, vCPU, RAM, disc).
- La manera de reduir el cost global del desenvolupament és minimitzar el cost de realitzar tasques típiques en sèrie: etapes i passos del procés tecnològic.
- Una tasca típica és una tasca la solució de la qual està totalment o parcialment automatitzada, no causa dificultats per als intèrprets i no requereix costos laborals importants.
- El procés de producció consta d'etapes, les etapes es divideixen en passos indivisibles, que són tasques típiques de diferent escala i abast.
- Des de tasques típiques dispars, hem arribat a cadenes tecnològiques complexes i models multinivells del procés de producció, que es poden descriure mitjançant un model IDEF0 funcional o un mapa tecnològic més senzill.
- El mapa tecnològic és una representació tabular de les etapes i passos del procés de producció. El més important: el mapa permet veure tot el procés en la seva totalitat, en grans peces amb la possibilitat de detallar-les.
- A partir del mapa tecnològic, és possible avaluar la necessitat d'introduir etapes en un producte determinat, delimitar àrees de responsabilitat, acordar contractes a les entrades i sortides de les etapes i valorar amb més precisió la necessitat de recursos.
En els articles següents, descriurem amb més detall quines eines tècniques s'utilitzen per implementar determinades etapes tecnològiques al nostre mapa.
Autors de l'article:
- — Cap d'Automatització (DevOps) de Positive Technologies
- - Diputat Cap del Departament d'Automatització (DevOps) de Positive Technologies
Font: www.habr.com