DevOps LEGO: wéi mir d'Pipeline a Cubë geluecht hunn

Mir hunn eemol en elektroneschen Dokumentmanagementsystem un engem Client an enger Ariichtung geliwwert. An dann op en aneren Objet. An nach een. An op de véierten, an op de fënneften. Mir sinn esou matgedroen, datt mir 10 verdeelt Objete erreecht hunn. Et huet sech staark erausgestallt ... besonnesch wa mir d'Ännerunge geliwwert hunn. Als Deel vun der Liwwerung un de Produktiounskrees, 5 Szenarie vum Testsystem erfuerdert schlussendlech 10 Stonnen a 6-7 Mataarbechter. Esou Käschten hunn eis gezwongen esou selten wéi méiglech Liwwerungen ze maachen. No dräi Joer Operatioun konnte mir et net ausstoen an hu beschloss de Projet mat enger Prise DevOps opzemaachen.

DevOps LEGO: wéi mir d'Pipeline a Cubë geluecht hunn

Elo gëtt all Tester an 3 Stonnen stattfonnt, an 3 Leit bedeelegen et: en Ingenieur an zwee Tester. D'Verbesserunge si kloer an Zuelen ausgedréckt a féieren zu enger Reduktioun vum beléiften TTM. An eiser Erfahrung ginn et vill méi Clienten déi vun DevOps profitéiere kënnen wéi déi déi iwwerhaapt wëssen. Dofir, fir DevOps méi no bei de Leit ze bréngen, hu mir en einfache Konstruktor entwéckelt, iwwer dee mir méi am Detail an dësem Post schwätzen.

Loosst eis Iech elo méi am Detail soen. Eng Energiefirma setzt en techneschen Dokumentmanagementsystem op 10 grouss Ariichtungen of. Et ass net einfach Projete vun dëser Skala ouni DevOps ze navigéieren, well e groussen Undeel vun der manueller Aarbecht d'Aarbecht staark verzögert an och d'Qualitéit reduzéiert - all manuell Aarbecht ass voll mat Feeler. Op der anerer Säit ginn et Projeten, wou et nëmmen eng Installatioun ass, awer alles muss automatesch funktionnéieren, konstant an ouni Ausfall - zum Beispill déiselwecht Dokumentflosssystemer a grousse monolitheschen Organisatiounen. Soss wäert iergendeen d'Astellunge manuell maachen, iwwer d'Deploymentinstruktioune vergiessen - an als Resultat, an der Produktioun ginn d'Astellunge verluer an alles wäert zesummeklappen.

Normalerweis schaffe mir mam Client iwwer e Kontrakt, an an dësem Fall divergéieren eis Interessen liicht. De Client kuckt op de Projet strikt am Budget an technesch Spezifikatioune. Et kann schwéier sinn him d'Virdeeler vu verschiddenen DevOps Praktiken z'erklären, déi net an den technesche Spezifikatioune abegraff sinn. Wat ass wann hien interesséiert ass fir séier Verëffentlechungen mat engem Plus-Geschäftswäert, oder fir eng Automatisatiounspipeline ze bauen?

Och, wann Dir mat engem pre-approuvéierte Käschte schafft, gëtt dësen Interessi net ëmmer fonnt. An eiser Praxis gouf et e Fall wou mir d'Entwécklung vun engem skrupellosen an onsécheren Optraghueler hu missen ophuelen. Et war schrecklech: et goufe keng aktuell Quellcoden, d'Codebasis vum selwechte System war ënnerschiddlech op verschiddenen Installatiounen, d'Dokumentatioun war deelweis feelen, an deelweis vu schrecklecher Qualitéit. Natierlech huet de Client keng Kontroll iwwer de Quellcode, Assemblée, Verëffentlechungen, etc.

Bis elo weess net jiddereen iwwer DevOps, awer soubal mir iwwer seng Virdeeler schwätzen, iwwer real Ressourcenspueren, sinn d'Ae vun alle Clienten op. Also d'Zuel vun Ufroen déi DevOps enthalen ass mat der Zäit erop. Hei, fir einfach déi selwecht Sprooch mat Clienten ze schwätzen, musse mir séier Geschäftsproblemer an DevOps Praktiken verbannen, déi hëllefe fir eng passend Entwécklungspipeline ze bauen.

Also, mir hunn eng Rei vu Probleemer op der enger Säit, mir hunn DevOps Wëssen, Praktiken an Tools op der anerer. Firwat net d'Erfahrung mat jidderengem deelen?

En DevOps Konstruktor erstellen

Agile huet säin eegene Manifest. ITIL huet seng eege Methodik. DevOps ass manner glécklech - et huet nach keng Templates a Standarde kritt. Obwuel e puer probéieren bestëmmen d'Reife vu Firmen op Basis vun enger Bewäertung vun hirer Entwécklung an Operatiounspraktiken.

Glécklecherweis huet déi bekannte Firma Gartner am Joer 2014 gesammelt an analyséiert Schlëssel DevOps Praktiken an d'Relatiounen tëscht hinnen. Baséierend op dësem hunn ech eng Infografik verëffentlecht:

DevOps LEGO: wéi mir d'Pipeline a Cubë geluecht hunn

Mir hunn et als Basis fir eis konstrukteur. Jiddwer vun de véier Beräicher huet eng Rei vun Tools - mir hunn se an eng Datebank gesammelt, déi populärste identifizéiert, Integratiounspunkten identifizéiert a passend Optimisatiounsmechanismen. Am Ganzen huet sech erausgestallt 36 Praktiken an 115 Tools, e Véierel vun deenen sinn Open Source oder gratis Software. Als nächst wäerte mir schwätzen iwwer wat mir an all Beräich erreecht hunn an, als Beispill, iwwer wéi dëst am Projet ëmgesat gouf fir technesch Dokumentmanagement ze kreéieren, mat deem mir de Post ugefaang hunn.

D'Prozesser

DevOps LEGO: wéi mir d'Pipeline a Cubë geluecht hunn

Am notoresche EDMS-Projet gouf den techneschen Dokumentatiounsmanagementsystem no deemselwechte Schema op jiddereng vun den 10 Objeten agesat. D'Installatioun enthält 4 Serveren: Datebankserver, Applikatiounsserver, Volltext Indexéierung an Inhaltsverwaltung. An der Installatioun funktionnéiere se an engem eenzegen Node a sinn am Rechenzentrum an den Ariichtungen. All Objeten ënnerscheede sech liicht an der Infrastruktur, awer dëst stéiert net mat der globaler Interaktioun.

Als éischt, laut DevOps Praktiken, hu mir d'Infrastruktur lokal automatiséiert, duerno hunn mir d'Liwwerung an den Testkrees bruecht, an dann op de Produkt vum Client. All Prozess gouf Schrëtt fir Schrëtt ausgeschafft. D'Ëmweltastellunge sinn am Quellcode-System fixéiert, berécksiichtegt wéi de Verdeelungskit fir automatesch Aktualiséierung kompiléiert ass. Am Fall vun Configuratioun Ännerungen, Ingenieuren brauchen einfach déi entspriechend Ännerungen am Versioun Kontroll System ze maachen - an dann automatesch Aktualiséierung opgetrueden ouni Problemer.

Dank dëser Approche ass den Testprozess staark vereinfacht ginn. Virdrun hat de Projet Tester déi näischt gemaach hunn wéi manuell Stänn aktualiséieren. Elo kommen se just, gesinn datt alles funktionnéiert a maache méi nëtzlech Saachen. All Update gëtt automatesch getest - vum Uewerflächenniveau bis zum Geschäftsszenarioautomatiséierung. D'Resultater ginn als separat Berichter an TestRail gepost.

Kultur

DevOps LEGO: wéi mir d'Pipeline a Cubë geluecht hunn

Kontinuéierlech Experimentéiere gëtt am beschten duerch d'Beispill vum Testdesign erkläert. E System testen deen nach net existéiert ass kreativ Aarbecht. Wann Dir en Testplang schreift, musst Dir verstoen wéi Dir richteg testt a wéi eng Filialen ze verfollegen. An och e Gläichgewiicht tëscht Zäit a Budget fannen fir déi optimal Unzuel u Schecken ze bestëmmen. Et ass wichteg genee déi néideg Tester ze wielen, iwwerdenken wéi de Benotzer mam System interagéiert, d'Ëmwelt a méiglech extern Faktoren berücksichtegen. Et ass onméiglech ouni kontinuéierlech Experimenter ze maachen.

Elo iwwer d'Kultur vun der Interaktioun. Virdru waren et zwou opposéierend Säiten - Ingenieuren an Entwéckler. D'Entwéckler hunn gesot: "Mir ass egal wéi et lancéiert gëtt. Dir sidd Ingenieuren, Dir sidd intelligent, gitt sécher datt et ouni Feeler funktionnéiert". D'Ingenieuren hunn geäntwert: "Dir Entwéckler sinn ze suergfälteg. Loosst eis méi virsiichteg sinn, a mir spillen Är Verëffentlechungen manner dacks. Well all Kéier wann Dir eis e leaky Code gitt, ass et eis net kloer wéi mir interagéieren.. Dëst ass e kulturellt Interaktiounsprobleem dat anescht aus enger DevOps Perspektiv strukturéiert ass. Hei sinn d'Ingenieuren an d'Entwéckler Deel vun engem eenzegen Team dat sech op stänneg verännert, awer gläichzäiteg zouverlässeg Software konzentréiert.

Am selwechte Team si Spezialisten décidéiert géigesäiteg ze hëllefen. Wéi et virdru war? Zum Beispill goufen e puer déck Asazinstruktioune virbereet, ongeféier 50 Säiten laang.Den Ingenieur huet et gelies, eppes net verstanen, verflucht an den Entwéckler um dräi Auer de Moien gefrot fir ze kommentéieren. Den Entwéckler huet kommentéiert an och verflucht - um Enn war kee glécklech. Plus, natierlech, et waren e puer Feeler, well Dir kënnt net alles an den Instruktiounen erënneren. An elo schreift den Ingenieur, zesumme mam Entwéckler, e Skript fir den automatiséierten Deployment vun der Applikatioun Software Infrastruktur. A si schwätzen praktesch an der selwechter Sprooch mateneen.

Leit

DevOps LEGO: wéi mir d'Pipeline a Cubë geluecht hunn

D'Gréisst vum Team gëtt vum Ëmfang vum Update bestëmmt. D'Team gëtt während der Formatioun vun der Liwwerung rekrutéiert; et enthält déi interesséiert aus dem allgemenge Projetsteam. Da gëtt en Updateplang mat deene Verantwortlech fir all Etapp geschriwwen, an d'Team mellt wéi et weidergeet. All Teammemberen sinn austauschbar. Als Deel vun der Equipe hu mir och e Backup Entwéckler, awer hien muss bal ni konnektéieren.

vun den Technologien

DevOps LEGO: wéi mir d'Pipeline a Cubë geluecht hunn

Am Technologiediagramm sinn e puer Punkte beliicht, awer ënner hinnen ass et eng Rëtsch Technologien - Dir kënnt e ganzt Buch mat hire Beschreiwunge publizéieren. Also wäerte mir déi interessantst markéieren.

Infrastruktur als Code

Elo wäert dëst Konzept wahrscheinlech keen iwwerraschen, awer virdrun hunn d'Beschreiwunge vun den Infrastrukturen vill ze wënschen. D'Ingenieuren hunn d'Instruktioune schrecklech gekuckt, d'Testëmfeld waren eenzegaarteg, si ware geschätzt a geschätzt, Stëbspartikele goufen vun hinnen ofgeblosen.

Hautdesdaags huet keen Angscht ze experimentéieren. Et gi Basisbiller vu virtuelle Maschinnen, et gi fäerdeg Szenarie fir Ëmfeld z'installéieren. All Templates a Skripte ginn an engem Versiounskontrollsystem gespäichert a ginn direkt aktualiséiert. Virdrun, wann et néideg war e Package op e Stand ze liwweren, erschéngt eng Konfiguratiounslück. Elo musst Dir just eng Zeil an de Quellcode addéieren.

Zousätzlech zu Infrastruktur Scripten a Pipelines gëtt d'Dokumentatioun als Code Approche och fir Dokumentatioun benotzt. Dank dësem ass et einfach, nei Leit mam Projet ze verbannen, se an de System aféieren op Basis vun de Funktiounen, déi beschriwwe sinn, zum Beispill am Testplang, an och Testfäll weiderbenotzen.

Kontinuéierlech Liwwerung an Iwwerwachung

Am leschten Artikel iwwer DevOps hu mir geschwat wéi mir Tools ausgewielt hunn fir kontinuéierlech Liwwerung an Iwwerwaachung ëmzesetzen. Dacks ass et net néideg eppes nei ze schreiwen - et ass genuch fir virdru geschriwwe Skripte ze benotzen, korrekt Integratioun tëscht Komponenten ze bauen an eng gemeinsam Gestiounskonsole ze kreéieren. An all Prozesser kënnen mat engem Knäppchen oder Zäitplang lancéiert ginn.

Op Englesch ginn et verschidde Konzepter, Continuous Delivery a Continuous Deployment. Béid kënnen als "kontinuéierlech Liwwerung" iwwersat ginn, awer tatsächlech ass et e klengen Ënnerscheed tëscht hinnen. An eisem Projet fir den techneschen Dokument Flux vun enger verdeelt Energie Firma, éischter, Liwwerung gëtt benotzt - wann Installatioun fir Produktioun op Kommando geschitt. Am Deployment geschitt d'Installatioun automatesch. Kontinuéierlech Liwwerung an dësem Projet ass allgemeng ginn zentral Deel vun DevOps.

Am Allgemengen, andeems Dir bestëmmte Parameteren sammelt, kënnt Dir kloer verstoen firwat DevOps Praktiken nëtzlech sinn. A vermëttelen dëst un d'Gestioun, déi wierklech Zuelen gär huet. D'Gesamtzuel vun de Starten, d'Ausféierungszäit vun de Skriptstadien, den Undeel vun erfollegräiche Starten - all dat beaflosst direkt jidderee seng Liiblingszäit op de Maart, dat heescht d'Zäit vun engem Engagement fir de Versiounskontrollsystem bis zur Verëffentlechung vun enger Versioun op engem Produktioun Ëmfeld. Mat der Ëmsetzung vun den néidegen Tools kréien d'Ingenieuren wäertvoll Indikatoren per Mail, an de Projektmanager gesäit se um Dashboard. Op dës Manéier kënnt Dir direkt d'Virdeeler vun neien Tools evaluéieren. An Dir kënnt se op Ärer Infrastruktur probéieren mam DevOps Designer.

Wien brauch eis DevOps Designer?

Loosst eis net virstellen: fir e Start ass hien eis nëtzlech ginn. Wéi mir scho gesot hunn, musst Dir déi selwecht Sprooch mam Client schwätzen, a mat der Hëllef vum DevOps Designer kënne mir séier d'Basis fir esou e Gespréich skizzéieren. D'Geschäftsspezialisten kënne selwer bewäerten wat se brauchen an domat méi séier entwéckelen. Mir hu probéiert den Designer sou detailléiert wéi méiglech ze maachen, eng Rëtsch Beschreiwunge bäizefügen fir datt all Benotzer versteet wat e wielt.

D'Format vum Designer erlaabt Iech déi existent Entwécklungen vun der Firma am Bauprozess an der Automatioun ze berücksichtegen. Et brauch een net alles ofzerappen an opzebauen, wann een nëmme Léisunge ka wielen, déi gutt mat existente Prozesser integréieren an déi einfach d'Lücken ausfëllen.

Vläicht ass Är Entwécklung schonn op e méi héijen Niveau geplënnert an eist Tool wäert ze "Kapitän" schéngen. Awer mir fannen et nëtzlech fir eis selwer an hoffen datt et fir e puer vun de Lieser nëtzlech ass. Mir erënneren Iech un Link dem Designer - wann iwwerhaapt, kritt Dir den Diagramm direkt nodeems Dir déi initial Donnéeën aginn hutt. Mir wäerten dankbar sinn fir Äre Feedback an Ergänzunge.

Source: will.com

Setzt e Commentaire