Tarkempi esittely

Ympäristöt: hallitut julkaisut DEVistä TESTin kautta PRODiin

DEVissä on käynnissä useita työkokonaisuuksia yhtä aikaa, ja julkaisuun otetaan yleensä vain osa niistä. Valitse valmis työ, niin Model One kokoaa TESTin tai PRODin seuraavan julkaisun kaikkine osineen, joita työ tarvitsee, tarkistaa sen ja kirjoittaa migraation ja dbt-projektin juuri tätä tilaa varten. Kukin ympäristö päättää, kuka julkaisun hyväksyy; tiimisi tai julkaisuputkesi vie sen käyttöön.

Environments-välilehti, jossa DEV, TEST ja PROD rinnakkain: kunkin ympäristön kohdetietokannat ja versio, jota kunkin kirjataan ajavan, PRODin tietokannan poikkeamatarkistus, kunkin ympäristön julkaisu latauksineen, Promote… ja edellisessä ympäristössä odottavat työkokonaisuudet
Yleiskuva

Siirrä työtä, älä malleja

DEV, TEST ja PROD eivät ole kolme mallin kopiota, jotka on pidettävä keskenään ajan tasalla. Ne ovat kolme paikkaa, joihin valikoitu valmis työ on edennyt.

Tietovarastotiimi julkaisee harvoin kaiken kerralla. DEVissä on käynnissä useita työkokonaisuuksia yhtä aikaa, julkaisuun otetaan yleensä vain muutama, ja yksi lähdetaulu voi syöttää kahta entiteettiä, joista vain toinen on valmis. Kun koko malli kopioidaan ympäristöstä seuraavaan, keskeneräinen työ kulkee valmiin mukana, ja tiimit päätyvät käsin poimittuihin skripteihin ja taulukkoon siitä, mitä vietiin minnekin.

Model Onessa DEV on live-projekti, jossa tiimi mallintaa yhdessä, ja jokainen muutos kirjautuu sen työkohteen alle, jota tekijä on työstämässä. TESTissä ja PRODissa on kummassakin julkaisu: mallin versio, jota kukaan ei muokkaa ja joka muuttuu vain, kun siihen viedään siirto, työn poisto tai palautus aiempaan julkaisuun. Kysymykseen ”mitä PRODissa on?” vastaa Environments-välilehti, työkokonaisuus kerrallaan.

Siirto voi ottaa kokonaisia työkokonaisuuksia, yksittäisiä työkohteita tai yksittäisiä osia. Model One tuo mukaan sen, mitä ne tarvitsevat, ottaa mukaan vastaavan muutoksen kaikkeen, minkä ne muuten rikkoisivat, ja tarkistaa julkaisun samoilla säännöillä kuin tallennuksen. Sitten se kirjoittaa kunkin kohdetietokannan migraation, dbt-projektin ja julkaisutiedotteen juuri tätä julkaisua varten. PROD saa arvonsa TESTin julkaisusta, joten tuotantoon päätyy se, mitä testattiin.

Model One ei vieläkään vie mitään käyttöön eikä koskaan muodosta yhteyttä tietokantoihisi. Kullakin ympäristöllä on omat hyväksyjänsä ja tarkistuksensa, ihminen tai ympäristön julkaisuputki ajaa hyväksytyt tiedostot, ja ihminen vahvistaa jokaisen käyttöönoton.

Läpikäynti

Yksi työkokonaisuus DEVistä PRODiin

Kuusi vaihetta ympäristöjen määrittelystä siihen, että löydät suoraan PRODiin tehdyn muutoksen.

Vaihe 1

Määrittele ympäristöt ja näe, mitä kussakin on

Omistaja lisää ympäristöt järjestyksessä: ensin live-projekti, yleensä DEV, sitten esimerkiksi TEST ja PROD. Kukin ympäristö nimeää fyysiset mallit, jotka se vie käyttöön, ja kohdetietokannan, jonka nimellä kunkin mallin käyttöönotot kirjataan. Environments-välilehdellä kullakin ympäristöllä on oma sarakkeensa: sen kohteet, sen julkaisu tiedostoineen, matkalla olevat siirrot ja edellisessä ympäristössä odottavat työkokonaisuudet. Minkä tahansa julkaisun voi avata luettavaksi mallinnusnäkymiin.

  • Enintään 20 ympäristöä järjestyksessä; live-projekti on ensimmäinen, eikä sillä ole julkaisua
  • Kullekin ympäristölle sen sisällöstä generoidut DDL, dbt-projekti ja migraatiot ladattaviksi
  • Yksi dbt-projekti kaikille ympäristöille, ja profiles.yml-tiedostossa oma kohde kullekin
  • Ympäristön julkaisu tai mikä tahansa versio aukeaa vain luettavaksi Logical-, Flow-, Dictionary- ja Physical-näkymiin
Environments-välilehti, jossa DEV, TEST ja PROD rinnakkain: kunkin ympäristön kohdetietokannat ja versio, jota kunkin kirjataan ajavan, PRODin tietokannan poikkeamatarkistus, kunkin ympäristön julkaisu latauksineen, Promote… ja edellisessä ympäristössä odottavat työkokonaisuudet
Vaihe 2

Anna jokaisen muutoksen kertoa, mihin työhön se kuuluu

Kukin valitsee työkohteen, jota on työstämässä, ja hänen mallimuutoksensa kirjautuvat sen alle, samoin kuin muutokset, jotka OneAssist ja hänen omat agenttinsa tekevät hänen puolestaan. Työkokonaisuus on työkohde ja kaikki sen alla olevat, esimerkiksi epic ja sen käyttäjätarinat, joten projekti tietää, mitä kukin kokonaisuus muutti. Kunkin ympäristön sarake näyttää edellisessä ympäristössä odottavat työkokonaisuudet, niiden muutosten määrän ja kohdat, joissa kaksi kokonaisuutta muutti samaa asiaa.

  • Ilman valittua työkohdetta tehdyt muutokset odottavat, että muokkaaja kohdistaa ne
  • Aiempi työ, tuonnit ja palautukset kohdistetaan vertaamalla mallia versioon
  • Omistaja voi vaatia työkohteen jokaiselle mallimuutokselle
  • Työkohteessa näkyy merkki jokaisesta ympäristöstä, jossa se on

Tehtävät ja työstettävä työ

TESTin ja PRODin sarakkeet: DEVissä odottava Sales Mart, TESTin neljä työkokonaisuutta ja samat neljä TESTissä odottamassa PRODiin muutosten määrineen sekä epic #12, josta PRODissa on vain osa
Vaihe 3

Valitse valmis työ, ja mukaan tulee se, mitä työ tarvitsee

Promote… avaa ohjatun toiminnon. Valitse edellisessä ympäristössä odottavat työkokonaisuudet, lisää yksittäisiä työkohteita tai vertaa kahta ympäristöä ja valitse osat yksi kerrallaan. Model One kokoaa seuraavan julkaisun ympäristön nykyisen julkaisun päälle ja ottaa valitut muutokset edellisestä ympäristöstä: TESTiin live-mallista ja PRODiin TESTin julkaisusta. Se näyttää, mitä tulee mukaan ja miksi, mitä se vain tarjoaa lisättäväksi, ja kohdat, joissa kaksi työkohdetta muutti samaa kenttää.

  • Valitse kokonaisia työkokonaisuuksia, yksittäisiä työkohteita tai osia, kuten yksi attribuutti, yksi sarakkeen asetus tai yksi Flow-vaihe
  • Valinnan tarvitsemat osat tulevat mukaan: attribuutti tuo entiteettinsä ja terminsä, Flow entiteettinsä ja lähdeobjektinsa
  • Jos poistettava osa on vielä ympäristön käytössä, mukaan tulee vastaava muutos, tai siirto estetään ja syy kerrotaan
  • Kahden työkokonaisuuden yhteinen lähdeobjekti kulkee ensin valmistuvan mukana ilman toisen lisäämiä sarakkeita
  • Graafimallit ja käsitteet siirretään kuten muukin malli
Promote-toiminto PRODiin sivulla What comes along: kahden valitun työkokonaisuuden entiteetit, Flow ja suhde sekä lähdeobjekti ja lähdejärjestelmä, joita Flow tarvitsee, kukin syineen
Vaihe 4

Tarkista, hyväksy ja vie käyttöön se, mikä hyväksyttiin

Ennen kuin siirtoa voi pyytää, Model One tarkistaa julkaisun samoilla säännöillä kuin tallennuksen ja arvioi vain sen, mitä siirto tuo mukanaan. Kullakin ympäristöllä on omat hyväksyjänsä ja tarkistuksensa. Kunkin kohdetietokannan migraatio, dbt-projekti ja työkokonaisuuksittain ryhmitelty julkaisutiedote tallennetaan SHA-256-tiivisteineen siirtopyynnön hetkellä, ja tiedosto, joka ei enää täsmää, hylätään. Ihminen tai ympäristön julkaisuputki ajaa ne, ja ihminen vahvistaa käyttöönoton Mark deployed -toiminnolla.

  • Ei hyväksyntää lainkaan, jolloin siirtäjä päättää itse, tai useita nimettyjä hyväksyjiä
  • Ympäristökohtaiset tarkistukset, kuten työkohteiden tila In Review TESTiin ja Done PRODiin
  • Migraatio, joka nimeää uudelleen Flow'n lukeman sarakkeen, viedään yhdessä dbt-projektin kanssa yhtenä käyttöönottona, migraatio ensin
  • Siirto, jonka kohdeympäristö on sillä välin muuttunut, merkitään vanhentuneeksi ja pyydetään uudelleen
  • Model One ei vie mitään käyttöön: ihminen vahvistaa jokaisen käyttöön viedyn tiedoston
Promote-toiminnon Checks-sivu siirrosta PRODiin: ympäristön kaikki tarkistukset läpäisty, sitten kootun julkaisun havainnot ja siitä luotava dbt-projekti
Vaihe 5

Vie jokainen julkaisu Gitiin julkaisuputkesi käyttöön

Kytke projekti GitHubin tai Azure DevOpsin repositorioon (github.com tai dev.azure.com), niin omistaja voi määrätä, että ympäristön jokainen hyväksytty julkaisu commitoidaan ympäristön omaan haaraan ja kansioon ja merkitään tagilla, jossa on ympäristö ja versio, esimerkiksi prod-v14. Commit sisältää täsmälleen hyväksytyt tiedostot käyttöönottojärjestykseen numeroituina sekä julkaisutiedotteen ja manifestin. Sen viesti linkittää jokaisen työkohteen takaisin Model Oneen, joten Jiran tai Azure DevOpsin tiketti voi viitata siihen.

  • Yksi commit julkaisua kohden, kunkin ympäristön omassa haarassa, kuten model-one/prod
  • Migraatio, dbt-projekti, julkaisutiedote, koko DDL ja manifesti, jossa jokaisen tiedoston SHA-256
  • Model One ei koskaan kirjoita haaran historiaa uudelleen, ja se varoittaa, jos joku muuttaa ympäristön kansiota
  • Lähetä myös nykyinen malli tai mikä tahansa versio Gitiin Import / Export -valikosta tai versioiden aikajanalta
Vaihe 6

Löydä, mitä PRODissa muutettiin Model Onen ohi

Jokaisen muutoksen pitäisi kulkea PRODiin DEVin ja siirron kautta, mutta tietokantaa voidaan silti muuttaa suoraan. Model One ei koskaan muodosta siihen yhteyttä. Sen sijaan liität tai lataat tietokannasta viedyn skeeman, ja poikkeamatarkistus vertaa sen tauluja, sarakkeita, tietotyyppejä, NULL-sallittavuutta ja avaimia siihen, mitä ympäristön julkaisu luo. Ota poikkeama malliin DEVissä, lataa skripti, joka palauttaa sen, tai hyväksy se tunnetuksi perustellen.

  • Viennin lukee SQL DDL -tuonnin jäsennin, kohteen omalla SQL-murteella
  • Adopt into DEV kirjaa poikkeamat Bugiin ja tekee malliin ne muutokset, jotka siihen sopivat
  • Revert kirjoittaa skriptin, joka palauttaa tietokannan julkaisun mukaiseksi; dataa hävittävät vaiheet on kommentoitu pois
  • Omistaja voi vaatia tuoreen poikkeamatarkistuksen ilman ratkaisemattomia eroja ennen jokaista siirtoa
PRODin tuotantotietokannan poikkeamaraportti: kolme avointa eroa tauluittain, kussakin julkaisun ja tietokannan arvo, ja niistä kaksi valittuna toimintoja Adopt into DEV, Revert ja Accept as known varten
Kohokohdat

Tehty sitä varten, miten julkaisut oikeasti etenevät

Osittaiset julkaisut, kiireelliset korjaukset ja satunnainen askel taaksepäin.

PROD saa sen, mitä TESTissä oli

Siirto PRODiin ottaa arvonsa TESTin julkaisusta eikä DEVistä, joten tuotantoon päätyy se, mitä testattiin.

Tie takaisin

Ota työkokonaisuus pois ympäristöstä tai palauta ympäristö aiempaan julkaisuun. Molemmat hyväksytään ja viedään käyttöön kuten siirto, ja paluumigraation dataa hävittävät vaiheet jäävät kommentoiduiksi.

Pikareitti kiireelliselle korjaukselle

Jos omistaja sallii, DEVissä tehty kiireellinen korjaus voi mennä suoraan PRODiin. Pyytäjä kertoo syyn, julkaisuhistoria kirjaa sen, ja kaikki muut tarkistukset ovat voimassa.

Jokainen julkaisu luettavissa

Avaa minkä tahansa ympäristön sisältö mallinnusnäkymiin vain luettavaksi kaikille, myös omistajille. Versiota, joka on tai on ollut ympäristön julkaisu, ei voi poistaa.

Roolit julkaisua varten

Omistajat määrittelevät ympäristöt sääntöineen, omistajat ja jäsenet tekevät siirtoja, kunkin ympäristön nimeämät hyväksyjät hyväksyvät, ja katselijat näkevät jokaisen ympäristön ilman toimintoja.

Agentit esikatselevat, ihmiset päättävät

OneAssist ja omat agenttisi voivat esikatsella siirron, työn poiston tai palautuksen ja lukea poikkeamaraportit. Hyväksyminen ja käyttöönotto jäävät ihmisille.

Jatka tutustumista

Mistä julkaisu koostuu

Julkaisu kokoaa kaikissa muissa moduuleissa tehdyn työn.

Vie yksi työkokonaisuus DEVistä PRODiin kanssamme

Tuo mukanasi äskettäin julkaisemasi muutos. Siirrämme siitä yhden työkokonaisuuden TESTin kautta PRODiin, kun muu työ jää DEViin, ja käymme läpi valinnat, mukaan tulevat osat, tarkistukset, hyväksynnän, skriptit ja vahvistetun käyttöönoton.