• Automation
• Automatic tests and code quality checks
• Environments
• Versions
• What now?

Imagine the following scenario: You are a student and have been asked to write either a brand new program or make changes to the code that already exists. So, how do you proceed? You start writing code, you compile and run it periodically to test that it runs and does what it should. You write some more code, and you run it again. The process goes on until you are satisfied and the code has to be delivered. After that, you package it nicely with some documentation, upload it to a page where it has to be delivered and wait for feedback. Sounds familiar?

The process is not so far away from what you might experience at a workplace – just in miniature form. You have someone who orders functionality – in this case, your teacher, but later a customer or product owner – and you have one or several deliveries to be shipped. From a functional perspective, you will want to be sure of three things: that the ordered functionality is implemented, that the new code does not mess up anything else, and that the code will behave the same way it does for you when the customer runs it on their machines or servers.

This simple “code-test-code” method works fine for small tasks, but what would you do if you were working on a large project with several colleagues, or even teams, working on different parts of the codebase? How can you check that your code still works when you have made your changes? How can you be sure that your changes have not messed up others’ code? And, how can you ensure that code that works on your machine still works when you deliver it to the customer?

Welcome to my workday. I often work with large IT systems consisting of hundreds of thousands lines of code and with dozens of developers working on different parts of the code. In addition to being a technical project manager with overall responsibility for the solution including application architecture, build infrastructure, and environments the solution runs on, I have often had the role of delivery manager. The latter is responsible for making sure that the final package that is being delivered contains all the code and functionality. Each delivery must have all the bits included, they must work correctly, and the recipients of the package will have to be able to install the software on their systems without any surprises.

Automation

A process to build, deploy and deliver a system consists of several steps, and most of them can usually be automated.

There are many reasons why you might want to automate this process. One reason is that it should be easier for you, and everyone else, to build the system. Automation shortens the time it takes to build it, making it easier to test a change you made to the codebase.

The second reason is that it makes it easier for others to take over or help on a project without having to familiarize themselves with the entire build process to get started. It will also make it easier to build with different build configurations. In addition to all this, it will also eliminate the human factor in the whole process – we humans make mistakes, and by automating the manual labor, we minimize the chance of making those errors.

Depending on the task at hand, the automation can be achieved by using various tools. Everything from simple make and shell scripts, to sophisticated build tools, like Apache Maven and Gradle, can help you reach your goals. Most often it will be not one, but a combination of the tools mentioned above. These can help you with both general automation of builds and deploy process, and automate the steps that will be described below.

Automatic tests and code quality checks

Once the code is written, and the build can be achieved with a single press of a button or by running a single script, you can begin to look at another important part of automation – running tests and managing code quality.

The automatic tests can be run both at low-level – unit tests, and at the functional level. Unit tests check that your methods are working properly, for example, that, given some specific input parameters, they return an expected answer. The functional tests on the other hand, will test the system as a whole, helping you to determine whether your system can still perform a set of specific tasks it was designed to do. There is also a third kind of tests that can, and should, be automated – integration tests. These are the tests used to check if the system is communicating with other systems in the way it was intended.

A failing test – no matter type – can tell you that something dramatic has happened in your system and that the system has ceased to behave as expected, giving you an opportunity to spot potential errors much earlier in the development process.

Another way to discover hidden problems is to run static code analysis that can detect known errors patterns, security weaknesses, bad coding habits, or unnecessary complexity. PMD, FindBugs and SonarQube can be mentioned as an example of tools for code quality management in Java world (while NDepend, StyleCop and SonarQube can be used for .NET projects).

Environments

When developing a system, one should know which environment and setup the system will run on when it goes live, i.e., when it gets deployed to a production environment. This information will help you to set up similar environments for development, and especially for testing. This is an important step in detecting errors that may occur only with a specific set-up or specific hardware. When these environments are set up, you can also automate the deployment of your code. This can be very convenient and save you a lot of time. Imagine, you push a change to a version control system (because you are using a VCS, right?), and it’s rolled out in a suitable environment – ready to be tested or demonstrated in no time, and with no effort from your side.

Versions

Versioning of the code and the applications will make sure you can simply answer two important questions:

• Which version of the code is running here?
• What functionality is part of the particular version of the application?

Both of these questions are something you are going to ask yourself and will be asked by others. The answers to these will help you when fixing or reporting bugs, or when working on a new functionality that is being rolled out.

If you are creating a larger system, you will also need this information when writing Release Notes for the latest version.

Versions will also help you keep track of and updating documentation for your system.

What now?

Automation of build and deploy is a complex topic. The points that I mentioned here can be used as a starting point – a kind of checklist for a better system. You do not need to do everything at once or go in depth on all points. You should rather start with one of them and work your way towards full automation.

These points – and a few more – are a part of a continuous delivery process that is designed to ensure that it will only take a few minutes between pushing a change to version control system till it is live in production. You do not need to go that far in the beginning, but it may be something to strive for.

These points may seem tedious, but they will often have an immediate effect on your development process – they will simplify the entire process of handling a system, so you can spend more time on what you like best, namely programming!

Jeg har skrevet en artikkel for studentmagasinet INDEX som utgis ved Institutt for Informatikk (Ifi), Universitetet i Oslo. Den ble publisert 30.04.2016, og er tilgjengelig for alle studenter på Ifi. Nå vil jeg også å dele den med alle dere andre som ikke kunne sikre dere en utgave av INDEX på fredag. Enjoy!

• Automatiser
• Automatiske tester og sjekk av kodekvalitet
• Miljøer
• Versjoner
• Veien videre

Tenk deg følgende scenario: Du er en student og har fått i oppgave om å skrive enten et helt nytt program, eller gjøre noen endringer i noe kode som finnes fra før av. Så, hvordan går du fram? Du begynner å skrive kode, du kompilerer og kjører den med jevne mellomrom for å teste at den fungerer og gjør det den skal. Du skriver mer, du kjører den igjen. Slik fortsetter du til du er fornøyd og koden skal leveres. Etter det pakker du koden din pent i en arkiv med litt dokumentasjon, laster den opp på en side hvor det skal leveres og venter på tilbakemelding. Høres det kjent ut?

Prosessen er vel ikke så langt unna det du vil oppleve i arbeidslivet, bare i miniatyrform. Du har noen som bestiller en type funksjonalitet – i dette tilfelle din lærer, men senere en kunde eller produkteier – og du har en eller flere leveranser som skal leveres til den som har bestilt jobben. Fra et funksjonelt perspektiv vil du være sikker på tre ting – at den bestilte funksjonaliteten er med, at den ikke ødelegger for noe annet og at koden vil oppføre seg på samme måte når bestilleren kjører det hos seg.

Den enkle «kode-teste-kode»-metoden fungerer fint for små oppgaver, men hva ville du gjort hvis du skulle jobbe på et stort prosjekt hvor flere jobber på forskjellige deler av koden? Hvordan kan du sjekke at koden din fortsatt fungerer når du har gjort dine endringer? Hvordan kan du være sikker på at dine endringer ikke har ødelagt andres kode?

Og, hvordan kan du sjekke at koden som fungerer på din maskin fortsatt fungerer når du leverer den fra deg?

Velkommen til min arbeidshverdag. Jeg jobber ofte med store datasystemer som består av mange hundre tusener kodelinjer og med flere titalls utviklere som jobber med forskjellige deler av den koden. I tillegg til å være teknisk prosjektleder med overordnet ansvar for blant annet applikasjonsarkitektur, bygg, og miljøer den kjører på, har jeg samtidig hatt rollen som leveranseansvarlig. Sistnevnte har ansvaret med å til slutt pakke all koden og levere den til kunden. Ved hver leveranse må man passe på at alle biter er med, at de fungerer som de skal og at mottakeren av pakken vil kunne installere det på sitt system uten noen overraskelser.

Automatiser

En prosess med å bygge, deploye og levere et system består ofte av flere steg og de kan som regel automatiseres. Det er mange årsaker til at man ønsker automatisering. Den ene årsaken er at det skal være enklere for deg og alle andre å bygge systemet – det korter ned tiden det tar å gjøre det, ergo å teste en endring du har gjort i koden. Den andre årsaken er at det kan gjøre det lettere for andre å ta over eller hjelpe til på et prosjekt uten å måtte sette seg inn i hele byggeprosessen. Det vil også gjøre det lettere å bygge med forskjellige konfigurasjoner dersom man ønsker det. I tillegg til alt dette, vil det også eliminere den menneskelige faktoren i hele prosessen. Vi mennesker kan gjøre feil, og ved å automatisere manuelt arbeid fjerner vi en kilde for en del feil.

Automatisering kan oppnås ved hjelp av forskjellige verktøy. Alt fra enkle make- og shell-skript til ganske avanserte byggeverktøy som Apache Maven og Gradle kan hjelpe deg, litt avhengig av oppgaven som skal gjøres. Oftest blir det en kombinasjon av noen ovennevnte verktøy. Disse kan hjelpe deg både med generell automatisering av bygge- og deploy-prosessen, og med automatisering av punktene under.

Automatiske tester og sjekk av kodekvalitet

Når koden din er skrevet og byggingen av den er et knappetrykk eller en skriptkjøring unna, kan du begynne å se på en annen viktig del av automatisering – kjøring av tester og sjekk av kodekvalitet. De automatiske testene kan være både på lavnivå – enhetstester – og på funksjonell nivå. Enhetstester sjekker at metodene dine fungerer som de skal, for eksempel å returnere riktig svar, gitt noen inputparametre. De funksjonelle testene vil teste systemet som en svart boks. Her vil du få svar om systemet ditt fortsatt kan utføre et sett med bestemte oppgaver. Det finnes også integrasjonstester som kan og bør automatiseres, og disse brukes for å sjekke at systemet snakker med og til andre systemer på den måten det var tiltenkt.

Uansett type tester kan disse, dersom de feiler, fortelle deg om at noe dramatisk har skjedd i ditt system og om at systemet har sluttet å oppføre seg som forventet. Det vil også gi deg en mulighet til å oppdage potensielle feil mye tidligere i utviklingsprosessen.

En annen måte å oppdage skjulte problemer er å kjøre statisk kodeanalyse som kan oppdage kjente mønstre for feil, sikkerhetssvakheter, uvaner eller unødvendig kompleksitet.

Miljøer

Når du utvikler et system bør du vite hvilket miljø og oppsett dette vil kjøre på når systemet går live, dvs. legges ut i produksjonsmiljøet. Denne informasjonen kan du bruke til å sette opp tilsvarende miljøer for utvikling, og spesielt med tanke på testing. Dette er nødvendig for å være i stand til å oppdage feil som vil kunne oppstå kun med et bestemt oppsett, eller spesifikk hardware. Når disse miljøene er satt opp kan du automatisere utrulling av din kode til disse miljøene. Dette kan være veldig praktisk, og spare deg for mye tid. Tenk at du sjekker inn en endring (for du bruker vel et versjonskontrollsystem, ikke sant?), og vips, er det ute på et passende miljø, klar til å testes eller demonstreres.

Versjoner

Versjonering av koden vil gjøre at du lett kan svare på to viktige spørsmål:

• Hvilken versjon av koden kjører her?
• Hvilken funksjonalitet er en del av bestemt versjon?

Begge disse spørsmålene er noe du kommer til å spørre deg selv og vil bli spurt om fra andre. Svarene på disse vil hjelpe deg når du skal jobbe med feil som blir fikset eller oppdaget, eller ny funksjonalitet som blir rullet ut. Dersom du lager et større produkt, vil du også få bruk for disse når du skal lage Release Notes for den nyeste versjonen. Versjoner vil også hjelpe deg å holde styr på en oppdatert dokumentasjon for ditt system.

Veien videre

Automatisering av bygg og deploy er et veldig stort tema. Punktene som jeg nevner her kan brukes som et springbrett, en slags sjekkliste for et bedre system. Du trenger ikke gjøre alt på en gang, eller gå i dybden på alle punkter, men start et sted og jobb deg videre mot full automatisering.

Disse punktene – og litt mer – er en del av en kontinuerlig leveranseprosess som skal bidra til at det kun vil ta noen minutter fra du sjekker inn en endring til det er ute i produksjon. Så langt trenger du ikke å gå i første omgang, men det kan jo være noe å strekke seg etter? Men det disse punktene kan gjøre med en gang er å forenkle din hverdag så vel som hele prosessen rundt håndtering av et system, slik at du kan bruke mer tid på det du liker best, nemlig programmering!

Denne artikkelen ble publisert i magasinet INDEX (2. utgave, 2016), Institutt for Informatikk, Universitetet i Oslo.