Kun Centero Software Manageria otetaan käyttöön uudelle asiakkaalle, meiltä kysytään usein kuinka sovellusten jakelu kannattaa tehdä. Tähän ei ole olemassa yhtä tyhjentävää vastausta, mutta käytännön kokemukseen perustuen pystymme antamaan vinkkejä, kuinka jakeluprosessit kannattaa toteuttaa.
Jakeluprosessilla tarkoitetaan tapahtumasarjaa, joka käynnistyy aina uutta sovellusversiota julkaistaessa päätelaiteympäristössä. Jakeluprosessi koostuu erilaisista ryhmistä ja etukäteen mietityistä jakeluiden aikataulutuksista. Sovellusversioiden jakelun lisäksi samankaltaisia jakeluprosesseja hyödynnetään myös käyttöjärjestelmien päivityksissä.

Miksi jakeluprosessit ovat tärkeitä?

Jakeluprosessien hyöty on siinä, että sovellusversioiden hallinta pysyy ylläpitäjällä. Mahdollisissa sovellusversion ongelmatapauksissa asiaa pystytään selvittämään ja korjaamaan paremmin, kun ympäristössä ei ole lukuisia eri versioita. Tämän vuoksi uusia sovellusversioita ei kannata jakaa kaikille ympäristön työasemille samaan aikaan.

Jos käytämme perinteistä kaksivaiheista jakelua, johon sisältyvät testi- ja tuotantojakelu, voidaan ongelmat havaita jo testivaiheessa ja keskeyttää jakelu. Tällöin vika esiintyy vain pienessä osassa koneita, eikä koko ympäristö lamaudu.

Esimerkki kaksivaiheisesta jakeluprosessista:

Jakeluryhmä Kone/käyttäjämäärä Jakelu käynnistyy
Testiryhmä 15 Heti
Tuotanto 200 7 päivää testijakelun jälkeen

Minkälainen on hyvä jakeluprosessi?

Hyvässä jakeluprosessissa testaukseen kiinnitetään riittävästi huomiota ja sovellusversioita testaavat henkilöt, jotka ymmärtävät miten sovelluksen pitäisi toimia. Testikäyttäjien on myös hyvä olla tietoisia uusista jakeluista, joten tiedottaminen on suositeltavaa esimerkiksi sähköpostitse. Yleisesti ottaen yrityksen IT-osastot ovat hyviä testijakeluiden kohteita päivittäin käytetyissä normaaleissa sovelluksissa, mutta IT-alalla työskentely ei tarkoita, että tietäisi kaiken kaikista sovelluksista. Mikäli jotakin sovellusta käytetään vain yhdellä osastolla yrityksessä, kannattaa testikäyttäjiä pyytää sieltä.

Testijakeluissa kannattaa kiinnittää huomion siihen, kuinka paljon testiryhmässä on jäseniä verrattuna varsinaiseen tuotantojakeluun. Jos testiryhmän jäsenmäärä on laskenut ajan myötä kone- tai henkilöstövaihdosten vuoksi huomattavan pieneksi, ei testausta välttämättä saada tehtyä luotettavasti. Tämän vuoksi testiryhmän jäsenmäärää kannattaa seurata, tai jos jakelujärjestelmä sen sallii, niin käyttää kyselyitä ja ylläpitää niitä dynaamisesti erilaisilla säännöillä.

Jonkinlaisena nyrkkisääntönä voi pitää testiryhmien koossa, että ne olisivat noin 10 % siitä kokonaismäärästä, jolle sovellusversiota jaetaan. Testijakelun ja tuotantojakeluiden välissä on yleensä hyvä olla aikaa noin viikko, sillä siinä ajassa mahdolliset ongelmat ehditään huomata ja jakelut keskeyttää.

10 prosentin nyrkkisääntö ja viikko testauksen ja tuotantojakelun välillä ei tietenkään sovellu kaikkiin ympäristöihin, sillä jos yrityksessä on 20 000 työasemaa, niin 2 000 testilaitetta on jo suuri määrä työasemia, jos sovelluksessa havaitaan yhteensopivuusongelmia. Isommissa yrityksissä kannattaa kaksivaiheisen jakeluprosessin sijaan käyttää useampia vaiheita.

Esimerkki jakeluprosessista noin 10 000 työaseman ympäristölle

Jakeluryhmä Jäsenet Konemäärä Jakelu käynnistyy
Tekninen testaus Vain testaukseen käytettäviä testikoneita 2 Heti
Testiryhmä IT-henkilöstön työasemat 60 Heti kun tekninen testaus OK
Pilottiryhmä Satunnaisesti valittuja koneita 800 7 päivää testijakelun jälkeen
Tuotanto 1 Toimistokäyttäjien työasemat 4000 7 päivää pilottijakelun jälkeen
Tuotanto 2 Kentällä olevia laitteita 3500 3 päivää 1. tuotantojakelun jälkeen
Tuotanto 3 Toiminnan kannalta kriittisempiä laitteita 1500 7 päivää 2. tuotantojakelun jälkeen

Kuinka jakeluprosesseja hyödynnetään Centero Software Managerissa?

Me Centerolla testaamme jokaisen paketoimamme sovelluksen tarkasti erilaisia tilanteita ajatellen. Mutta miksi sitten asiakkaan tulisi käyttää yllä mainittuja jakeluprosesseja ympäristössään? Jokainen ympäristö on erilainen määritysten ja muiden sovellusten osalta, joten on huomioitava mahdolliset yhteensopivuusongelmat. Esimerkiksi jos jokin versio selaimesta ei toimi yhdessä muun sovellusvalmistajan selainpohjaisen järjestelmän kanssa, täytyisi testaajan olla joku, joka käyttää kyseistä järjestelmää.

Onneksi jakeluprosessien määrittäminen automaattiseksi sähköposti-ilmoituksia myöten on helppoa CSM:ssä.

CSM:ään voit luoda vaikka jokaista sovellusta varten omat jakeluprosessit, mutta on myös mahdollista luoda jakeluprosessit riippuen siitä, jaetaanko sovellus kaikille työasemille vai onko sitä tarpeen päivittää vain koneille, joilta se jo löytyy. On yleistä, että sovellukset kuten Flash Player, Java ja Adobe Reader päivitetään kaikille työasemille, ja osasta sovelluksia annetaan mahdollisuus käyttäjille valita, haluaako tämä sen koneelleen.

Alapuolella on esitetty ruutukaappaukset kahdesta eri jakeluprosessista CSM for SCCM:stä. Ylemmässä on jakeluprosessi, jolla päivitetään jakeluprosessiin valitut sovellukset kaikille ja alempi jakeluprosessi on Firefox-selainta varten. Required-nimisessä jakeluprosessissa testiryhmänä on CSM – Test, joka voi koostua IT-henkilöstöstä ja tuotantojakeluryhmänä on CSM – Production, jossa on yrityksen kaikki työasemat. Tuotantojakelu käynnistyy viikon päästä, kun testijakelun asennuksen määräaika on tullut täyteen.

Firefoxin testijakelussa käytetään CSM – Mozilla Firefox Test -ryhmää, jonka jäseniksi on määritetty kaikki testilaitteet, josta löytyy jo Firefox. Tuotantojakeluryhmänä on CSM – Mozilla Firefox Production -niminen ryhmä, joka sisältää työasemat, joilta Firefox jo löytyy asennettuna. Nämä kaksi jakelua menevät samaan tapaan viikon välein kuin muiden sovellusten jakelu.

Jotta Firefox saadaan vielä niille käyttäjille, jotka sen haluavat, voimme määrittää viimeiseksi jakeluprosessin vaiheeksi available-tyyppisen jakelun kaikille käyttäjille. Kun käyttäjä asentaa sen kerran, niin kone lisätään automaattisesti tuotantojakeluryhmään SCCM:ssä, ja se päivittyy jatkossa automaattisesti työasemalle.

Mitä tästä opimme?

Sovelluspäivitysten jakeluprosessien pitäisi olla ennakkoon suunniteltuja jokaisessa IT-ympäristössä. Jakeluprosesseilla saadaan parempaa hallintaa työasemilla oleviin sovellusversioihin ja mahdolliset virheet voidaan havaita jo testivaiheessa, ilman että normaalien käyttäjien toiminta keskeytyy.

Tämän artikkelin vinkit antavat hyvän valmiuden uusien jakeluprosessien muodostamiseen tai nykyisten päivittämiseen, mutta oman IT-ympäristön mahdolliset erityistarpeet kannattaa aina huomioida.

Jakeluprosessien täysi hyöty tulee käyttöön, kun automatisoit sovellusjakelut Centero Software Managerilla!


Aapo Kettunen
IT-asiantuntija

Järjestelmäasiantuntija Aapo Kettusen tärkeimpiä työtehtäviä ovat Centero Software Manager -käyttöönotot, sovellusten paketointi ja testaaminen, Office 365 -ympäristöjen ylläpito sekä pääkäyttäjätuki. Aapon mukaan parasta työssä ovat asiakkaan kiperän ongelman ratkaiseminen ja asiakkaan työtä helpottavat kehitystoimenpiteet. Asiantuntija nauttii työssään haasteista, joiden ratkomisessa on mahdollista oppia jotakin uutta.

Tutustu Centero Software Manageriin »

Lisää luettavaa aiheesta:

Hannu Laitinen ja Timo Ruuska vahvistavat Centeron myyntiä

Centero moninkertaisti myyntinsä hevosvoimat kertalaakista. Joulukuun alusta Centeron remmiin astuneet Hannu Laitinen ja Timo Ruuska tuovat uutta näkemystä sekä kokemusta yrityksen myyntiin.

Uusi WSUS-tuote: Insider-preview

Windows Server Update Services (WSUS) -päivityspalvelua käyttäville organisaatioille on voinut tänään tulla yllätyksenä Windows Insider Pre-release Feature Update to Windows 10 version 1909 -nimisen päivityksen automaattinen hyväksyminen asennukseen. Microsoft on näet lisännyt uuden tuotteen Windows-pääkategorian alle. Mikäli tuo Windows-kategoria on ollut valittuna kaikkine alatuotteineen, myös Windows Insider Pre-Release -tuote on uutena tuotteena siirtynyt valituksi. Tästä johtuen […]