Miten siirtyä IBM Rational Synergystä Gitiin

IBM Rational Synergyn historia

IBM Rational Synergy on asiakas-palvelinarkkitehtuuriin perustuva versionhallintajärjestelmä, joka on kehittynyt 1990-luvun yksittäisten tiedostojen versionhallintajärjestelmästä tehtävienhallintajärjestelmäksi. Sen päällä toimii Change-niminen muutostenhallintajärjestelmä. Järjestelmällä on ollut vuosien varrella eri nimiä (Continuus, CM/Synergy ja viimeisimpänä Rational® Synergy), ja se on kuulunut eri yrityksille ennen päätymistään IBM®:lle Rational®-brändin alle.

2000-luvulla sillä oli muutamia vahvuuksia, jotka lisäsivät sen suosiota markkinoilla. Ensinnäkin se on tehtäväpohjainen konfiguraationhallintajärjestelmä, mikä on edistysaskel CVS:n kaltaisiin järjestelmiin verrattuna. Synergyssä voit määrittää kehittäjille tehtäviä, joissa muutetaan ja lisätään tiedostoversioita ja jotka lopuksi saatetaan valmiiksi tiettyä julkaisua varten.

Toiseksi siinä on repositorioiden käsite, joka sopii hyvin suurille organisaatioille, joissa useat tiimit toimittavat komponentteja tuotelinjoille.

Kolmanneksi sitä voitiin laajentaa Rational Changella ohjelmistomuutosten hallintaprosessien, mukautettujen hierarkioiden, ominaisuuksien ja elinkaarien toteuttamiseksi.

IBM Rational Synergy lähestyy elinkaarensa loppua

Työkalua ylläpidetään, mutta siihen ei ole tehty toiminnallisuuspäivityksiä vuosiin, joten se lähestyy elinkaarensa loppua. Jo tämän kriittisen syyn vuoksi siirtymisen uuteen järjestelmään, kuten Gitiin, pitäisi olla nopeasti IT:n asialistalla.

Lisäksi järjestelmä on hidas käyttää, yksinkertaisten yhdistämisten tekeminen vaatii paljon manuaalista työtä, se on suunniteltu pitkäikäisille julkaisuhaaroille ja sitä on vaikea ymmärtää. Kaikki tämä voi heikentää kehitystiimien tehokkuutta.

Kokemukseni mukaan tiimeille ja organisaatioille kehittyy "älä koske siihen" -ajattelutapa. Tämä tarkoittaa, etteivät ne edes kehitä tai optimoi Synergyn käyttöään tiimien tarpeita vastaavaksi. Kaikki vain elävät sen kanssa ja kiertävät sen rajoitteita. Jo tämä kertoo, että on aika siirtyä eteenpäin.

Suuri kysymys kuuluu: voidaanko se tehdä? Lyhyt vastaus on: "todennäköisesti kyllä". Se riippuu pitkälti siitä, miten Synergyä on käytetty vuosien varrella.

Migraation suunnittelu

Synergyn ja Gitin tietomallien yhteensovittaminen

Synergyssä ohjelmistomuutosten muodostama revisio perustuu hyvin väljästi määriteltyyn malliin. Tämä aiheuttaa haasteita Synergystä Gitiin siirtymisessä. Tietomallit ovat täysin erilaiset. Tässä ovat merkittävimmät erot.

Yhteenveto käsitteiden vastaavuuksista

Migraatiokokemustemme pohjalta olemme kehittäneet migraatiostrategian, joka on tiivistetty alla olevaan taulukkoon. Siinä esitetään ensin nopea arvio ja sen jälkeen yksityiskohtaiset perustelut.

Synergy

Git

Tiedostot ja historia

Ei suoraan

Tehtävät

Ei suoraan

Baselinet

Ei suoraan

Julkaisut

Ei

Projektit ja revisiot

Repositorio, commitit ja tagit

Aliprojektit

Alimoduulit

Mukautetut attribuutit

Ei

Tiedostot ja niiden historia – ei migroida suoraan

Synergyn tiedostoilla on oma revisiohistoriansa, ja niiden migrointi voi olla kiinnostavaa, mutta Gitissä tiedostorevisioita ei ole erillisinä revisioina.

Synergyn tiedosto-objekteilla on tyypit, joiden perusteella tiedostoilla voi olla erilaiset rivinvaihdot sekä katselu- ja yhdistämiskäytännöt. Tämä voidaan toteuttaa suurelta osin .gitattributes-tiedostossa. Erityisesti on kuitenkin käsiteltävä suoritusoikeusbitit, sillä Git ei aseta niitä automaattisesti.

Huomioi tuotavan lähdekoodin nykyiset .gitignore- ja .gitattributes-tiedostot, sillä ne voivat aiheuttaa tahatonta toimintaa, jos ne ovat mukana migraation aikana. Yhdistämiset tehdään tiedosto-objektitasolla.

Tehtävät – ei migroida suoraan

Tehtävät olisivat ihanteellinen migroitava objekti, sillä ne ovat yksittäisiä muutoksia Gitin patch-tiedoston tapaan. Niillä ei siis ole parent-suhdetta. Niitä ei migroida, mutta ne listataan commit-viesteissä ja annotuissa tageissa.

Baselinet – ei migroida suoraan

Baselineja, joita kutsutaan myös baseline-objekteiksi, ei voi migroida sellaisenaan, koska ne ovat vain metatietosäiliöitä ja linkkejä projektirevisioihin, tehtäviin ja Change Objecteihin. Gitissä lähimpänä vastaavaa ovat annotetut tagit, joihin baseline-tiedot lisätään annotaationa. Baselinet ovat verrattain uusi käsite, ja ne tulivat pakollisiksi vasta versiossa 7.x, joten ne eivät ole luotettava migraatiolähde.

Releaset – ei migroida

Releaset muistuttavat jossain määrin brancheja, mutta niitä käytetään yleensä pitkäikäisinä release brancheina. Ne näkyvät vain annotetun tagin nimessä.

Projektit ja projekti­revisiot – migroidaan

Staattisessa tilassa olevat projektit ja projekti­revisiot vastaavat lähimmin Gitin committia. Projekti­revisioiden staattiset tilat ovat: integrate, test, sqa ja released. Kyseessä on toistettavissa oleva revisio, joka perustuu aiempaan revisioon eli project baselineen. Projekti­revisiot ovat paras migraatio-objekti, sillä ne sisältävät lähdekoodin revision ja siihen liittyvän historian.

Synergy-projekti tulisi oletusarvoisesti yhdistää Git-repositorioon. Revision nimi on yleensä sama kuin release, build-numero tai tunniste, jonka ohjelmisto-organisaatio voi tunnistaa myöhemmin. Revision nimet tai tunnisteet yhdistetään Git-tageihin. Migraation jälkeen löydät vastaavan ohjelmistorevision Gitistä samalla nimellä kuin Synergystä.

Projektien nimillä ja revisioilla on huomattavasti vähemmän rajoituksia kuin Git-repositorion ja tagien nimillä. Tämä tarkoittaa, että välilyönnit ja erikoiset merkit on todennäköisesti korvattava väliviivoilla tai alaviivoilla, ja projektinimet on todennäköisesti myös yhdenmukaistettava pieniksi kirjaimiksi.

Synergyssä useilla projekteilla voi olla sama nimi, mikä erotellaan instance-attribuutilla. Migraatiotavan tulisi määräytyä sen perusteella, miksi päällekkäisiä projektinimiä on olemassa. Kyseessä voi olla eri projekti repositoriohallinnassa, tai kaikkien instanssien historia voi kuulua samaan kohde-Git-repositorioon.

Projekti­revisioiden tasolla ei ole yhdistämisen käsitettä, sillä projekti­revisiolla voi olla vain yksi parent.

Jos projekti­revisiot eivät vastaa revisioita, buildeja tai releaseja tai niitä ei ole lainkaan, estääkö se migraation?

Ei välttämättä. Ohjelmisto-organisaatioilla on yleensä release notes -dokumentaatio tai bill of materials. Niissä ilmoitetaan baseline-revisio, aliprojektien revisiot ja tehtäväluettelot. Tällöin revisio voidaan toistaa ja migroida Gitihin.

Aliprojektit – migroidaan

Ne voidaan yhdistää suoraan Gitin almoduuleihin, sillä tietomalli on sama. Projektiin voidaan lisätä toinen projekti aliprojektiksi tietyssä revisiossa. Tämä luo työtilaan hakemiston. Gitissä toimintatapa on sama.

Mukautetut attribuutit – ei migroida

Niitä voidaan luoda mille tahansa Synergy-tietokannan objektille. Ne antavat kehitysprosessille erityisen merkityksen, jota voi olla vaikea toteuttaa uudelleen Gitissä. Tämä ei niinkään liity itse migraatioon, vaan siihen, miten kehitysprosessi mukautetaan Gitissä työskentelyyn.

Edellä kuvatun perusteella voidaan todeta, että vaikka Synergystä Gitiin ei ole yksi yhteen -vastaavuutta, voimme tehdä järkeviä valintoja, joiden avulla migraatio onnistuu.

Miten migraatio tehdään

Koska projektit ja niiden revisiot ovat migraation yksiköitä, tarkastellaan migraation toteutusta hieman tarkemmin.

Projektit

Ensin sinun on selvitettävä, mitkä projektit ja mistä tietokannoista haluat migroida. Saatat jo tietää, mitä haluat migroida, mutta suosittelen hakemaan projektit tietokannoista, jotta yksikään ei jää huomaamatta.

Tietokannat saattavat olla vanhempia kuin tiimeissä tällä hetkellä työskentelevät ihmiset. Projektit on arvioitava, jotta voidaan päättää, mitkä migroidaan ja mitkä voidaan jättää pois. Joissakin projekteissa on aliprojekteja, ja sinun on päätettävä, miten ne migroidaan. Ne tulisi joko säilyttää almoduuleina tai siirtää alihakemistoiksi.

Tiedostorevisioiden vaikutus

Työskentely client-server-SCM-järjestelmässä on yleensä luonut käytäntöjä artefaktien, riippuvuuksien ja työkalujen tallentamiseen lähdekoodiin. Tämä ei sovi hyvin yhteen Gitin kaltaisen hajautetun versionhallintajärjestelmän kanssa, sillä oletuksena mukana kulkee koko commit- ja tiedostohistoria.

Repositorion koko sekä koon kasvu revisiota kohden antavat ensimmäisen viitteen siitä, onko repositorio pitkällä aikavälillä kestävä. Korjaavat toimet voivat vaihdella tiedostojen poistamisesta artefaktienhallintaan siirtämiseen, Git Large Files Systemin (LFS) tai almoduulien käyttöön. Etukäteen on vaikea sanoa, mikä ratkaisu on paras millekin tiedostolle tai alueelle. Organisaation tulee päättää arvioinnista ja tarvittavista toimista.

Metadata – tiedostot, tehtävät ja baselinet

Kuten edellä mainittiin, tiedostoja, tehtäviä ja baselineja ei voida sellaisenaan migroida Gitiin, mutta ne sisältävät paljon olennaista tietoa. Baseline-objekti sisältää nämä tiedot, ja ne voidaan lisätä annotated tagiin commit-viestin yhteyteen. Tämä on hyödyllistä, sillä tiedot ovat haettavissa Gitissä ja Git-repositorioiden hallintatyökalut voivat myös jäsentää ne. Näin saat jäljitettävyyssillan Synergystä Gitiin. Voit migroida Synergy-tehtävät ja Rational Change -ongelmat tehtävienhallintatyökaluusi. Tehtävät voivat sisältää tietoa vastuuhenkilöstä, releasesta, kuvauksen ja tiedostoluetteloita.

Yleensä repositorioiden hallintatyökaluissa ja tehtävienhallintajärjestelmissä on integraatioita, joiden avulla tehtäviin voi viitata commit-viesteissä. Tällä tavalla voidaan yhdistää migroidut projektirevisiot ja tehtävienhallintajärjestelmän tehtävät. Se tarjoaa erinomaisen jäljitettävyyden historiallisiin revisioihin. Olen aiemmin tehnyt migraation, jonka kohteina olivat BitBucket ja Jira. Synergy-tehtävät migroitiin Jiraan storyina yhdessä FixVersionsien ja komponenttien kanssa.

Iterointi ja varmistus

Vuosien kokemus kertoo, että migraatiomekanismia on säädettävä muutaman kerran, jotta se toimii oikein. Kyse on iteratiivisesta prosessista. On tehtävä päätöksiä, jotka liittyvät prosesseihin ja rakenteeseen. Todennäköisesti vaihdat auton moottoria sen ollessa liikkeessä, joten migraatiota kannattaa harjoitella useita kertoja.

Migraatio on varmistettava sekä teknisestä että prosessin näkökulmasta

Teknisesti voit verrata Synergystä otetun revision tiedostoja ja rakenteita Gitistä otettuun tagiin. Voimmeko buildata ja varmistaa ohjelmiston? Voitteko luoda dokumentaation sekä tuottaa artefaktit ja releaset?

Prosessin näkökulmasta on käytävä läpi koko kehitys- ja toimituselinkaari Gitissä, jotta voidaan varmistaa, että työskentely Git-pohjalta onnistuu.

Migraation toteuttaminen

Edellisissä osioissa nostin esiin eri tietomalleista johtuvia haasteita ja mahdollisia ratkaisuja. Monet näistä elementeistä on toteutettu avoimen lähdekoodin 2git-työkalussamme, jota on käytetty ClearCase- ja Synergy-migraatioissa.

Migraatiossa on kaksi päävaihetta. Ensimmäisessä lähdekoodi siirretään Synergystä Gitiin ilman muutoksia ja optimointeja. Toisessa Git-repositorio optimoidaan ja siihen lisätään riippuvuudet.

Synergystä Gitiin:

1. Aja 2git ccm2git-driverilla. Tuloksena on Git-historia, jota ei ole optimoitu ja jossa ei ole almoduuleja.

2. Synergystä ja Gitistä otetun saman revision tiedosto- ja rakennevertailu

3. Rakenna ohjelmisto Gitistä

4. Arvioi tulos

5. Tee repositorioanalyysi tunnistaaksesi vaiheessa 2 poistettavat tiedostot ja LFS-konfiguraation. Yksi vaihtoehto on käyttää git-repo-analyseria Git-repositorioon eniten vaikuttavien tiedostojen tunnistamiseen.

Toista nämä vaiheet, kunnes olet tyytyväinen migraatioon.

Gitin optimointi:

1. Päivitä vaiheessa 1 tehdyn repositorioanalyysin perusteella .gitignore ja .gitattributes

2. Lisää riippuvuudet artefaktienhallintajärjestelmään

3. Aja 2git git2git-with-ccm-flavourilla. Tuloksena on Git-historia, joka on optimoitu submoduleja hyödyntäen.

4. Synergystä ja Gitistä otetun saman revision tiedosto- ja rakennevertailu

5. Lisää Gitistä puuttuvat riippuvuudet ja työkalut

6. Päivitä 2git-työkalu päätöstesi perusteella hakemaan riippuvuudet ja työkalut

7. Rakenna ohjelmisto Gitistä

8. Arvioi tulos

Toista yllä olevat vaiheet, kunnes olet tyytyväinen

Käyttöönotto

Delta- ja osittaiset migraatiot

Suurissa organisaatioissa tiimin jäsenten kouluttaminen Gitin ja uusien prosessien käyttöön voi olla haastavaa. Tällöin osittaiset migraatiot voivat olla hyödyllisiä. Ne voidaan toteuttaa joko projektitasolla tai Synergy-julkaisuihin perustuen.

2git pystyy käsittelemään delta-migraatioita ja siirtämään Gitiin vain puuttuvat projektirevisiot, mikä tekee siitä joustavan ja vähentää kertarysäyksen riskiä. Suosittelen aloittamaan ylimmän tason projekteista. Ensinnäkin niistä ei ole riippuvaisia muita Synergy-projekteja, ja toiseksi voit varmistaa jo varhaisessa vaiheessa, että pystyt tuottamaan tuotejulkaisuja uuden työkaluketjun avulla. Tämä pienentää ohjelmistoprojektien riskiä. Alijärjestelmät voivat edelleen julkaista Synergyssä, ja Git-tagi tai -commit on käytettävissä integraatiota varten seuraavan 2git-ajon jälkeen.

Määritä haarautumisstrategia

Kuten aiemmin mainittiin, Synergy ja Git eroavat toisistaan julkaisujen ja haarojen osalta. Molemmissa kehittäjä toimittaa muutokset julkaisuun tai haaraan, mutta Synergyssä ei ole oletushaaraa eikä trunk-based development -mallin käsitettä. Olet ehkä hallinnut tämän itse Synergyssä, mikä on hienoa, ja voit hyödyntää Gitin toimintatapaa heti määrittämällä saman haaran oletushaaraksi.

Git-haarojen hallintaan on monia lähestymistapoja, ja sopivaa toimintatapaa on vaikea suositella ilman syvällistä ymmärrystä nykyisistä työtavoistasi ja rajoitteistasi.

Suosittelen tutkimaan Gitiin siirrettyä historiaa, jotta saat hyvän käsityksen siitä, miten ohjelmistoresurssisi ovat kehittyneet ajan myötä. Näet havainnollisesti, miten projektirevisiot ja niiden baselinet ovat kehittyneet ajan kuluessa ja missä kohdin historiassa on haarautumia.

Jokainen haarautuma tarkoittaa haaraa, mutta olet kiinnostunut vain mahdollisesti aktiivisista haaroista, joihin tehdään committeja lähitulevaisuudessa. Voit aina luoda lisää haaroja tarpeen mukaan.

Jatkotoimet

Olet nyt siirtynyt Gitiin ja hyödyt sen eduista, mutta tapojen muuttaminen voi olla vaikeaa.

Esimerkiksi organisaatiot jatkavat usein kehitystä release-haaroissa. Gitissä ominaisuuksia voi kuitenkin kehittää master-haarassa ja luoda release-haarat vasta, kun niitä tarvitaan kypsyttämistä varten. Siirtyminen varhaisesta haarautumisesta myöhäiseen haarautumiseen vaatii aktiivista työtä, jotta vähemmän eriytyneestä koodikannasta saadaan hyödyt irti.

Yhdistäminen on Synergyssä kallista, minkä vuoksi release-haaroja yhdistetään harvoin takaisin päälinjaan. Muutoksia ei välttämättä yhdistetä lainkaan, vaan kehittäjiä pyydetään toteuttamaan samat muutokset uudelleen useissa haaroissa.

Voit nyt luoda haarautumisstrategian, joka mahdollistaa tämän automatisoidusti. Git tekee yhdistämiset sekä nopeasti että luotettavasti. Sen voi toteuttaa jopa Continuous Integration -alustallasi. Suosittelen Git Phlow'ta, sillä se on suunniteltu niin, että muutokset tarvitsee toteuttaa vain kerran ja automaatio vie ne päälinjaan yksinkertaisten yhdistämisten kautta.

Yhteenveto

Synergy-migraatio tuntuu usein pelottavalta sen laajuuden ja siihen liittyvien legacy-työkalujen vuoksi, mutta se on täysin mahdollista oikealla osaamisella ja taidoilla. Kokemuksesta on myös apua. Olemme auttaneet tässä suuria kansainvälisiä organisaatioita.

Voimme myös hallinnoida GitLabiasi Eficode ROOT managed service -palvelumme kautta.