Kirjoitin keväällä Power Platformin julkaisuputkista (pipelines). Mielestäni varsin siisti ominaisuus. Mutta onko siinä jotain vikaa, kun se ei tunnu olevan käytössä oikein missään?
Ei. Ominaisuudessa ei itsessään ole vikaa. Sillä vain yritetään ratkaista monimutkaista ongelmaa yksinkertaisella tavalla, mikä on harvoin helppoa.
Mutta mikä tässä nyt on niin monimutkaista?
Hallitut (managed) ja hallitsemattomat (unmanaged) ratkaisut (solution)
Power Platformissa ratkaisuja siirretään ympäristöstä toiseen ratkaisupakettien (solution package) avulla. Ratkaisupaketti voi olla hallittu tai hallitsematon.
Mikä näiden ero on?
- Hallittu – Jokaisella ratkaisupaketilla on kohdeympäristössä oma muutoskerros (managed layer), jossa paketin muutokset ovat
- Hallitsematon – Kaikkien asennettujen ratkaisupakettien sisältämät muutokset ovat yhdessä ja samassa muutoskerroksessa (unmanaged layer)
Mikä näiden ero käytännössä on? Ne tärkeimmät:
Hallittu ratkaisu osaa käsitellä poistot. Jos poistat kehitysympäristössä taulusta sarakkeen ja viet paketin testiympäristöön, poistuu sarake myös sieltä. Tämä koskee kaikkia objekteja. Hallitsemattomien ratkaisujen kanssa poistot tehdään kaikissa ympäristöissä käsin.
Hallittua ratkaisua ei voi asennuksen jälkeen muokata. Mitenkään. Voit toki tehdä sen päälle hallitsemattomia muutoksia. Jolloin sinulla on ympäristössä sekä hallittuja että hallitsemattomia kerroksia. Ja olet nopeasti solmussa.
Hallitut ratkaisut on se ”oikea”, Microsoftin suosittelema, tapa. Näen niitä kuitenkin käytettävän aika vähän.
Miksi näin?
Koska niiden käyttö vaatii huolellista suunittelua. Muutoin leikistä voi tulla kallista. Ja voi siitä tulla vaikka suunnittelisikin.
Jos jaat ratkaisun huolimattomasti eri paketteihin, niiden välillle voi syntyä ajan saatossa riippuvuuksia. Lopputuloksena voit päätyä tilanteeseen, jossa et voi asentaa tuotantoon mitään pakettiasi. Ja sitten ihmetellään.
Nyrkkisääntö onkin (hallitut ratkaisut), että yhtä ympäristöä kohden on yksi ratkaisupaketti. Tai maksimissaan siten että Canvasit ovat omassaan, Flow’t omassaan ja kaikki muu omassaan. Mutta miten vien tuotantoon vain osan tietomallimuutoksista?
Jos tämä tehdään kunnolla, tarvitsetkin
- kehitysympäristön per muutostyö
- versionhallinnan, josta (rakentamallasi) automaatiolla luodaan näitä kehitysympäristöjä
- staging/build ympäristön, johon koostetaan paketti, joka voidaan viedä eteenpäin niihin oikeisiin ympristöihin (testi, tuotanto jne)
Sieltä sitä kustannusta alkaa syntymään. Perustelua yhtään isommissa hankkeissa. Mutta muutaman kansalaiskehittäjän pienessä yhteisponnistelussa? Ei. Toki näiden kahden ääripään (vapaasti käsin asentaminen vs kehitysympäristö per muutos) väliltä löytyy muitakin vaihtoehtoja.
Palataan kuitenkin niihin Power Platform julkaisuputkiin.
Ongelma 1 – Työ on jo aloitettu
Power Platformin julkaisputket -ominaisuus käyttää hallittuja ratkaisuja. Mikäli olet jo ehtinyt viemään ratkaisun tuotantoympäristöön hallitsemattomana pakettina, tulee sinun todennäköisesti luoda uusi tuotantoympäristö ottaaksesi julkaisputket käyttöön.
Mikäli tuotantoympäristöön on ehtinyt kertymään paljon dataa, on migraatiossa oma työnsä.
Ongelma 2 – Monta ratkaisua, osin yhteinen tietomalli
Tämä on mielestäni se todellinen haaste. Ympäristössä asuvat ratkaisut hyödyntävät usein osin samoja tauluja (asiakas, projekti, käyttäjät, assetti tms). Tällöin ratkaisujen välille syntyy helposti pelättyjä riippuvuuksia.
Otetaan yksinkertainen esimerkki.
Meillä on kehitysympäristössä kaksi ratkaisua.
- Ratkaisu 1 käyttää omaa tauluaan (taulu A), jossa on viittaus (LookUp) Account-tauluun
- Ratkaisu 2 käyttää sekin omaa tauluaan (taulu B). Siinäkin on viittaus Account-tauluun

Ratkaisut on pakattu omiin ratkaisupaketteihinsa, joissa eri kansalaiskehittäjät niitä työstävät. On myös yhteisesti sovittu, ettei account-tauluun tehdä muutoksia.
Ratkaisu 2:en kehittäjä on kuitenkin epähuomiossa lisännyt ratkaisuunsa account-taulun kaikki objektit. Nyt hän ei voi viedä ratkaisu 1:n asennuksen jälkeen omaa ratkaisuaan tuotantoon, ennen kuin hän poistaa account-taulun objektit ratkaisustaan.
Yhteenveto
Milloin Power Platformin julkaisuputkia voi helposti ja turvallisesti käyttää? Silloin kun ympäristössä on vain yksi ratkaisu jota kehitetään. Ja tälle ratkaisulle on oma tuotantoympäristönsä. Tällöin pakettien välille ei synny riippuvuusongelmia.
Mikäli tilanne on jotain muuta, kannataa käyttää aikaa suunnitteluun ennen kuin tekee mitään. Ei se mahdotonta ole. Mutta vaatii tarkkuutta ratkaisujen (solution) sisältöjen sekä jaettujen taulujen muutosten koordinoinnin kanssa.
Mikään automaattinen tie onneen se ei ole.