Version control of an old database system

This thesis describes a database-centric legacy system. The system wasn’t originally under version control at all and while version control was introduced later, it was backup-minded in nature. Business logic of the systesm was largely coded in database procedures, functions and triggers. Deployments of the system were done by copying previously deployed databases and over time the system’s version history was blurred or entirely forgotten. Problems caused by this are identified and their harmfulness is described. The problems are significant and cause harm different ways depending on the point of view. Programmers find that their work becomes more difficult and less appealing when they are wasting time figuring out the state of different environments, end up doing extra work because of forgotten features and the state of the software code in general deteriorates. Project management will find specification and planning more difficult for the same reasons and businesswise all wasted time ends up costing money. After identifying the problems solutions are looked from the software engineering theory. Cases where similar problems have been solved are especially looked for. It can be said, that much less is written about version controlling databases than on version control in general. The biggest challenge when version controlling databases is extracting the business logic from the database into version controllable scripts. The key part in various solutions is using tools to make this part easier. Methods that would make database version control as easy as version control in general cannot be found, though. Next a set of actions is introduced to improve the state of the described system. The actions aim at helping to avoid overlapping work, make the version history more clear and improve level of the software code in general. Workload of the actions is estimated using the planning poker method and the most cost effective ones are selected to be implemented. Implementation and effectiveness of these actions are evaluated. Some of the actions were implemented differently than planned, some weren’t implemented at all and some non-planned actions were implemented. It could be acknowledged that overlapping development work could be prevented and version history became clearer, but maintaining the process created more workload overhead. Next changes to this process and organization in general are suggested. Finally, it is pointed out that not too much time should be spent fixing a legacy system and the root cause of problems can be avoided altogether by allocating more resources to the development.Työssä esitellään tietokantaa normaalia enemmän hyödyntävä legacy-järjestelmä. Järjestelmää kehittäessä ei ole käytetty versiohallintaa ollenkaan, ja myöhemminkin vain varmuuskopionäkökulmasta. Järjestelmän ohjelmistologiikka on suurelta osin toteutettu tietokantojen proseduureissa, funktioissa ja liipaisimissa. Järjestelmästä on tehty julkaisuja asiakastoimituksia varten kopioimalla vanhoja toimituksia varten tehtyjä julkaisuja ja ajan kuluessa järjestelmän versiohistoria on hämärtynyt tai unohtunut kokonaan. Työssä pyritään tunnistamaan tästä aiheutuvia ongelmia ja perustelemaan, miksi ne ovat haitallisia. Ongelmat ovat merkittäviä ja aiheuttavat haittaa eri tavalla näkökulmasta riippuen. Ohjelmistokehittäjien työ vaikeutuu ja muuttuu epämiellyttävämmäksi, kun eri versioiden tilan selvittämiseen täytyy käyttää aikaa. Jo tehdyn kehitystyön unohtuminen aiheuttaa päällekkäisen työn tekemistä ja ylipäätään järjestelmän ohjelmistotekninen laatu laskee. Projektinjohtonäkökulmasta työn määrittely ja suunnittelu vaikeutuvat samoista syistä, sekä liiketoimintanäkökulmasta kaikkeen päällekkäiseen ja ylimääräiseen työhön kuluva aika maksaa rahaa. Ongelmien tunnistamisen jälkeen etsitään ratkaisukeinoja ohjelmistotieteen kirjallisuudesta. Erityisesti paneudutaan tapauksiin, joissa on ratkaistu vastaavia ongelmia. Voidaan todeta, että aiheesta on kirjoitettu vähän verrattuna versiohallintaan yleisesti. Suurin haaste tietokantojen versiohallinnoinnissa on ohjelmistologiikan muuttaminen versiohallintaa tukeviksi tiedostoiksi. Ratkaisujen oleellisin osuus onkin työkalujen käyttö tämän vaiheen helpottamiseksi. Keinoja, jotka tekisivät tietokantojen versionhallinnoinnista yhtä helppoa kuin tyypillisen ohjelmistokoodin versiohallinnoinnista ei löytynyt. Seuraavaksi esitellään joukko toimenpiteitä esitellyn järjestelmän tilan parantamiseksi. Toimenpiteet keskittyvät päällekkäisen työn välttämiseen, versiohistorian selventämiseen ja ohjelmistokoodin tason parantamiseen. Toimenpiteiden työmäärä arvioidaan planning poker -menetelmällä ja niistä valitaan toteutettavaksi kustannustehokkaimmat. Toimenpiteiden toteutuksen jälkeen niiden toteutusta ja tehoa arvioidaan. Osa niistä toteutettiin eri tavalla kuin oli suunniteltu, joitain jäi toteuttamatta ja lisäksi tehtiin joitain suunnittelemattomia toimenpiteitä. Voidaan todeta, että päällekkäisen kehitystyön tekeminen ja versiohistorian hämärtyminen saatiin estettyä, mutta itse prosessin ylläpitämisestä tuli työläämpää. Jatkoehdotuksissa ehdotetaan korjauksia tähän prosessiin ja organisaatioon yleensä. Lopuksi todetaan, että vanhaa järjestelmää ei kannata korjata liian työläästi ja ongelmiin päätyminen voidaan alkujaan välttää poistamalla juurisyynä toiminut resurssipula