Yksi Power Platformin heikkouksista on aina ollut sen ALM (application lifecycle management) ominaisuudet. Tekemisen saa versionhallinnan ja automaattiset julkaisuputket mukaan, mutta näiden virittely vie oman aikansa. Mikäli työn kohde on pieni (Power Platformissa usein on), ei tätä usein nähdä järkeväksi, vaan päädytään viemään ratkaisupaketteja (solution package) manuaalisesti ympäristöstä toiseen.

Toinen haaste on kansalaiskehittäjyys. Sovelluskehityksestä tutut julkaisuputket ovat luonnollisesti täyttä hepreaa aivan toisesta ympäristöstä tuleville kansalaiskehittäjille. Mitä vaikeammaksi (tekeminen ja ymmärtäminen) tehdään, sitä varmemmin kansalaiskehittäjät jättävät leikin sikseen ja palaavat tekemään tarvitsemansa ratkaisut Excelillä ja SharePoint -listoilla.

Tähän rakoon Microsoft kehitti Power Platform julkaisuputket (pipelines). Yksinkertaistettu, kansalaiskehittäjien ymmärrettävä, versio aiheesta, joka on myös todella helppo ottaa käyttöön.

Ratkaiseeko tämä kaikki ongelmat?

Katsotaan.

Tarvittavat ympäristöt

Luodaan ensimmäisenä kaikki tarvittavat ympäristöt. Tyypillisesti meillä on erilliset kehitys (dev), testi (test) ja tuotanto (prod) -ympäristöt.

Kehitys tehdään vain ja ainoastaan kehitysympäristössä, josta valmis versio viedään testiin testattavaksi. Mikäli kaikki on kunnossa, sama versio viedään tuotantoon loppukäyttäjien käytettäväksi.

Jotta Power Platformin julkaisuputkia voidaan käyttää, tulee tuotantoympäristön olla tyypiltään tuotantoympäristö (Production). Muut ympäristöt voivat olla kehittäjä (developer) tai hiekkalaatikko (sandbox) -ympäristöjä.

Tarvitsemme kuitenkin vielä yhden ympäristön. Siellä (Pipelines Host) suoritetaan kaikki julkaisuun liittyvät tehtävät. Ympäristön tulee olla tyypiltään tuotantoympäristö ja Microsoft suosittelee että se pyhitetään tähän käyttöön. Älä siis käytä nykyistä CoE-ympäristöäsi tähän tarkoitukseen. Tiedän että mieli tekisi.

Sama isäntäympäristö voi pyörittää useita eri julkaisuputkia. Yksi isäntäympäristö riittää siis pitkälle.

Alla omat ympäristöni.

Asennus

Olemme luoneet tarvittavat ympäristöt. Seuraavaksi asennamme isäntäympäristöön (Pipelines Host) tarvittavan sovelluksen (Admin Center -> Environments -> Pipelines Host > Dynamics 365 Apps).

Valitaan asennettava sovellus (Power Platform Pipelines) ja käynnistetään asennus.

Hyväksytään ehdot.

Asennus kestää aikansa.

Asennuksen valmistuttua, voimme tehdä tarvittavat asetukset.

Konfigurointi

Avataan ympäristö, jossa julkaisuputkia suoritetaan.

Sovelluksen nimeä (Solution Health Hub) klikkaamalla avautuu sovellusvalikko. Avataan sieltä Deployment Pipeline Configuration.

Tällä sovelluksella hallitaan julkaisuputkia. Sovelluksesta näkee myös tehdyt julkaisut vaiheineen (Run history) sekä ratkaisupaketit, joita niissä on käytetty (Solution artifacts).

Ympäristöt

Ensimmäisenä määritellään, mitä ympäristöjä julkaisuputkiimme sisältyy. Ympäristöt, joissa kehitetään ovat tyypiltään kehitysympäristöjä (Development Environment). Loput ympäristöt ovat kohdeympäristöjä (Target Environment).

Tarvittava ympäristön tunniste (Environment ID) löytyy Power Platform admin centeristä.

Näin olemme luoneet julkaisuputkessamme käytettävät ympäristöt. Käytä ympäristöjen niminä niiden oikeita nimiä. Helpottaa jatkossa kummasti.

Seuraavaksi määritellään julkaisuputki. Näitä voi olla useita, mutta tarvitsemme tällä kertaa vain yhden. Eli tämän.

Nimetään julkaisuputki ja annetaan sille kuvaus (1). Tallennuksen (2) jälkeen voimme liittää siihen kehitysympäristön (3), joka ilmestyy kehitysympäristöjen listalle (4).

Luodaan julkaisuputki, jota käytetään sovelluksen X julkaisuun (App X Pipeline).

Seuraavaksi määritellään julkaisun vaiheet (Deployment Stages).

Ensimmäinen vaihe on julkaista paketti kehitysympäristöstä testiin. Ensimmäisen vaiheen edeltävä julkaisuvaihe (Previous Deployment Stage) jätetään tyhjäksi.

Toien vaihe on julkaisu testistä tuotantoon. Sitä edeltää aina julkaisu kehityksestä testiin (Deploy to Test, Previous Deployment Stage).

Määritykset on tehty ja voimme aloittaa julkaisun tällä julkaisuputkella.

Ensimmäinen kerta vei hieman aikaa, mutta jatkossa uuden julkaisuputken luominen vie vain muutaman minuutin. Aivan uskomatonta.

Tyypillisesti julkaisuputket määrittelee joku muu kuin ratkaisujen kehittäjät.

Mutta mitä tällä nyt sitten voi tehdä? Miten tämä muuttaa tekemistä?

Julkaisu kehityksestä testiin

Esimerkkiratkaisumme sisältää seuraavat komponentit

  • Kolme taulua
  • Mallipohjainen Power Apps
  • Käyttöoikeusrooli
  • Ympäristömuuttuja
  • Yhteysviittaus (connection reference)

Kaikki tämä on pakattu yhden ja saman ratkaisupaketin sisään.

Olemme saaneet ensimmäisen version valmiiksi ja haluamme viedä sen testiympäristöön testattavaksi.

Avataan ympäristön julkaisuputket (pipelines) (1) ja valitaan mitä niistä haluamme käyttää (2). Näemme että testiin ja tuotantoon ei ole viety vielä mitään. Käynnistetään julkaisu testiin (3).

Vahvistetaan valinta.

Olemme viemässä pakettia testiin, mutta kohdeympäristössä ei ole yhteysviittauksemme tarvitsemaa yhteyttä. Prosessi pakottaa meidät luomaan sen etukäteen.

Sama pätee ympäristömuuttujiin.

Lopuksi vielä yksi vahvistus, ennen kuin varsinainen julkaisu alkaa.

Ja sitten odotellaan.

Valmista!

Testivaiheen jälkeen teemme muutoksia ja korjauksia kehitysympäristössä ja suoritamme julkaisun uudelleen. Olemme vienneet testiin versiot 1.0.0.1 ja 1.0.0.2.

Julkaisu tuotantoon

Julkaisu tuotantoon tehdään kuten julkaisu testiin. Ensimmäisellä kerralla luodaan puuttuvat komponentit (yhteys ja ympäristömuuttujan arvo).

Julkaisuketjussa kohdeympäristöön viedään aina viimeisin edeltävään ympäristöön asennettu versio. Esimerkissämme siis versio 1.0.0.2.

Julkaisuhistoria

Jokainen julkaisu tallentuu isäntäkoneelle. Pääsemme tarkastelemaan historiaa Deployment Pipeline Configuration -sovelluksella.

Voimme selata julkaisun eri vaiheita.

Artifakteista löytyvät julkaisussa käytetyt paketit.

Mikä julkaisuputkissa on hyvää?

Julkaisuputket tarjoavat vihdoin tekijöille helpon tavan julkaista tuotokset eri ympäristöihin. Tämä mahdollistaa nykyistä huomattavasti laajemman erillisten kehitys, testi ja tuotantoympäristöjen käytön.

Julkaisussa ratkaisupaketin manuaalinen vienti ja tuonti jää kokonaan pois. Tämä on yhtä juhlaa, mikäli organisaatiossa on tiedostojen lataaminen estetty MCAS-palvelulla.

Ratkaisupaketista myös näkee suoraan, mitkä versiot siitä on asennettu mihinkin ympäristöön ja milloin.

Mikä julkaisuputkissa on huonoa?

Onhan näissä vielä omat puutteensa. Et voi esimerkiksi (ainakaan vielä)

  • Palauttaa ympäristöä aiemmin asennettuun versioon
  • Kytkeä julkaisuputkea versionhallintaan, jotta saisit kaiken aina myös itsellesi talteen
  • Lisätä julkaisuprosessiin itse tehtyjä työnkulkuja (esim. hyväksymiskuittaukset testaajilta, jonka jälkeen automaattinen julkaisu tuotantoon)

Suurin mörkö monille saattaa kuitenkin olla julkaisuputkien käyttämät hallitut ratkaisupaketit. Mikäli olet jo asentanut testi/tuotantoympäristöön hallitsemattomia ratkaisupaketteja, tulee sinun ensin muuttaa ne hallituiksi.

Dataverse (ja Dynamics 365) -yhteisössä käydään aktiivista kädenvääntöä siitä, tulisiko käyttää hallittuja (managed) vai hallitsemattomia (unmanaged) ratkaisupaketteja. Microsoft suosittelee hallittuja, yhteisö pääasiassa hallitsemattomia.

Mielestäni julkaisuputket soveltuvat kuitenkin mainiosti käyttöön, mikäli ratkaisu voidaan kokonaisuudessaan (poislukien flow’t ja canvas Power Appsit) sijoittaa yhteen ratkaisupakettiin. En kuitenkaan suosittele näiden käyttöönottoa omin päin, mikäli ymmärrys ratkaisupaketeista ja niiden sisältöjen mahdollisista riippuvuuksista ei ole riittävä.

Muussa tapauksessa riski kaikenlaiselle sekoilulle on huomattava. Siitä ehkä lisää seuraavassa jutussa.