Imagine:
Salutare tuturor! Suntem ingineri de automatizare ai companiei și sprijinim dezvoltarea produselor companiei: susținem întreaga conductă de asamblare de la comiterea unei linii de cod de către dezvoltatori până la publicarea produselor finite și a licențelor pe serverele de actualizare. În mod informal, suntem numiți ingineri DevOps. În acest articol, dorim să vorbim despre etapele tehnologice ale procesului de producție de software, cum le vedem și cum le clasificăm.
Din material veți afla despre complexitatea coordonării dezvoltării multi-produs, despre ce este o hartă tehnologică și cum ajută aceasta la eficientizarea și replicarea soluțiilor, care sunt principalele etape și pași ai procesului de dezvoltare, cum sunt zonele de responsabilitate între DevOps și echipele din compania noastră.
Despre Chaos și DevOps
Pe scurt, conceptul DevOps include instrumente și servicii de dezvoltare, precum și metodologii și cele mai bune practici pentru utilizarea acestora. Să scoatem în evidență globalul scop din implementarea ideilor DevOps în compania noastră: aceasta este o reducere consistentă a costului de producție și întreținere a produselor în termeni cantitativi (ore-om sau ore de mașină, CPU, RAM, Disc etc.). Cea mai simplă și mai evidentă modalitate de a reduce costul total de dezvoltare la nivelul întregii companii este minimizând costul efectuării sarcinilor în serie tipice în toate etapele producţiei. Dar care sunt aceste etape, cum să le separăm de procesul general, în ce pași constau?
Când o companie dezvoltă un produs, totul este mai mult sau mai puțin clar: există de obicei o foaie de parcurs și o schemă de dezvoltare comună. Dar ce să faci când linia de produse se extinde și există mai multe produse? La prima vedere, au procese și linii de asamblare similare, iar jocul „găsește X diferențe” în jurnale și scripturi începe. Dar dacă există deja peste 5 proiecte în dezvoltare activă și este necesar suport pentru mai multe versiuni dezvoltate de-a lungul mai multor ani? Dorim să reutilizam numărul maxim posibil de soluții în pipeline de produse sau suntem gata să cheltuim bani pentru o dezvoltare unică pentru fiecare?
Cum să găsești un echilibru între unicitate și soluții de serie?
Aceste întrebări au început să apară în fața noastră din ce în ce mai des din 2015. Numărul de produse a crescut și am încercat să ne extindem la minimum departamentul de automatizare (DevOps), care a susținut liniile de asamblare ale acestor produse. În același timp, am dorit să replicăm cât mai multe soluții între produse. La urma urmei, de ce să faci același lucru în zece produse în moduri diferite?
Director de dezvoltare: „Băieți, putem evalua cumva ce face DevOps pentru produse?”
Noi: „Nu știm, nu am pus o astfel de întrebare, dar ce indicatori ar trebui luați în considerare?”
Director de dezvoltare: "Cine ştie! Gândi…"
Ca în acel celebru film: "Sunt într-un hotel! .." - "Uh... Poți să-mi arăți drumul?" Reflectând, am ajuns la concluzia că mai întâi trebuie să decidem asupra stărilor finale ale produselor; acesta a devenit primul nostru obiectiv.
Deci, cum analizezi o duzină de produse cu echipe destul de mari de la 10 la 200 de persoane și cum poți determina valori măsurabile atunci când replici soluții?
1:0 în favoarea Chaosului sau DevOps pe omoplați
Am început cu o încercare de a aplica diagrame IDEF0 și diferite diagrame de proces de afaceri din seria BPwin. Confuzia a început după al cincilea pătrat al următoarei etape a următorului proiect, iar aceste pătrate pentru fiecare proiect pot fi desenate în coada unui piton lung sub 50+ pași. M-am simțit trist și am vrut să urlu la lună - nu se potrivea în general.
Sarcini tipice de producție
Modelarea proceselor de producție este o muncă foarte complexă și minuțioasă: trebuie să colectați, să procesați și să analizați o mulțime de date de la diverse departamente și lanțuri de producție. Puteți citi mai multe despre asta în articolul „".
Când am început să modelăm procesul nostru de producție, am avut un obiectiv specific - să transmitem fiecărui angajat implicat în dezvoltarea produselor companiei noastre și managerilor de proiect:
- modul în care produsele și componentele lor, pornind de la comiterea unei linii de cod, ajung la client sub formă de instalatori și actualizări,
- ce resurse sunt furnizate pentru fiecare etapă de producție a produselor,
- ce servicii sunt implicate în fiecare etapă,
- modul în care sunt delimitate domeniile de responsabilitate pentru fiecare etapă,
- ce contracte exista la intrarea si iesirea din fiecare etapa.
Făcând clic pe imagine, o va deschide la dimensiune completă.
Activitatea noastră în companie este împărțită în mai multe domenii funcționale. Direcția infrastructurii este angajată în optimizarea funcționării tuturor resurselor „de fier” ale departamentului, precum și în automatizarea implementării mașinilor virtuale și a mediului pe acestea. Direcția de monitorizare asigură controlul performanței serviciului 24/7; oferim, de asemenea, monitorizare ca serviciu pentru dezvoltatori. Direcția fluxului de lucru oferă echipelor instrumente pentru a gestiona procesele de dezvoltare și testare, pentru a analiza starea codului și pentru a obține analize asupra proiectelor. Și, în sfârșit, direcția webdev asigură publicarea versiunilor pe serverele de actualizare GUS și FLUS, precum și licențierea produselor folosind serviciul LicenseLab. Pentru a susține conducta de producție, am înființat și menținem multe servicii de asistență diferite pentru dezvoltatori (puteți asculta povești despre unele dintre ele în întâlnirile vechi: и). De asemenea, dezvoltăm instrumente de automatizare interne, inclusiv .
În ultimii cinci ani, munca noastră a acumulat o mulțime de operațiuni de același tip și de rutină, iar dezvoltatorii noștri din alte departamente provin în principal din așa-numitele sarcini tipice, a cărui soluție este complet sau parțial automatizată, nu provoacă dificultăți artiștilor interpreți și nu necesită cantități semnificative de muncă. Împreună cu domeniile de conducere, am analizat astfel de sarcini și am putut identifica categorii individuale de muncă, sau etapele de producție, etapele au fost împărțite în trepte indivizibile, iar mai multe etape se adună lanțul procesului de producție.
Cel mai simplu exemplu de lanț tehnologic îl reprezintă etapele de asamblare, implementare și testare a fiecăruia dintre produsele noastre în cadrul companiei. La rândul său, de exemplu, etapa de construire constă din mulți pași tipici separati: descărcarea surselor din GitLab, pregătirea dependențelor și biblioteci terță parte, testarea unitară și analiza codului static, executarea unui script de compilare pe GitLab CI, publicarea artefactelor în depozit pe Artifactory și generarea de note de lansare prin instrumentul nostru intern ChangelogBuilder.
Puteți citi despre sarcinile tipice DevOps în celelalte articole ale noastre despre Habré: „"Și"".
Se formează multe lanțuri de producție tipice proces de fabricație. Abordarea standard pentru descrierea proceselor este utilizarea modelelor IDEF0 funcționale.
Un exemplu de modelare a unui proces CI de fabricație
Am acordat o atenție deosebită dezvoltării proiectelor standard pentru un sistem de integrare continuă. Acest lucru a făcut posibilă realizarea unificării proiectelor, evidențiind așa-numitele schemă de creare a lansării cu promoții.
Iată cum funcționează. Toate proiectele arată tipic: includ configurația ansamblurilor care se încadrează în depozitul de instantanee de la Artifactory, după care sunt implementate și testate pe bancuri de testare și apoi promovate în depozitul de lansare. Serviciul Artifactory este un singur punct de distribuție pentru toate artefactele de construcție între echipe și alte servicii.
Dacă simplificăm și generalizăm foarte mult schema noastră de lansare, atunci aceasta include următorii pași:
- asamblare de produse pe mai multe platforme,
- desfășurare pe bancuri de testare,
- efectuarea de teste funcționale și alte teste,
- promovarea versiunilor testate pentru a lansa depozite la Artifactory,
- publicarea versiunii se bazează pe servere de actualizare,
- livrarea de ansambluri și actualizări ale producției,
- lansarea instalării și actualizării produsului.
De exemplu, luați în considerare modelul tehnologic al acestei scheme tipice de lansare (în continuare pur și simplu Model) sub forma unui model IDEF0 funcțional. Acesta reflectă principalele etape ale procesului nostru CI. Modelele IDEF0 folosesc așa-numitele Notație ICOM (Input-Control-Output-Mechanism) pentru a descrie ce resurse sunt utilizate în fiecare etapă, pe baza ce reguli și cerințe se realizează, care este rezultatul și ce mecanisme, servicii sau oameni implementează o anumită etapă.
Făcând clic pe imagine, o va deschide la dimensiune completă.
De regulă, este mai ușor să descompuneți și să detaliați descrierea proceselor în modelele funcționale. Dar pe măsură ce numărul elementelor crește, devine din ce în ce mai dificil să înțelegeți ceva în ele. Dar în dezvoltarea reală există și etape auxiliare: monitorizarea, certificarea produselor, automatizarea proceselor de lucru și altele. Din cauza problemei de scalare, am abandonat această descriere.
Nașterea Speranței
Într-o carte, am dat peste vechi hărți sovietice care descriu procese tehnologice (care, apropo, sunt încă folosite astăzi la multe întreprinderi de stat și universități). Așteptați, așteptați, pentru că avem și un flux de lucru!... Există etape, rezultate, metrici, cerințe, indicatori și așa mai departe... De ce să nu încercați să aplicați scheme de flux și la conductele noastre de produse? Era un sentiment: „Asta este! Am găsit firul potrivit, e timpul să-l tragem bine!
Într-un tabel simplu, am decis să înregistrăm produsele pe coloane și etapele tehnologice și pașii conductei de produse pe rânduri. Etapele sunt ceva mare, cum ar fi un pas de construire a produsului. Și pașii sunt ceva mai mici și mai detaliați, cum ar fi pasul de descărcare a codului sursă pe serverul de compilare sau pasul de compilare a codului.
La intersecțiile rândurilor și coloanelor hărții, punem în jos stările pentru o anumită etapă și produs. Pentru stări, a fost definit un set de stări:
- Nu există informații - sau nepotrivit. Este necesar să se analizeze cererea pentru o etapă a produsului. Fie analiza a fost deja efectuată, dar etapa nu este în prezent necesară sau nu este justificată din punct de vedere economic.
- Amânat - sau nu este relevantă în acest moment. Este nevoie de o etapă în pregătire, dar nu există forțe pentru implementare în acest an.
- Planificat. Etapa este planificată pentru implementare în acest an.
- Realizat. Etapa în conductă este implementată în volumul necesar.
Completarea tabelului a început proiect cu proiect. Mai întâi, etapele și etapele unui proiect au fost clasificate și starea acestora a fost înregistrată. Apoi au luat următorul proiect, au fixat stările din el și au adăugat etapele și pașii care lipseau în proiectele anterioare. Drept urmare, am obținut etapele și etapele întregii noastre conducte de producție și statusurile acestora într-un proiect specific. S-a dovedit ceva similar cu matricea de competențe pentru pipeline de produse. Am numit o astfel de matrice o hartă tehnologică.
Cu ajutorul hărții tehnologice, coordonăm în mod rezonabil metrologic cu echipele planurile de lucru pe an și țintele pe care dorim să le atingem împreună: ce etape adăugăm proiectului anul acesta și pe care le lăsăm pentru mai târziu. De asemenea, în cursul lucrărilor, este posibil să avem îmbunătățiri în etapele pe care le-am finalizat pentru un singur produs. Apoi ne extindem harta și introducem această îmbunătățire ca o etapă sau un nou pas, apoi analizăm pentru fiecare produs și aflăm fezabilitatea reproducerii îmbunătățirii.
S-ar putea să ne opună: „Aceasta este, desigur, bine, doar cu timpul numărul de pași și etape va deveni prohibitiv de mare. Cum să fii?
Am introdus descrieri standard și destul de complete ale cerințelor pentru fiecare etapă și pas, astfel încât acestea să fie înțelese de toată lumea din cadrul companiei în același mod. De-a lungul timpului, pe măsură ce se introduc îmbunătățiri, un pas poate fi absorbit într-o altă etapă sau pas, iar apoi se vor „prăbuși”. În același timp, toate cerințele și nuanțele tehnologice se încadrează în cerințele etapei sau etapei de generalizare.
Cum se evaluează efectul soluțiilor de replicare? Folosim o abordare extrem de simplă: atribuim costurile inițiale de capital pentru implementarea unei noi etape costurilor generale anuale ale produsului și apoi împărțim la toți atunci când replicăm.
Părți ale dezvoltării sunt deja afișate ca repere și pași pe hartă. Putem influența reducerea costului produsului prin introducerea automatizării pentru etapele tipice. După aceea, luăm în considerare modificările caracteristicilor calitative, metrici cantitative și profitul primit de echipe (în ore-om sau ore-mașină de economii).
Harta tehnologica a procesului de productie
Dacă ne parcurgem toate etapele și pașii, le codificăm cu etichete și le extindem într-un singur lanț, atunci se va dovedi a fi foarte lung și de neînțeles (doar „coada de piton” despre care am vorbit la începutul articolului) :
[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]Acestea sunt etapele de construire a produselor [Build], implementarea lor pe serverele de testare [Deploy], testarea [Test], promovarea build-urilor pentru a lansa depozite pe baza rezultatelor testării [Promovare], generarea și publicarea licențelor [Licența], publicarea [ Publicare] pe serverul de actualizare GUS și livrarea către serverele de actualizare FLUS, instalarea și actualizarea componentelor produsului pe infrastructura clientului utilizând Product Configuration Management [Instalare], precum și colectarea de telemetrie [Telemetrie] din produsele instalate.
Pe lângă acestea, pot fi distinse etape separate: monitorizarea stării infrastructurii [InfMonitoring], versiunea codului sursă [SourceCodeControl], pregătirea mediului de construcție [Prepare], managementul proiectelor [Workflow], furnizarea echipelor cu instrumente de comunicare [Comunicare], certificare produs [ Certificare] și asigurarea autosuficienței proceselor CI [CISelfSufficiency] (de exemplu, independența ansamblurilor față de Internet). Zeci de pași din procesele noastre nici nu vor fi luați în considerare, deoarece sunt foarte specifici.
Va fi mult mai ușor de înțeles și de privit întregul proces de producție dacă acesta este prezentat sub formă harta tehnologica; acesta este un tabel în care etapele individuale de producție și etapele descompuse ale Modelului sunt scrise pe rânduri, iar în coloane o descriere a ceea ce se face la fiecare etapă sau pas. Accentul principal este pus pe resursele care asigură fiecare etapă, și pe delimitarea domeniilor de responsabilitate.
Harta pentru noi este un fel de clasificator. Ea reflectă părțile tehnologice mari ale producției de produse. Datorită acesteia, a devenit mai ușor pentru echipa noastră de automatizare să interacționeze cu dezvoltatorii și să planifice în comun implementarea etapelor de automatizare, precum și să înțeleagă ce costuri de muncă și resurse (umane și hardware) vor fi necesare pentru aceasta.
În cadrul companiei noastre, harta este generată automat din șablonul jinja ca fișier HTML obișnuit și apoi încărcată pe serverul GitLab Pages. Se poate vizualiza o captură de ecran cu un exemplu de hartă complet generată .
Făcând clic pe imagine, o va deschide la dimensiune completă.
Pe scurt, harta tehnologică este o imagine generalizată a procesului de producție, care reflectă blocuri clar clasificate cu funcționalitate tipică.
Structura foii noastre rutiere
Harta este formată din mai multe părți:
- Zona de titlu - iată o descriere generală a hărții, sunt introduse concepte de bază, sunt definite principalele resurse și rezultatele procesului de producție.
- Tabloul de bord - aici puteți controla afișarea datelor pentru produse individuale, este furnizat un rezumat al etapelor implementate și al pașilor în general pentru toate produsele.
- Harta tehnologică - o descriere tabelară a procesului tehnologic. Pe hartă:
- sunt date toate etapele, etapele și codurile acestora;
- sunt oferite descrieri scurte și complete ale etapelor;
- sunt indicate resursele de intrare și serviciile utilizate în fiecare etapă;
- sunt indicate rezultatele fiecărei etape și o etapă separată;
- este indicată domeniul de responsabilitate pentru fiecare etapă și pas;
- au fost stabilite resursele tehnice, cum ar fi HDD (SSD), RAM, vCPU și orele de lucru necesare pentru a susține munca în această etapă, atât în momentul actual - un fapt, cât și în viitor - un plan;
- pentru fiecare produs, se indică ce etape tehnologice sau pași pentru acesta au fost implementate, planificate pentru implementare, irelevante sau neimplementate.
Luarea deciziilor pe baza hărții tehnologice
După examinarea hărții, este posibil să se întreprindă unele acțiuni - în funcție de rolul angajatului în companie (manager de dezvoltare, manager de produs, dezvoltator sau tester):
- să înțeleagă ce etape lipsesc dintr-un produs sau proiect real și să evalueze necesitatea implementării acestora;
- delimitează ariile de responsabilitate între mai multe departamente dacă acestea lucrează pe etape diferite;
- conveni asupra contractelor la intrările și ieșirile din etape;
- integrați-vă etapa de lucru în procesul general de dezvoltare;
- să evalueze mai precis nevoia de resurse care asigură fiecare dintre etape.
Rezumând toate cele de mai sus
Rutarea este versatilă, extensibilă și ușor de întreținut. Este mult mai ușor să dezvoltați și să mențineți o descriere a proceselor în această formă decât într-un model IDEF0 academic strict. În plus, o descriere tabelară este mai simplă, mai familiară și mai bine structurată decât un model funcțional.
Pentru implementarea tehnică a pașilor, avem un instrument intern special CrossBuilder - un instrument de nivel între sistemele CI, servicii și infrastructură. Dezvoltatorul nu trebuie să-și taie bicicleta: în sistemul nostru CI, este suficient să rulați unul dintre scripturile (așa-numita sarcină) a instrumentului CrossBuilder, care îl va executa corect, ținând cont de caracteristicile infrastructurii noastre. .
Rezultatele
Articolul s-a dovedit a fi destul de lung, dar acest lucru este inevitabil atunci când descriem modelarea proceselor complexe. În cele din urmă, aș dori să repar pe scurt ideile noastre principale:
- Scopul implementării ideilor DevOps în compania noastră este de a reduce constant costul de producție și întreținere al produselor companiei în termeni cantitativi (ore-man sau ore de mașină, vCPU, RAM, Disk).
- Modul de reducere a costului total al dezvoltării este de a minimiza costul efectuării sarcinilor tipice în serie: etapele și etapele procesului tehnologic.
- O sarcină tipică este o sarcină a cărei soluție este complet sau parțial automatizată, nu provoacă dificultăți executanților și nu necesită costuri semnificative ale forței de muncă.
- Procesul de producție constă din etape, etapele sunt împărțite în etape indivizibile, care sunt sarcini tipice de scară și anvergură diferită.
- De la sarcini tipice disparate, am ajuns la lanțuri tehnologice complexe și modele pe mai multe niveluri ale procesului de producție, care pot fi descrise printr-un model IDEF0 funcțional sau o hartă tehnologică mai simplă.
- Harta tehnologică este o reprezentare tabelară a etapelor și etapelor procesului de producție. Cel mai important lucru: harta vă permite să vedeți întregul proces în întregime, în bucăți mari cu posibilitatea de a le detalia.
- Pe baza hărții tehnologice, este posibil să se evalueze necesitatea introducerii etapelor într-un anumit produs, să se delimiteze zonele de responsabilitate, să se convină asupra contractelor la intrările și ieșirile etapelor și să se evalueze mai precis nevoia de resurse.
În articolele următoare, vom descrie mai detaliat ce instrumente tehnice sunt folosite pentru implementarea anumitor etape tehnologice pe harta noastră.
Autorii articolului:
- — Șef de automatizare (DevOps) la Positive Technologies
- - Deputat Șef al departamentului de automatizare (DevOps) la Positive Technologies
Sursa: www.habr.com