DevOps-käytännöt toimivat. Tästä vakuuttuimme itsekin, kun lyhensimme julkaisun asennusaikaa 10 kertaa. FIS Profile -järjestelmässä, jota käytämme VTB:ssä, asennus vie nyt 90 minuuttia 10:n sijaan. Julkaisun rakennusaika on lyhentynyt kahdesta viikosta kahteen päivään. Pysyvien toteutusvirheiden määrä on pudonnut lähes minimiin. Päästäksemme eroon ”käsityöstä” ja eliminoidaksemme riippuvuuden myyjästä meidän piti työskennellä kainalosauvojen kanssa ja löytää odottamattomia ratkaisuja. Leikkauksen alla on yksityiskohtainen tarina siitä, kuinka rakensimme täysimittaisen sisäisen kehityksen.
Prologi: DevOps on filosofia
Olemme viimeisen vuoden aikana tehneet paljon työtä DevOps-käytäntöjen sisäisen kehittämisen ja käyttöönoton järjestämiseksi VTB:llä:
- Rakensimme sisäiset kehitysprosessit 12 järjestelmälle;
- Otimme käyttöön 15 putkilinjaa, joista neljä otettiin tuotantoon;
- Automatisoitu 1445 testiskenaariota;
- Otimme onnistuneesti käyttöön useita sisäisten tiimien valmistelemia julkaisuja.
Yksi vaikeimmin organisoitavista DevSecOps-käytäntöjen sisäisestä kehittämisestä ja käyttöönotosta osoittautui FIS Profile -järjestelmäksi - vähittäiskaupan tuoteprosessoriksi ei-relatiivisessa DBMS:ssä. Pystyimme kuitenkin rakentamaan kehitystyön, käynnistämään prosessin, asentamaan tuotteeseen yksittäisiä ei-julkaisupaketteja ja opettelimme julkaisujen kokoamista. Tehtävä ei ollut helppo, mutta mielenkiintoinen ja ilman ilmeisiä toteutusrajoituksia: tässä on järjestelmä - sinun on rakennettava talon sisäinen kehitys. Ainoa ehto on käyttää CD-levyä ennen tuottavaa ympäristöä.
Aluksi toteutusalgoritmi vaikutti yksinkertaiselta ja selkeältä:
- Kehitämme alkukehitysosaamista ja saavutamme kooditiimiltä hyväksyttävän laatutason ilman suuria vikoja;
- Integroimme olemassa oleviin prosesseihin niin paljon kuin mahdollista;
- Koodin siirtämiseksi ilmeisten vaiheiden välillä leikkaamme liukuhihnan ja työnnämme sen toisen päistä jatkoon.
Tänä aikana tarvittavan kokoisen kehitystiimin tulee kehittää taitojaan ja kasvattaa panoksensa julkaisuihin hyväksyttävälle tasolle. Ja siinä kaikki, voimme katsoa tehtävän suoritetuksi.
Näyttää siltä, että tämä on täysin energiatehokas polku vaadittuun tulokseen: tässä on DevOps, tässä on tiimin suorituskykymittarit, tässä on kertynyt asiantuntemus... Mutta käytännössä saimme jälleen vahvistuksen, että DevOps on edelleen filosofiaa , eikä "liitetty gitlab-prosessiin, ansible, nexus ja alempana luettelossa".
Analysoituamme vielä kerran toimintasuunnitelman, huomasimme, että rakennamme eräänlaista ulkoista toimittajaa itseemme. Siksi yllä kuvattuun algoritmiin lisättiin prosessin uudelleensuunnittelu sekä osaamisen kehittäminen koko kehitysreitin varrella johtavan roolin saavuttamiseksi tässä prosessissa. Ei helpoin vaihtoehto, mutta tämä on ideologisesti oikean kehityksen polku.
Mistä sisäinen kehitys alkaa?
Se ei ollut ystävällisin järjestelmä työskentelyyn. Arkkitehtonisesti se oli yksi suuri ei-relaatiotietokantajärjestelmä, joka koostui useista erillisistä suoritettavista objekteista (skriptit, menettelyt, erät jne.), joita kutsuttiin tarpeen mukaan, ja se toimi mustan laatikon periaatteella: se vastaanottaa pyynnön ja antaa kysymykset. vastaus. Muita huomionarvoisia vaikeuksia ovat:
- Eksoottinen kieli (MUMPS);
- konsolin käyttöliittymä;
- Integraation puute suosittujen automaatiotyökalujen ja -kehysten kanssa;
- Tietojen määrä kymmeninä teratavuina;
- Yli 2 miljoonan toimenpiteen kuormitus tunnissa;
- Merkitys - Liiketoiminnan kannalta kriittinen.
Samaan aikaan puolellamme ei ollut lähdekoodivarastoa. Ollenkaan. Dokumentaatiota oli, mutta kaikki keskeiset tiedot ja kompetenssit olivat ulkopuolisen organisaation puolella.
Aloitimme järjestelmän kehittämisen hallitsemisen lähes tyhjästä ottaen huomioon sen ominaisuudet ja alhaisen jakelun. Aloitettu lokakuussa 2018:
- Opiskellut dokumentaatiota ja koodin generoinnin perusteita;
- Tutkimme toimittajalta saatua lyhytkurssia kehitystyöstä;
- Hallitsee alkukehitystaidot;
- Teimme koulutusoppaan uusille tiimin jäsenille;
- Sovimme sisällyttävämme joukkueen "taistelutilaan";
- Ratkaistiin ongelma koodin laadunvalvonnalla;
- Järjestimme kehitysosaston.
Käytimme kolme kuukautta osaamisen kehittämiseen ja järjestelmään uppoutumiseen, ja vuoden 2019 alusta sisäkehitys aloitti liikkeensä kohti valoisaa tulevaisuutta, toisinaan vaikeasti, mutta luottavaisesti ja määrätietoisesti.
Tietovaraston siirto ja automaattiset testit
Ensimmäinen DevOps-tehtävä on arkisto. Sovimme nopeasti pääsyn tarjoamisesta, mutta oli välttämätöntä siirtyä nykyisestä yhden runkohaaran SVN:stä kohde Gitiin siirtymällä usean haaran malliin ja kehittämällä Git Flowta. Meillä on myös 2 tiimiä omalla infrastruktuurilla sekä osa myyjän tiimistä ulkomailla. Minun piti elää kahden Gitin kanssa ja varmistaa synkronointi. Tällaisessa tilanteessa se oli pienempi kahdesta pahasta.
Arkiston siirtoa lykättiin toistuvasti, se valmistui vasta huhtikuussa etulinjan kollegoiden avustuksella. Git Flow'n kanssa päätimme pitää asiat yksinkertaisina aluksi ja päädyimme klassiseen järjestelmään hotfix-korjauksen, kehittämisen ja julkaisun kanssa. He päättivät hylätä mestarin (alias prod-like). Alla selitämme, miksi tämä vaihtoehto osoittautui meille optimaaliseksi. Työntekijänä käytettiin toimittajalle kuuluvaa ulkoista arkistoa, joka oli yhteinen kahdelle ryhmälle. Se synkronoitiin sisäisen arkiston kanssa aikataulun mukaisesti. Nyt Gitin ja Gitlabin avulla prosesseja oli mahdollista automatisoida.
Autotestien ongelma ratkesi yllättävän helposti - saimme valmiit puitteet. Järjestelmän erityispiirteet huomioon ottaen erillisen toiminnon kutsuminen oli ymmärrettävä osa liiketoimintaprosessia ja toimi samalla yksikkötestinä. Jäljelle jäi vain testitietojen valmisteleminen ja halutun skriptien kutsun ja tulosten arvioinnin järjestyksen asettaminen. Kun toimintatilastojen, prosessien kriittisyyden ja olemassa olevan regressiometodologian perusteella muodostettu skenaariolista täyttyi, alkoi ilmaantua automaattisia testejä. Nyt voimme aloittaa putken rakentamisen.
Miten se oli: malli ennen automaatiota
Toteutusprosessin olemassa oleva malli on erillinen tarina. Jokainen muutos siirrettiin manuaalisesti erillisenä lisäasennuspakettina. Seuraavaksi tuli manuaalinen rekisteröinti Jiraan ja manuaalinen asennus ympäristöihin. Yksittäisten pakettien osalta kaikki näytti selvältä, mutta julkaisun valmistelun myötä asiat olivat monimutkaisempia.
Kokoonpano suoritettiin yksittäisten toimitusten tasolla, jotka olivat itsenäisiä kohteita. Mikä tahansa muutos on uusi toimitus. Pääjulkaisukoostumuksen 60-70 pakettiin lisättiin mm. 10–15 teknistä versiota - versioita, jotka saatiin lisättäessä tai poissuljettaessa jotain julkaisusta ja jotka heijastavat julkaisujen ulkopuolisen myynnin muutoksia.
Toimituksissa olevat objektit olivat päällekkäisiä toistensa kanssa, erityisesti suoritettavassa koodissa, joka oli alle puolet uniikkia. Sekä jo asennettuun koodiin että siihen, jonka asennus oli juuri suunniteltu, oli monia riippuvuuksia.
Tarvittavan koodiversion saamiseksi oli noudatettava tiukasti asennusjärjestystä, jonka aikana esineitä kirjoitettiin fyysisesti uudelleen monta kertaa, noin 10-12 kertaa.
Pakettipaketin asennuksen jälkeen minun piti manuaalisesti noudattaa ohjeita asetusten alustamiseksi. Myyjä kokosi ja asensi julkaisun. Julkaisun koostumus selvitettiin melkein ennen toteutushetkeä, mikä johti "decoupling" -pakettien luomiseen. Tämän seurauksena merkittävä osa tarvikkeista siirtyi julkaisusta julkaisuun omalla "irrotuspäällään".
Nyt on selvää, että tällä lähestymistavalla - julkaisupalapelin kokoaminen pakettitasolla - yhdellä päähaaralla ei ollut käytännön merkitystä. Asennus tuotantoon kesti puolitoista - kaksi tuntia käsityötä. On hyvä, että ainakin asentajatasolla oli määritelty objektien käsittelyjärjestys: kentät ja rakenteet syötettiin ennen niiden ja menettelyjen tietoja. Tämä toimi kuitenkin vain erillisessä paketissa.
Tämän lähestymistavan looginen tulos oli pakolliset asennusvirheet kohteiden vinoversioiden, tarpeettoman koodin, puuttuvien ohjeiden ja objektien keskinäisten vaikutusten muodossa, jotka poistettiin kuumeisesti julkaisun jälkeen.
Ensimmäiset päivitykset: sitoa kokoonpano ja toimitus
Automatisointi aloitettiin lähettämällä koodi putken kautta tätä reittiä:
- Nouda valmis toimitus varastosta;
- Asenna se erityiseen ympäristöön;
- Suorita automaattisia testejä;
- Arvioi asennuksen tulos;
- Kutsu seuraava liukuhihna testauskomennon puolella.
Seuraavan liukuhihnan tulee rekisteröidä tehtävä Jirassa ja odottaa komentojen jakamista valituille testaussilmukaille, jotka riippuvat tehtävän toteutuksen ajoituksesta. Trigger - kirje valmiista toimitusta varten tiettyyn osoitteeseen. Tämä oli tietysti ilmeinen kainalosauva, mutta jostain oli aloitettava. Toukokuussa 2019 koodin siirto alkoi ympäristöjemme tarkistuksella. Prosessi on alkanut, jäljellä on vain saada se kunnolliseen muotoon:
- Jokainen muutos suoritetaan erillisessä haarassa, joka vastaa asennuspakettia ja sulautuu kohdepäähaaraan;
- Putkilinjan käynnistyslaukaisin on uuden sitoumuksen ilmestyminen päähaaraan yhdistämispyynnön kautta, jonka sisäisen tiimin ylläpitäjät sulkevat.
- Tietovarastot synkronoidaan kerran viidessä minuutissa;
- Asennuspaketin kokoaminen aloitetaan - käyttämällä toimittajalta saatua kokoonpanoa.
Tämän jälkeen oli jo olemassa vaiheita koodin tarkistamiseksi ja siirtämiseksi, putken käynnistämiseksi ja kokoamiseksi puolellemme.
Tämä vaihtoehto otettiin käyttöön heinäkuussa. Siirron vaikeudet johtivat tyytymättömyyteen myyjän ja etulinjan keskuudessa, mutta seuraavan kuukauden aikana onnistuimme poistamaan kaikki epätasaisuudet ja luomaan prosessin tiimien kesken. Meillä on nyt kokoonpano ja toimitus.
Elokuussa onnistuimme saamaan valmiiksi erillisen paketin ensimmäisen asennuksen tuotantoon käyttämällä putkistoamme, ja syyskuusta lähtien poikkeuksetta kaikki yksittäisten ei-release-pakettien asennukset tehtiin CD-työkalumme kautta. Lisäksi onnistuimme saavuttamaan 40 %:n osuuden sisäisistä tehtävistä julkaisukoostumuksesta pienemmällä tiimillä kuin myyjä - tämä on selvä menestys. Vakavin tehtävä jäi - julkaisun kokoaminen ja asentaminen.
Lopullinen ratkaisu: kumulatiiviset asennuspaketit
Ymmärsimme erittäin hyvin, että toimittajan ohjeiden kirjoittaminen oli niin automaatiota; meidän piti ajatella itse prosessia uudelleen. Ratkaisu oli ilmeinen - kerätä julkaisuhaaralta kumulatiivinen tarjonta kaikkien tarvittavien versioiden objektien kanssa.
Aloitimme proof of conceptilla: kokosimme julkaisupaketin käsin aiemman toteutuksen sisällön mukaan ja asensimme sen ympäristöihimme. Kaikki toimi, konsepti osoittautui toteuttamiskelpoiseksi. Seuraavaksi ratkaisimme ongelman alustusasetusten komentosarjasta ja niiden sisällyttämisestä vahvistukseen. Valmistelimme uuden paketin ja testasimme sitä testausympäristöissä osana ääriviivapäivitystä. Asennus onnistui, vaikkakin käyttöönottotiimin kommenteista tuli paljon. Mutta pääasia, että meille annettiin lupa aloittaa tuotanto marraskuun julkaisussa kokoonpanollamme.
Hieman yli kuukauden jäljellä, käsin poimitut tarvikkeet vihjasivat selvästi, että aika oli loppumassa. He päättivät tehdä koontiversion julkaisuhaarasta, mutta miksi se pitäisi erottaa? Meillä ei ole Prod-tyyppistä, eivätkä nykyiset haarat ole hyviä - tarpeetonta koodia on paljon. Meidän on leikattava pikaisesti tuotetyyppejä, ja tämä on yli kolme tuhatta sitoumusta. Käsin kokoaminen ei ole ollenkaan vaihtoehto. Laadimme skriptin, joka kulkee tuotteen asennuslokin läpi ja kerää sitoumuksia haaraan. Kolmannella kerralla toimi oikein ja "viimeistelyn jälkeen" haara oli valmis.
Kirjoitimme oman rakentajan asennuspaketille ja valmistuimme viikossa. Sitten jouduimme muokkaamaan asennusohjelmaa järjestelmän ydintoiminnoista, koska se on avoimen lähdekoodin. Useiden tarkistusten ja muutosten jälkeen tulos katsottiin onnistuneeksi. Sillä välin muotoutui julkaisun koostumus, jonka oikeaa asennusta varten oli tarpeen kohdistaa testipiiri tuotantopiiriin ja tätä varten kirjoitettiin erillinen käsikirjoitus.
Luonnollisesti ensimmäisestä asennuksesta tuli paljon kommentteja, mutta yleisesti ottaen koodi toimi. Ja noin kolmannen asennuksen jälkeen kaikki alkoi näyttää hyvältä. Kohteiden kompositio- ja versionhallintaa valvottiin erikseen manuaalisessa tilassa, mikä tässä vaiheessa oli varsin perusteltua.
Lisähaasteena oli suuri määrä ei-julkaisuja, jotka piti ottaa huomioon. Mutta Prod-tyyppisen haaran ja Rebasen avulla tehtävästä tuli läpinäkyvä.
Ensimmäinen kerta, nopeasti ja ilman virheitä
Lähestyimme julkaisua optimistisella asenteella ja yli tusinalla onnistuneella asennuksella eri piireillä. Mutta kirjaimellisesti päivää ennen määräaikaa kävi ilmi, että myyjä ei ollut saanut valmiiksi julkaisun valmistelua asennusta varten hyväksytyllä tavalla. Jos versiomme ei jostain syystä toimi, julkaisu keskeytyy. Lisäksi meidän ponnisteluillamme, mikä on erityisen epämiellyttävää. Meillä ei ollut mahdollisuutta vetäytyä. Siksi mietimme vaihtoehtoisia vaihtoehtoja, laadimme toimintasuunnitelmat ja aloitimme asennuksen.
Yllättäen koko julkaisu, joka koostuu yli 800 kohteesta, alkoi oikein, ensimmäistä kertaa ja vain 10 minuutissa. Vietimme tunnin tarkastaessamme lokeja virheiden etsimiseen, mutta emme löytäneet niitä.
Koko seuraavan päivän julkaisukeskustelussa vallitsi hiljaisuus: ei toteutusongelmia, vääriä versioita tai "sopimatonta" koodia. Se oli jopa jotenkin noloa. Myöhemmin kommentteja tuli esiin, mutta muihin järjestelmiin ja aikaisempaan kokemukseen verrattuna niiden määrä ja prioriteetti olivat huomattavasti pienempiä.
Lisävaikutus kumulatiivisesta vaikutuksesta oli kokoonpanon ja testauksen laadun paraneminen. Täyden julkaisun useiden asennusten vuoksi rakennusvirheet ja käyttöönottovirheet tunnistettiin ajoissa. Testaus täydessä julkaisukokoonpanossa mahdollisti lisäksi sellaisten esineiden keskinäisen vaikutuksen puutteiden tunnistamisen, joita ei ilmennyt inkrementaalisten asennusten aikana. Se oli ehdottomasti menestys, varsinkin kun otetaan huomioon 57 %:n osuus julkaisusta.
Yhteenveto ja päätelmät
Alle vuodessa onnistuimme:
- Rakenna täysipainoinen sisäinen kehitys käyttämällä eksoottista järjestelmää;
- Poista kriittinen toimittajariippuvuus;
- Käynnistä CI/CD saadaksesi erittäin epäystävällisen perinnön;
- Nosta toteutusprosessit uudelle tekniselle tasolle;
- Vähentää merkittävästi käyttöönottoaikaa;
- Vähentää merkittävästi toteutusvirheiden määrää;
- Ilmoittaudu rohkeasti johtavaksi kehitysasiantuntijaksi.
Tietysti suuri osa kuvatusta näyttää suoralta paskalta, mutta nämä ovat järjestelmän ominaisuuksia ja siinä esiintyviä prosessirajoituksia. Tällä hetkellä muutokset vaikuttivat IS Profilen tuotteisiin ja palveluihin (yleistilit, muovikortit, säästötilit, sulkutilit, käteislainat), mutta mahdollisesti lähestymistapaa voidaan soveltaa mihin tahansa IS:ään, jolle on asetettu tehtävänä DevOps-käytäntöjen toteuttaminen. Kumulatiivinen malli voidaan turvallisesti replikoida monista toimituksista tulevia toteutuksia varten (mukaan lukien ei-julkaisemat).
Lähde: will.com