Perusasiat ovat kaiken perusta
Asiakkaan verkkopalvelu oli rakennettu käyttäen Sinatra- ja Sequel-ohjelmistokehyksiä ja kirjastoja.
Tavallaan. Todellisuudessa näitä oli käytetty hyvin vaillinaisesti.
Esimerkiksi Sinatra sisältää helpon ja suoraviivaisen tavan renderöidä näkymiä. Sequelissa puolestaan on työkalut tietomalleja varten ja tärkeitä ominaisuuksia datan hallintaa ja validointiin liittyen.
Verkkopalvelu ei käyttänyt mitään näistä. Sen sijaan alkuperäinen kehittäjä oli rakentanut omat toimintonsa. Sen jälkeen hän oli irtautunut projektista.
Ongelmana tässä oli se, että meillä oli käsissämme täysin epästandardi kehys, josta ei ollut mitään dokumentaatiota ja joka ei ollut yhteensopiva juuri minkään Sinatra- ja Sequel-projekteissa käytettyjen muiden työkalujen kanssa. Esimerkiksi FactoryBot-testityökalun käyttö oli mahdotonta. Erään dokumentin mukaan kokonaisuutta oli luonnehdittu helposti testattavaksi, mutta yhtäkään testiä ei ollut.
Kun valmiita ja hyväksi havaittuja työkaluja ja kirjastoja ei voinut käyttää, paloi aikaa ja rahaa siihen, että moneen asiaan piti keksiä oma räätälöity ratkaisu.
Ohjelmiston ongelmat eivät loppuneet tähän. Pääohjelmiston lisäksi kokonaisuuteen kuului eräänlainen prosessointiyksikkö, jonka lähdekoodi oli erillisessä repossa. Toisaalta pääohjelmistokin koostui kolmesta erillisestä sovelluksesta, joita ajettiin eri prosesseissa. Nämä oli kuitenkin sijoitettu yhteiseen repoon. Reitityksestä huolehti Nginx-konfiguraatio. Kokonaisuus ei ollut selkeästi monoliitti eikä (mikro)palveluarkkitehtuuri, vaan sekavasti jotain näiden väliltä.
Kehitysympäristö sijaitsi erillisellä palvelimella. Ilmeisesti tarkoitus oli putkittaa yhteys ssh-tunnelin läpi ja muokata tiedostoja suoraan palvelimen levyllä – verkkoviiveineen kaikkineen. En muistaakseni saanut tätä itse käyntiin lainkaan.
Aloitin vyyhdin purkamisen järjestelemällä pääsovelluksen rakenteen loogisemmaksi ja sellaiseksi, että sitä oli mahdollista kehittää paikallisessa ympäristössä. Siirsin eri osasten reitityksen Nginx:stä pääohjelmaan käyttäen apuna Rackin URLMap-toimintoa. Näin pääohjelmasta tuli selkeämmin yksi kokonainen sovellus.
Rakensin tavallaan ohjelman käynnistyksen uusiksi puhtaalta pöydältä ja lisäsin vanhaa toiminnallisuutta mukaan pala kerrallaan. Samalla dokumentoin tätä uutta ympäristöä Readme-tiedostoon.
Seuraavaksi liitin aiemmin mainitun prosessointiyksikön osaksi pääsovellusta. Tämä vaati onneksi vain vähän koodimuutoksia, sillä ydintoiminnallisuus oli pari Python-skriptiä, jotka pystyin kopioimana vanhasta reposta. Pääohjelmistoon lisäsin Sidekiq-prosessin, joka ajoi näitä skriptejä tausta-ajona.
Käyttöönottoalustan päivitin myös, ja siihen valitsin Dokkun – olin käyttänyt Dokkua omissa projekteissani jo jonkun aikaa, ja olin havainnut sen sekä helpoksi että luotettavaksi työkaluksi. Oleellista tässä on se, että sovelluksen päivitys tuotantoon (tai betaan) vaatii vain git push -komennon, ja automatiikka hoitaa lopun.
Testien kirjoittamista varten jouduin tekemään aluksi väliaikaisratkaisun, sillä Sequelin modelit saatiin käyttöön vasta paljon myöhemmin. Testien ajo oli kohtuullisen hidasta, mutta nyt sentään ylipäänsä mahdollista.
Testien ansiosta sovelluksesta löytyi paljon bugeja ja tietoturva-aukkoja, joita sitten korjasin.
Tämä projekti oli malliesimerkki siitä, miten suuri osa ongelmista poistuu ihan vain sillä, että laittaa perusasiat kuntoon.
Samaan tapaan kuin kunto- ja hyvinvointivalmentajatkin puhuvat perusasioiden puolesta: ei ole mitään ihmepilleriä, superruokaa tai yksittäistä lihaskuntoliikettä, joka tuosta vain kääntäisi retuperällä olevan elämäntavan yhtäkkisesti kuntoon. Perusasiat ovat loppujen lopuksi jokseenkin yksinkertaisia noudattaa, mutta huonoon tilaan ajauduttua niille tarvitsee antaa jonkin verran aikaa.