Raportissa puhutaan joistakin DevOps-käytännöistä, mutta kehittäjän näkökulmasta. Yleensä kaikilla DevOpsiin liittyneillä insinööreillä on jo usean vuoden hallinnollinen kokemus. Mutta tämä ei tarkoita, etteikö täällä olisi tilaa kehittäjälle. Useimmiten kehittäjät korjaavat "päivän seuraavaa kiireellisesti kriittistä virhettä", eikä heillä ole aikaa edes katsoa nopeasti DevOps-kenttää. Kirjoittajan käsityksen mukaan DevOps on ensinnäkin tervettä järkeä. Toiseksi se on mahdollisuus olla tehokkaampi. Jos olet kehittäjä, sinulla on maalaisjärkeä ja haluat olla tehokkaampi tiimipelaaja, tämä raportti on sinua varten.
Saanen esitellä itseni, myönnän täysin, että huoneessa on ihmisiä, jotka eivät tunne minua. Nimeni on Anton Boyko, olen Microsoft Azure MVP. Mikä on MVP? Tämä on Model-View-Presenter. Model-View-Presenter on juuri minä.
Lisäksi toimin tällä hetkellä ratkaisuarkkitehdin tehtävässä Ciklumissa. Ja äskettäin ostin itselleni niin kauniin verkkotunnuksen ja päivitin sähköpostini, jonka yleensä näytän esityksissä. Voit kirjoittaa minulle osoitteeseen: me [koira] byokoant.pro. Voit lähettää minulle kysymyksiä sähköpostitse. Vastaan niihin yleensä. Ainoa asia on, etten halua vastaanottaa sähköpostitse kysymyksiä, jotka liittyvät kahteen aiheeseen: politiikkaan ja uskontoon. Kaikesta muusta voit kirjoittaa minulle sähköpostitse. Aikaa kuluu, vastaan.
Muutama sana itsestäsi:
- Olen ollut tällä alalla nyt 10 vuotta.
- Työskentelin Microsoftilla.
- Olen Ukrainan Azure-yhteisön perustaja, jonka perustimme jossain vuonna 2014. Ja meillä on se edelleen ja kehitämme sitä.
- Olen myös Ukrainassa järjestämämme Azure-konferenssin perustajan isä.
- Autan myös järjestämään Global Azure Bootcamp -tapahtumaa Kiovassa.
- Kuten sanoin, olen Microsoft Azure MVP.
- Puhun konferensseissa melko usein. Pidän todella paljon konferensseissa puhumisesta. Viimeisen vuoden aikana pääsin esiintymään noin 40 kertaa. Jos ohitat Ukrainan, Valko-Venäjän, Puolan, Bulgarian, Ruotsin, Tanskan, Alankomaiden, Espanjan tai annat tai otat toisen maan Euroopassa, on täysin mahdollista, että kun menet konferenssiin, jossa on pilviteema, saatat nähdä minut puhujaluettelossa.
- Olen myös Star Trek -fani.
Puhutaanpa vähän Agendasta. Agendamme on hyvin yksinkertainen:
- Puhumme siitä, mitä DevOps on. Puhutaanpa siitä, miksi tämä on tärkeää. Aiemmin DevOps oli avainsana, jonka kirjoitit ansioluetteloosi ja sait heti +500 dollaria palkkaa. Nyt sinun on kirjoitettava ansioluetteloosi esimerkiksi lohkoketju saadaksesi +500 dollaria palkkaasi.
- Ja sitten, kun ymmärrämme hieman, mitä tämä on, puhumme siitä, mitä DevOps-käytännöt ovat. Mutta ei niinkään DevOpsin yhteydessä yleensä, vaan niistä DevOps-käytännöistä, jotka saattavat kiinnostaa kehittäjiä. Kerron sinulle, miksi ne saattavat kiinnostaa sinua. Kerron sinulle, miksi sinun pitäisi tehdä tämä ja kuinka se voi auttaa sinua kokemaan vähemmän kipua.
Perinteinen kuva, jota monet ihmiset näyttävät. Näin tapahtuu monissa projekteissa. Silloin meillä on ohjelmistojamme tukevat kehitys- ja käyttöosastot. Ja nämä osastot eivät kommunikoi keskenään.
Ehkä, jos et voinut tuntea sitä niin selvästi DevOps- ja käyttöosastoilla, voit vetää analogian Dev- ja QA-osastojen kanssa. On ihmisiä, jotka kehittävät ohjelmistoja, ja on laadunvarmistushenkilöitä, jotka ovat huonoja kehittäjien näkökulmasta. Sitoan esimerkiksi upean koodini arkistoon, ja siellä istuu joku roisto, joka palauttaa tämän koodin minulle ja sanoo, että koodisi on huono.
Tämä kaikki tapahtuu, koska ihmiset eivät kommunikoi keskenään. Ja he heittävät joitain paketteja, sovelluksia toisilleen jonkin väärinkäsitysmuurin läpi ja yrittävät tehdä niillä jotain.
Juuri tämä muuri DevOps-kulttuuri on suunniteltu tuhoamaan, ts. pakottaa ihmiset kommunikoimaan toistensa kanssa ja ainakin ymmärtämään, mitä projektissa eri ihmiset tekevät ja miksi heidän työnsä on tärkeää.
Ja kun puhumme DevOpsista, joku kertoo sinulle, että DevOps on silloin, kun projektissa on jatkuva integraatio; joku sanoo, että DevOps on, jos projekti toteuttaa "infrastruktuuri koodina" -käytännön; joku sanoo, että ensimmäinen askel DevOpsiin on ominaisuuksien haarautuminen, ominaisuusliput.
Pohjimmiltaan tämä kaikki on totta omalla tavallaan. Mutta nämä ovat vain parhaita käytäntöjämme. Ennen kuin siirryt näihin käytäntöihin, suosittelen katsomaan tätä diaa, joka näyttää kolme vaihetta Dev-Ops-metodologian käyttöönotossa projektissasi, yrityksessäsi.
Tällä dialla on myös toinen epävirallinen nimi. Voit etsiä verkosta, mitkä ovat DevOpsin 3 muskettisoturia. On mahdollista, että löydät tämän artikkelin. Miksi 3 muskettisoturia? Alla lukee: ihmiset, prosessit ja tuotteet, ts. PPP – Porthos, Porthos ja Porthos. Tässä on DevOpsin 3 muskettisoturia. Tässä artikkelissa kuvataan yksityiskohtaisemmin, miksi tämä on tärkeää ja mitä se sisältää.
Kun aloitat DevOps-kulttuurin käyttöönoton, on erittäin tärkeää, että se toteutetaan seuraavassa järjestyksessä.
Aluksi sinun on puhuttava ihmisten kanssa. Ja sinun on selitettävä ihmisille, mitä se on ja kuinka he voivat hyötyä siitä.
Konferenssimme on nimeltään DotNet Fest. Ja kuten järjestäjät kertoivat, kutsuimme tänne lähinnä kehittäjäyleisön, joten toivon, että suurin osa hallissa olevista on mukana kehitystyössä.
Puhumme ihmisistä, puhumme siitä, mitä kehittäjät haluavat tehdä joka päivä. Mitä he haluavat eniten? He haluavat kirjoittaa uutta koodia, käyttää uusia kehyksiä, luoda uusia ominaisuuksia. Mitä kehittäjät haluavat vähiten? Korjaa vanhat bugit. Toivottavasti olet kanssani samaa mieltä. Tätä kehittäjät haluavat. He haluavat kirjoittaa uusia ominaisuuksia, he eivät halua korjata vikoja.
Tietyn kehittäjän tuottamien bugien määrä riippuu siitä, kuinka suorat hänen kätensä ovat ja kuinka paljon ne kasvavat hänen harteistaan, eivät hänen takataskuistaan. Mutta kuitenkin, kun meillä on suuri projekti, joskus käy niin, että on mahdotonta seurata kaikkea, joten meidän olisi mukavaa käyttää joitain lähestymistapoja, jotka auttavat meitä kirjoittamaan vakaampaa ja laadukkaampaa koodia.
Mitä QA:t haluavat eniten? En tiedä ovatko he hallissa. Minun on vaikea sanoa, että haluan laadunvarmistuksen, koska en ole koskaan ollut sellainen. Ja älä loukkaa kavereita, sanotaan, että toivottavasti en koskaan tee. Mutta ei siitä syystä, että pidän heidän työtään merkityksettömänä ja hyödyttömänä, vaan koska en pidä itseäni ihmisenä, joka voisi tehdä tämän työn tehokkaasti, joten en edes yritä tehdä sitä. Mutta mitä ymmärrän, QA ei pidä siitä, että se toimii aamulla, tekee jatkuvasti jonkinlaisia regressiotestejä, astuu samoihin virheisiin, joista he ilmoittivat kehittäjille 3 sprinttiä sitten ja sanovat: "Milloin aiot tehdä , Monsieur D 'Artagnan, korjaa tämä virhe.' Ja herra D'Artagnan vastaa hänelle: "Kyllä, kyllä, kyllä, olen jo korjannut sen." Ja kuinka kävi niin, että korjasin yhden bugin ja tein 5 matkan varrella.
Tätä ratkaisua tuotannossa tukevat ihmiset haluavat tämän ratkaisun toimivan ilman bugeja, jotta heidän ei tarvitse käynnistää palvelinta uudelleen joka perjantai, kun kaikki normaalit ihmiset menevät baariin. Kehittäjät ottivat käyttöön perjantaina, järjestelmänvalvojat istuvat lauantaihin asti yrittäen saada tämän käyttöönoton kuntoon.
Ja kun selität ihmisille, että he pyrkivät ratkaisemaan samoja ongelmia, voit siirtyä prosessien virallistamiseen. Se on erittäin tärkeää. Miksi? Koska kun sanomme "formalisointi", sinun on tärkeää kuvailla, kuinka prosessisi tapahtuvat ainakin jossain lautasliinassa. Sinun on ymmärrettävä, että jos otat käyttöön esimerkiksi laadunvarmistusympäristöön tai tuotantoympäristöön, niin se tapahtuu aina tässä järjestyksessä, näissä vaiheissa suoritamme esimerkiksi automaattisia yksikkötestejä ja käyttöliittymätestejä. Käyttöönoton jälkeen tarkistamme, menikö käyttöönotto hyvin vai huonosti. Mutta sinulla on jo selkeä luettelo toiminnoista, jotka on toistettava yhä uudelleen, kun otat käyttöön tuotantoon.
Ja vasta kun prosessisi on virallistettu, alat valita tuotteita, jotka auttavat sinua automatisoimaan nämä prosessit.
Valitettavasti näen hyvin usein tämän tapahtuvan päinvastoin. Heti kun joku kuulee sanan "DevOps", hän ehdottaa välittömästi Jenkinsin asentamista, koska he uskovat, että heti kun he asentavat Jenkinsin, heillä on DevOps. He asensivat Jenkinsin, lukivat "How to"-artikkeleita Jenkinsin verkkosivuilla, yrittivät laittaa prosesseja näihin How to -artikkeleihin ja sitten tulivat ihmisten luo ja kumarsivat ihmisiä sanoen, että kirjassa sanotaan, että sinun täytyy tehdä se näin. joten teemme sen näin.
Ei se tarkoita, että Jenkins olisi huono työkalu. En tarkoita sanoa sitä millään tavalla. Mutta tämä on vain yksi tuotteista. Ja mitä tuotetta käytät, sen pitäisi olla viimeinen päätöksesi, eikä suinkaan ensimmäinen. Kulttuurin ja lähestymistapojen toteuttaminen ei saa ohjata tuotettasi. Tämä on erittäin tärkeää ymmärtää, minkä vuoksi vietän niin paljon aikaa tällä dialla ja selitän kaiken tämän niin pitkään.
Puhutaanpa DevOps-käytännöistä yleisesti. Mitä ne ovat? Mikä on ero? Kuinka kokeilla niitä? Miksi ne ovat tärkeitä?
Ensimmäinen käytäntö, josta olet ehkä kuullut, on nimeltään Continuous Integration. Ehkä jollain projektissa on jatkuva integrointi (CI).
Suurin ongelma on, että useimmiten kun kysyn henkilöltä: "Onko sinulla projektissa CI?" ja hän sanoo: "Kyllä", sitten kun kysyn, mitä hän tekee, hän kuvailee minulle ehdottomasti koko automaatioprosessia. Tämä ei ole täysin totta.
Itse asiassa CI:n käytäntö on vain tarkoitettu integroimaan eri ihmisten kirjoittama koodi jonkinlaiseksi yhdeksi koodipohjaksi. Siinä kaikki.
CI:n ohella matkan varrella on yleensä muita käytäntöjä - kuten jatkuva käyttöönotto, julkaisujen hallinta, mutta puhumme niistä myöhemmin.
CI itse kertoo meille, että eri ihmiset kirjoittavat koodia ja tämä koodi on jatkuvasti integroitava yhdeksi koodipohjaksi.
Mitä tämä antaa meille ja miksi se on tärkeää? Jos meillä on DotNet, se on hyvä, se on käännetty kieli, voimme kääntää sovelluksemme. Jos se kääntää, se on jo hyvä merkki. Tämä ei vielä tarkoita mitään, mutta se on ensimmäinen hyvä merkki, jonka voimme ainakin koota.
Sitten voimme suorittaa testejä, mikä on myös erillinen käytäntö. Kaikki testit ovat vihreitä – tämä on toinen hyvä merkki. Mutta jälleen kerran, tämä ei tarkoita mitään.
Mutta miksi tekisit tämän? Kaikilla käytännöillä, joista puhun tänään, on suunnilleen sama arvo, eli suunnilleen samat hyödyt, ja niitä mitataan myös suunnilleen samalla tavalla.
Ensinnäkin sen avulla voit nopeuttaa toimitusta. Miten tämä nopeuttaa toimitusta? Kun teemme joitain uusia muutoksia koodipohjaamme, voimme heti yrittää tehdä jotain tällä koodilla. Emme odota torstaihin, koska torstaina julkaisemme sen QA Environmentille, teemme sen täällä ja täällä.
Kerron sinulle yhden surullisen tarinan elämästäni. Siitä oli kauan aikaa, kun olin vielä nuori ja komea. Nyt olen jo nuori, kaunis ja älykäs ja vaatimaton. Olin jonkin aikaa sitten projektissa. Meillä oli suuri noin 30 kehittäjän tiimi. Ja meillä oli iso, iso yritysprojekti, joka kehittyi noin 10 vuotta. Ja meillä oli eri haarat. Arkistossa meillä oli haara, jossa kehittäjät kävelivät. Ja siellä oli haara, joka näytti tuotannossa olevan koodin version.
Tuotantohaara oli 3 kuukautta jäljessä kehittäjien käytettävissä olevasta haarasta. Mitä tämä tarkoittaa? Tämä tarkoittaa, että heti kun minulla on jossain bugi, joka menee tuotantoon kehittäjien syyn vuoksi, koska he sallivat sen, ja laadunvarmistuksen virheen vuoksi, koska he katsoivat sen, tämä tarkoittaa, että jos saan Tehtävä hotfix-korjaukselle tuotantoa varten, minun on palautettava koodimuutokseni 3 kuukautta sitten. Minun täytyy muistaa, mitä minulla oli 3 kuukautta sitten, ja yrittää korjata se siellä.
Jos sinulla ei vielä ole tätä kokemusta, voit kokeilla sitä kotiprojektissasi. Pääasia on, että älä kokeile sitä kaupallisella. Kirjoita pari koodiriviä, unohda ne kuudeksi kuukaudeksi ja palaa sitten takaisin ja yritä selittää nopeasti, mistä nämä koodirivit liittyvät ja kuinka voit korjata tai optimoida ne. Se on erittäin, erittäin jännittävä kokemus.
Jos meillä on jatkuva integrointikäytäntö, sen avulla voimme tarkistaa sen useilla automatisoiduilla työkaluilla täällä ja juuri nyt, heti kun olen kirjoittanut koodini. Tämä ei ehkä anna minulle täyttä kuvaa, mutta siitä huolimatta se poistaa ainakin osan riskeistä. Ja jos jokin mahdollinen vika ilmenee, tiedän sen heti, eli kirjaimellisesti muutaman minuutin kuluttua. Minun ei tarvitse palata 3 kuukautta taaksepäin. Tarvitsen vain 2 minuuttia taaksepäin. Hyvä kahvinkeitin ei ehdi edes keittää kahvia kahdessa minuutissa, joten se on aika siistiä.
Tällä on se arvo, että se voidaan toistaa kerta toisensa jälkeen jokaisessa projektissa, ts. ei vain sitä, johon sen asensit. Voit toistaa sekä itse harjoituksen että itse CI toistetaan jokaisen uuden projektin muutoksen yhteydessä. Näin voit optimoida resursseja, koska tiimisi toimii tehokkaammin. Sinulla ei enää ole tilannetta, jossa virhe tulee sinulle koodista, jonka kanssa työstit 3 kuukautta sitten. Et voi enää vaihtaa kontekstia, kun istut ja vietät kaksi ensimmäistä tuntia yrittäessäsi ymmärtää, mitä silloin tapahtui, ja päästäksesi kontekstin olemukseen ennen kuin alat korjata jotain.
Kuinka voimme mitata tämän käytännön onnistumista tai epäonnistumista? Jos raportoit isolle pomolle, mitä toteutimme CI-projektissa, hän kuulee blaa blaa blaa. Toteutimme sen, ok, mutta miksi, mitä se toi meille, miten mittaamme sen, kuinka oikein tai väärin toteutamme sen?
Ensimmäinen on, että CI:n ansiosta voimme ottaa käyttöön yhä useammin ja useammin juuri siksi, että koodimme on mahdollisesti vakaampi. Samalla tavalla aikamme virheen löytämiseen lyhenee ja tämän virheen korjaamiseen kuluva aika pienenee juuri siitä syystä, että saamme järjestelmältä vastauksen juuri tässä ja juuri nyt, mikä koodissamme on vialla.
Toinen käytäntö meillä on automaatiotestauskäytäntö, joka tulee useimmiten CI-käytännön mukana. Ne kulkevat käsi kädessä.
Mikä tässä on tärkeää ymmärtää? On tärkeää ymmärtää, että testimme ovat erilaisia. Ja jokainen automaattinen testi on tarkoitettu ratkaisemaan omat ongelmansa. Meillä on esimerkiksi yksikkötestejä, joiden avulla voimme testata moduulia erikseen, ts. Miten se toimii tyhjiössä? Tämä on hyvä.
Meillä on myös integraatiotestejä, joiden avulla voimme ymmärtää, miten eri moduulit integroituvat toisiinsa. Se on myös hyvä.
Meillä voi olla käyttöliittymän automaatiotestejä, joiden avulla voimme tarkistaa, kuinka hyvin käyttöliittymän kanssa työskentely vastaa asiakkaan asettamia vaatimuksia jne.
Suorittamasi tietyt testit voivat vaikuttaa siihen, kuinka usein suoritat niitä. Yksikkötestit kirjoitetaan yleensä lyhyinä ja pieninä. Ja ne voidaan käynnistää säännöllisesti.
Jos puhumme käyttöliittymän automaatiotesteistä, on hyvä, jos projektisi on pieni. Käyttöliittymän automaatiotestit voivat kestää jonkin verran aikaa. Mutta yleensä käyttöliittymän automaatiotesti on asia, joka kestää useita tunteja suuressa projektissa. Ja se on hyvä, jos se kestää muutaman tunnin. Ainoa asia on, että ei ole mitään järkeä käyttää niitä jokaisessa rakennuksessa. On järkevää ajaa niitä yöllä. Ja kun kaikki tulivat töihin aamulla: sekä testaajat että kehittäjät, he saivat jonkinlaisen raportin, että teimme käyttöliittymän automaattisen testin yöllä ja saimme nämä tulokset. Ja täällä tunnin työ palvelimella, joka tarkistaa, että tuotteesi täyttää tietyt vaatimukset, on paljon halvempi kuin tunti saman laadunvarmistusinsinöörin työtä, vaikka hän olisi nuorempi laadunvarmistusinsinööri, joka työskentelee ruoan ja kiitoksen puolesta. Kuitenkin tunti koneenkäyttöä tulee halvemmaksi. Siksi siihen on järkevää sijoittaa.
Minulla on toinen projekti, jonka parissa olen työstänyt. Meillä oli kahden viikon sprintit tässä projektissa. Projekti oli suuri, tärkeä finanssisektorille, eikä virhettä voitu tehdä. Ja kahden viikon sprintin jälkeen kehityssykliä seurasi testausprosessi, joka kesti vielä 4 viikkoa. Yritä kuvitella tragedian laajuus. Kirjoitamme koodia kaksi viikkoa, sitten teemme sen ala CodeFreeze, pakkaamme sen uuteen sovelluksen versioon ja julkaisemme sen testaajille. Testaajat testaavat sitä vielä 4 viikkoa, ts. Kun he testaavat sitä, meillä on aikaa valmistella heille kaksi muuta versiota. Tämä on todella surullinen tapaus.
Ja kerroimme heille, että jos haluat olla tuottavampi, sinun on järkevää ottaa käyttöön automatisoidut testauskäytännöt, koska tämä satuttaa sinua juuri täällä, juuri nyt.
Harjoittele jatkuvaa käyttöönottoa. Hienoa, olet rakentanut. Tämä on jo hyvä. Koodisi on käännetty. Nyt olisi mukavaa ottaa tämä rakennelma käyttöön jossain ympäristössä. Sanotaan vaikka kehittäjille tarkoitetussa ympäristössä.
Miksi se on tärkeää? Ensinnäkin voit tarkastella, kuinka onnistunut olet itse käyttöönottoprosessissa. Olen tavannut tällaisia projekteja, kun kysyn: "Kuinka otat käyttöön uuden version sovelluksesta?", kaverit kertovat minulle: "Kootaan se ja pakkaamme sen zip-arkistoon. Lähetämme sen järjestelmänvalvojalle postitse. Järjestelmänvalvoja lataa ja laajentaa tämän arkiston. Ja koko toimisto alkaa rukoilla, että palvelin ottaisi uuden version."
Aloitetaan jostain yksinkertaisesta. He esimerkiksi unohtivat laittaa CSS:n arkistoon tai unohtivat vaihtaa hashtagin java-script-tiedoston nimessä. Ja kun teemme pyynnön palvelimelle, selain luulee, että sillä on jo tämä java-script-tiedosto, ja päättää olla lataamatta sitä. Ja siellä oli vanha versio, josta puuttui jotain. Yleisesti ottaen ongelmia voi olla monia. Siksi jatkuvan käyttöönoton käytäntö antaa sinun ainakin testata, mitä tapahtuisi, jos ottaisit puhtaan viitekuvan ja lataat sen täysin puhtaaseen uuteen ympäristöön. Saa nähdä mihin tämä johtaa.
Myös kun integroit koodia keskenään, esim. komennon välillä, tämän avulla voit myös nähdä, miltä se näyttää käyttöliittymässä.
Yksi ongelmista, joita esiintyy, kun käytetään paljon vanilja-java-skriptiä, on se, että kaksi kehittäjää ilmoitti vahingossa samannimisen muuttujan ikkunaobjektiin. Ja sitten tuuristasi riippuen. Kenen java-script-tiedosto vedetään pois toiseksi, korvaa toisen muutokset. Se on myös erittäin jännittävää. Tulet sisään: yksi asia toimii yhdelle, toinen ei toimi toiselle. Ja se on "ihanaa", kun se kaikki tulee ulos tuotannossa.
Seuraava käytäntö, joka meillä on, on automaattisen palautuksen käytäntö, nimittäin palaaminen sovelluksen edelliseen versioon.
Miksi tämä on tärkeää kehittäjille? On edelleen niitä, jotka muistavat kaukaisen, kaukaisen 90-luvun, jolloin tietokoneet olivat suuria ja ohjelmat pieniä. Ja ainoa tapa web-kehitykseen oli PHP:n kautta. PHP ei ole huono kieli, vaikka se onkin.
Mutta ongelma oli toinen. Kun otimme käyttöön uuden version php-sivustostamme, miten otimme sen käyttöön? Useimmiten avasimme Far Managerin tai jotain muuta. Ja latasi nämä tiedostot FTP:hen. Ja yhtäkkiä huomasimme, että meillä oli pieni, pieni virhe, esimerkiksi unohdimme laittaa puolipisteen tai unohdimme vaihtaa tietokannan salasanan, ja tietokannalle on salasana, joka on paikallisessa isännässä. Päätämme muodostaa nopeasti yhteyden FTP:hen ja muokata tiedostoja siellä. Tämä on vain tulipalo! Tämä oli suosittua 90-luvulla.
Mutta jos et ole katsonut kalenteria, 90-luku oli melkein 30 vuotta sitten. Nyt kaikki tapahtuu hieman eri tavalla. Ja yritä kuvitella tragedian laajuutta, kun he kertovat sinulle: ”Käytimme tuotantoon, mutta siellä jokin meni pieleen. Tässä on FTP-kirjautumistunnuksesi ja salasanasi, muodosta yhteys tuotantoon ja korjaa se nopeasti siellä." Jos olet Chuck Norris, tämä toimii. Jos ei, niin vaarana on, että jos korjaat yhden virheen, teet lisää 10. Juuri tästä syystä tämä käytäntö palata edelliseen versioon antaa sinun saavuttaa paljon.
Vaikka jotain pahaa jotenkin joutuisi tuotteeseen, se on huono, mutta ei kohtalokas. Voit palata edelliseen versioon. Kutsu sitä varmuuskopioksi, jos se on helpompi havaita tuossa terminologiassa. Voit palata tähän edelliseen versioon, ja käyttäjät voivat edelleen työskennellä tuotteesi kanssa ja sinulla on riittävästi puskuriaikaa. Voit rauhallisesti, ilman kiirettä ottaa kaiken tämän ja testata paikallisesti, korjata sen ja ladata sitten uuden version. On todella järkevää tehdä tämä.
Yritetään nyt yhdistää jotenkin kaksi edellistä käytäntöä yhteen. Saamme kolmannen nimeltä Release Management.
Kun puhumme jatkuvasta käyttöönotosta sen klassisessa muodossa, sanomme, että meidän täytyy vetää koodi jostain haarasta arkistosta, kääntää se ja ottaa käyttöön. On hyvä, jos meillä on sama ympäristö. Jos meillä on useita ympäristöjä, tämä tarkoittaa, että meidän on vedettävä koodi joka kerta, jopa samasta toimituksesta. Vedämme sen ulos joka kerta, rakennamme sen joka kerta ja otamme sen käyttöön uudessa ympäristössä. Ensinnäkin tämä on aika, koska projektin rakentaminen, jos sinulla on suuri ja 90-luvulta peräisin oleva projekti, voi kestää useita tunteja.
Lisäksi on toinen suru. Kun rakennat, jopa samalle koneelle, rakennat samat lähteet, sinulla ei silti ole takeita siitä, että tämä kone on samassa tilassa kuin se oli edellisen koontiversion aikana.
Oletetaan, että joku tuli sisään ja päivitti DotNetin puolestasi tai päinvastoin, joku päätti poistaa jotain. Ja sitten sinulla on kognitiivinen dissonanssi, että tästä sitoumuksesta kaksi viikkoa sitten rakensimme rakennetta ja kaikki oli hyvin, mutta nyt näyttää siltä, että sama kone, sama commit, sama koodi, jota yritämme rakentaa, mutta se ei toimi. . Tulet käsittelemään tätä pitkään, etkä ole tosiasia, että ymmärrät sitä. Ainakin pilaat hermojasi paljon.
Tästä syystä julkaisujen hallintakäytäntö ehdottaa ylimääräisen abstraktion, jota kutsutaan artefaktivarastoksi, galleriaksi tai kirjastoksi, käyttöönottoa. Voit kutsua sitä miksi haluat.
Pääajatuksena on, että heti kun meillä on jonkinlainen sitoumus siellä, esimerkiksi haarassa, jonka olemme valmiita ottamaan käyttöön eri ympäristöissämme, keräämme sovellukset tästä commitista ja kaiken mitä tarvitsemme tätä sovellusta varten, pakkaamme sen. zip-arkistoon ja tallenna se johonkin luotettavaan tallennustilaan. Ja tästä varastosta voimme saada tämän zip-arkiston milloin tahansa.
Sitten otamme sen ja otamme sen käyttöön automaattisesti kehitysympäristöön. Kilpailemme siellä, ja jos kaikki on hyvin, siirrymme lavalle. Jos kaikki on hyvin, otamme käyttöön saman arkiston tuotantoon, samat binaarit, jotka on käännetty tasan kerran.
Lisäksi, kun meillä on tällainen galleria, se auttaa meitä myös käsittelemään riskejä, joita käsittelimme viimeisessä diassa, kun puhuimme edelliseen versioon palauttamisesta. Jos otit vahingossa käyttöön jotain väärin, voit aina ottaa minkä tahansa muun aiemman version tästä galleriasta ja poistaa sen käyttöönoton näissä ympäristöissä samalla tavalla. Tämän avulla voit helposti palata edelliseen versioon, jos jokin menee pieleen.
On toinenkin hieno käytäntö. Sinä ja minä kaikki ymmärrämme, että kun palautamme sovelluksemme aiempaan versioon, tämä voi tarkoittaa, että tarvitsemme myös edellisen version infrastruktuurin.
Kun puhumme virtuaalisesta infrastruktuurista, monet ihmiset ajattelevat, että tämä on jotain, jonka järjestelmänvalvojat määrittävät. Ja jos haluat esimerkiksi hankkia uuden palvelimen, jolla haluat testata sovelluksesi uutta versiota, sinun on kirjoitettava lippu järjestelmänvalvojille tai devopsille. Devops kestää 3 viikkoa tähän. Ja 3 viikon kuluttua he kertovat sinulle, että olemme asentaneet sinulle virtuaalikoneen, jossa on yksi ydin, kaksi gigatavua RAM-muistia ja Windows-palvelin ilman DotNetiä. Sanot: "Mutta minä halusin DotNetin." He: "Ok, tule takaisin 3 viikon kuluttua."
Ajatuksena on, että käyttämällä infrastruktuuria koodikäytäntöinä voit käsitellä virtuaalista infrastruktuuriasi vain yhtenä resurssina.
Ehkä, jos joku teistä kehittää sovelluksia DotNetissä, olet ehkä kuullut Entity Framework -nimisestä kirjastosta. Ja olet ehkä jopa kuullut, että Entity Framework on yksi Microsoftin aktiivisesti ajamista lähestymistavoista. Tietokannan kanssa työskentelyä varten tämä on Code First -niminen lähestymistapa. Tällöin kuvailet koodissa, miltä haluat tietokantasi näyttävän. Ja sitten otat sovelluksen käyttöön. Se muodostaa yhteyden tietokantaan, määrittää itse, mitkä taulukot ovat siellä ja mitkä eivät, ja luo kaiken tarvitsemasi.
Voit tehdä saman infrastruktuurisi kanssa. Ei ole eroa sillä, tarvitsetko tietokannan projektia varten vai tarvitsetko Windows-palvelimen projektia varten. Se on vain resurssi. Ja voit automatisoida tämän resurssin luomisen, voit automatisoida tämän resurssin määrityksen. Näin ollen joka kerta kun haluat testata jotain uutta konseptia, jotain uutta lähestymistapaa, sinun ei tarvitse kirjoittaa lippua devopsiin, voit yksinkertaisesti ottaa käyttöön erillisen infrastruktuurin itsellesi valmiista malleista, valmiista skripteistä ja ottaa sen käyttöön. siellä kaikki kokeilusi. Voit poistaa tämän, saada tuloksia ja raportoida siitä lisää.
Seuraava käytäntö, joka on myös olemassa ja on myös tärkeä, mutta jota harvat käyttävät, on Application Performance Monitoring.
Halusin sanoa vain yhden asian sovelluksen suorituskyvyn valvonnasta. Mikä tässä käytännössä on tärkeintä? Sovelluksen suorituskyvyn valvonta on suunnilleen sama asia kuin asunnon korjaus. Tämä ei ole lopullinen tila, se on prosessi. Sinun on tehtävä se säännöllisesti.
Hyvällä tavalla sovelluksen suorituskyvyn valvontaa olisi hyvä suorittaa lähes jokaisessa versiossa, vaikka, kuten ymmärrät, tämä ei aina ole mahdollista. Mutta se on suoritettava vähintään jokaiselle julkaisulle.
Miksi se on tärkeää? Koska jos koet yhtäkkiä suorituskyvyn laskun, sinun on ymmärrettävä selvästi miksi. Jos tiimilläsi on vaikkapa kahden viikon sprintit, niin vähintään kerran kahdessa viikossa sinun tulee asentaa sovelluksesi jollekin erilliselle palvelimelle, jossa sinulla on selkeästi kiinteä prosessori, RAM, levyt jne. Ja suorita ne samat suorituskykytestit. . Saat tuloksen. Katso kuinka se on muuttunut edellisestä sprintistä.
Ja jos huomaat, että nosto laski jyrkästi jossain, se tarkoittaa, että se johtui vain kahden viime viikon aikana tapahtuneista muutoksista. Näin voit tunnistaa ja korjata ongelman paljon nopeammin. Ja jälleen kerran, nämä ovat suunnilleen samoja mittareita, joilla voit mitata, kuinka menestyksekkäästi teit sen.
Seuraava käytäntö meillä on kokoonpanonhallintakäytäntö. Hyvin harvat ottavat tämän vakavasti. Mutta usko minua, tämä on itse asiassa erittäin vakava asia.
Äskettäin oli hauska tarina. Kaverit tulivat luokseni ja sanoivat: "Auta meitä suorittamaan sovelluksemme tietoturvatarkastus." Katsoimme koodia yhdessä pitkään, he kertoivat minulle sovelluksesta, piirsivät kaavioita. Ja plus tai miinus kaikki oli loogista, ymmärrettävää, turvallista, mutta oli yksi MUTTA! Heillä oli lähdehallinnassa konfiguraatiotiedostoja, mukaan lukien IP-tietokannan tuotannosta peräisin olevat tiedostot, kirjautumistunnukset ja salasanat yhteyden muodostamiseksi näihin tietokantoihin jne.
Ja minä sanon: "Kaverit, okei, olet sulkenut tuotantoympäristönne palomuurilla, mutta se, että sinulla on tuotantotietokannan käyttäjätunnus ja salasana suoraan lähdehallinnassa ja kuka tahansa kehittäjä voi lukea sen, on jo valtava turvallisuusriski. . Ja riippumatta siitä, kuinka erittäin turvallinen sovelluksesi on koodin kannalta, jos jätät sen lähdehallintaan, et koskaan läpäise auditointia missään." Siitä minä puhun.
Kokoonpanon hallinta. Meillä voi olla erilaisia kokoonpanoja eri ympäristöissä. Meillä voi esimerkiksi olla erilaisia kirjautumistunnuksia ja salasanoja tietokantoihin laadunvarmistusta, demoa, tuotantoympäristöä jne. varten.
Tämä konfigurointi voidaan myös automatisoida. Sen tulee aina olla erillään itse sovelluksesta. Miksi? Koska olet rakentanut sovelluksen kerran, ja sitten sovellukselle ei ole väliä, muodostatko yhteyden SQL-palvelimeen sellaisen ja sellaisen IP:n kautta vai sellaisen ja sellaisen IP:n kautta, sen pitäisi toimia samoin. Siksi, jos joku teistä yhtäkkiä edelleen koodaa koodissa olevaa yhteysmerkkijonoa, muista, että löydän sinut ja rankaisin sinua, jos löydät itsesi samasta projektista kanssani. Tämä sijoitetaan aina erilliseen kokoonpanoon, esimerkiksi web.config-tiedostoon.
Ja tätä kokoonpanoa hallitaan jo erikseen, eli tämä on juuri se hetki, jolloin kehittäjä ja ylläpitäjä voivat tulla istumaan samassa huoneessa. Ja kehittäjä voi sanoa: "Katso, tässä ovat sovellukseni binaarit. He työskentelevät. Sovellus tarvitsee tietokannan toimiakseen. Täällä binaarien vieressä on tiedosto. Tässä tiedostossa tämä kenttä vastaa sisäänkirjautumisesta, tämä on salasanasta, tämä on IP-osoitteesta. Ota se käyttöön missä tahansa." Ja se on yksinkertainen ja selkeä järjestelmänvalvojalle. Hän voi ottaa sen käyttöön todella missä tahansa hallitsemalla tätä kokoonpanoa.
Ja viimeinen käytäntö, josta haluaisin puhua, on käytäntö, joka liittyy hyvin, hyvin pilviin. Ja se tuo maksimaalisen vaikutuksen, jos työskentelet pilvessä. Tämä on ympäristösi automaattinen poistaminen.
Tiedän, että tässä konferenssissa on useita ihmisiä tiimeistä, joiden kanssa työskentelen. Käytämme tätä käytäntöä kaikissa tiimeissä, joiden kanssa työskentelen.
Miksi? Tietenkin olisi hienoa, jos jokaisella kehittäjällä olisi virtuaalikone, joka toimisi 24/7. Mutta ehkä tämä on sinulle uutinen, ehkä et kiinnittänyt huomiota, mutta kehittäjä itse ei toimi 24/7. Kehittäjä työskentelee yleensä 8 tuntia päivässä. Vaikka hän tulee töihin aikaisin, hänellä on suuri lounas, jonka aikana hän käy kuntosalilla. Olkoon 12 tuntia päivässä, kun kehittäjä todella käyttää näitä resursseja. Lainsäädäntömme mukaan meillä on viikossa 5 päivää seitsemästä työpäivänä.
Näin ollen arkipäivisin tämän koneen ei pitäisi toimia 24 tuntia, vaan vain 12, ja viikonloppuisin tämän koneen ei pitäisi toimia ollenkaan. Vaikuttaa siltä, että kaikki on hyvin yksinkertaista, mutta mitä tässä on tärkeää sanoa? Toteuttamalla tämän yksinkertaisen käytännön tässä perusaikataulussa voit vähentää näiden ympäristöjen ylläpitokustannuksia 70 %, eli otit kehittäjän, laadunvarmistuksen, demon, ympäristön hinnan ja jaat sen kolmella.
Kysymys kuuluu, mitä tehdä lopuilla rahoilla? Esimerkiksi kehittäjien tulisi ostaa ReSharper, jos he eivät ole jo ostaneet sitä. Tai pidä cocktail-juhlat. Jos sinulla oli aiemmin yksi ympäristö, jossa sekä dev että QA laidunsivat, ja siinä kaikki, nyt voit tehdä 3 erilaista, jotka eristetään ja ihmiset eivät häiritse toisiaan.
Mitä tulee diaan jatkuvalla suoritusmittauksella, miten voimme verrata suorituskykyä, jos projektissa oli 1 tietuetta tietokannassa, kaksi kuukautta myöhemmin niitä on miljoona? Miten ymmärtää miksi ja mikä on suorituskyvyn mittaamisen tarkoitus?
Tämä on hyvä kysymys, koska sinun tulee aina mitata suorituskykyä samoilla resursseilla. Toisin sanoen otat käyttöön uuden koodin, mittaat uuden koodin suorituskykyä. Sinun on esimerkiksi testattava erilaisia suorituskykyskenaarioita, oletetaan, että haluat testata kuinka sovellus toimii kevyellä kuormituksella, jossa on 1 käyttäjää ja tietokannan koko on 000 gigatavua. Mittasit sen ja sait numerot. Seuraavaksi otamme toisen skenaarion. Esimerkiksi 5 käyttäjää, tietokannan koko 5 teratavu. Saimme tulokset ja muistimme ne.
Mikä tässä on tärkeää? Tärkeää tässä on, että skenaariosta, datamäärästä, samanaikaisten käyttäjien määrästä jne. riippuen saatat törmätä tiettyihin rajoituksiin. Esimerkiksi verkkokortin rajoihin tai kovalevyn rajoihin tai prosessorin ominaisuuksien rajoihin. Tämä on se, mitä sinun on tärkeää ymmärtää. Eri skenaarioissa törmäät tiettyihin rajoihin. Ja sinun on ymmärrettävä numerot, kun osut niihin.
Puhutaanko suorituskyvyn mittaamisesta erityisessä testiympäristössä? Eli tämä ei ole tuotantoa?
Kyllä, tämä ei ole tuotantoa, tämä on testiympäristö, joka on aina sama, jotta voit verrata sitä aikaisempiin mittauksiin.
Ymmärretty kiitos!
Jos kysymyksiä ei ole, luulen, että voimme lopettaa. Kiitos!
Lähde: will.com