Devauskäytännöt kuntoon

Liityin taannoin mukaan erääseen devaustiimiin, joka teki Djangolla kirjoitetua webbisoftaa. Projekti oli kasvanut tutkimusprojektista kohti kaupallista tuotetta. Vauhti oli ilmeisesti ollut parina edellisenä vuotena kova, koska koodi oli kerännyt paljon teknistä velkaa.

Otin tehtäväkseni suoria tiimin devauskäytännöt ja koodin kuntoon. Paikkausta vaativia osa-alueita oli useampi.

Sovellus ja palveluinstanssi samassa kasassa

Koodin muutoksia hallinnoitiin tyypilliseen tapaan Git-versionhallinnan avulla. Alunperin verkkopalvelusta oli ollut ajossa vain yksi instanssi, mutta ajan myötä oli tullut tarvetta useammalle. Niiden konfiguraatiot erosivat hieman toisistaan, joten ilman pieniä muokkauksia sovelluskoodiin ei pärjännyt.

Ongelma oli tullut siitä, että kahden eri instanssin konfiguraatiot eivät tallentuneet sulassa sovussa versionhallintaan. Siksi varsinaisten konffirivien seassa oli kommentoituja rivejä eri instansseja varten.

Tuotannossa olevan softan päivittäminen oli kuulemma yhtä helvettiä, ja vaati vähintään muutaman tunnin aikaa.

Oli varsin selvää, että tilannetta pystyi parantamaan muutamalla peruskorjauksella.

Tutkittua koodia huomasin, että sieltä oli havaittavissa kolme erilaista kokonaisuutta. Nämä erottelin kolmeksi eri Django-projektiksi: sovelluksen perustoiminnan ja backendin tarjoava ydinpaketti, käyttöliittymä ja lisänäkymät, jotka olivat käytössä vain yhdessä tietyssä instanssissa. Lisäksi loin jokaiselle instanssille oman Django-projektin ja Git-repon, jotka asettivat omien tarpeidensa mukaan riippuvuudet edellä mainittuihin paketteihin. Tällä tavoin saatiin eristettyä sovelluskoodi ja instanssikohtaiset asetukset toisistaan.

Yhtenäinen devausympäristö Vagrantilla

Tiimi käytti Windows-työasemia, mutta webbidevauksessa tarvittavat ohjelmistot ovat tyypillisimmin käytössä Linux-maailmassa. Window-porttauksia on kyllä olemassa, mutta välillä nissä on pientä purkkavirityksen makua. Lisäksi firmalla ei ollut oikein minkäänlaista dokumentaatiota siitä, mitä kaikkea devausympäristöön pitäisi asentaa.

Otin avuksi Vagrantin ja loin sen avulla selkeän ja eristetyn devausympäristön projekteille. Tuo eristys kaikesta muusta oli hyvä, koska tiimin jäsenet työskentelivät välillä 2-3 eri projektin parissa. Toisistaan itsenäiset virtuaalikäyttöjärjestelmät toivat näin ollen myös vikasietoisuutta.

Automaattitestaus

Pystytin Jenkinsin monitoroimaan Git-repoihin pushattuja muutoksia ja ajamaan automaattisesti projektin testit ja lintterin. Kyse ei varsinaisesti ollut täysmuotoisesta jatkuvasta integraatiosta, koska useat muutokset kulkivat koodihaarojen kautta. Joka tapauksessa Jenkinsin kautta näki kätevästi yhdellä silmäyksellä eri koodihaarojen tilan.

Tarpeen mukaan jenkinsin pipelinet olivat joko yksinkertaisia tai multibranch-tyyppisiä.

Paketointi ja Pypi-palvelin

Perustin firman palvelimille sisäisen Pypi-palvelun, jonka toteutin Simplepypi-sovelluksella. Tämä pakettivarasto huolehti sisäisten sovellusten jakelusta. Aikaisemmin oli tarve kopioda ja säätää tarvittavat riippuvuuden käsin paikalleen, mutta uuden käytännön asioista riitti, kun lisäsi riippuvuuspakettien nimet requirements.txt-tiedostoon ja ajoi komennon pip install -r requirements.txt.