• Intro
• 1. Before you begin
• 2. Create a Cloud Function
• 3. Deploy the Cloud Function

Intro

Recently we decided to migrate our builds from Travis CI to Google Cloud Build to speed up the builds. The process was quite easy and flawless; however, we were still missing a few minor things. One of them was the notifications from Cloud Build to our #ops channel in Slack. This was slightly annoying because you would not know if the build was finished and the site was deployed, or if it failed for some reason.

Integrating with Cloud Build was a bit more different than what you are used to from integrations with Jenkins or Travis CI. Normally you would just create a webhook that would call an interface in the Slack API. In Cloud Build, on the other hand, everything is getting posted to the Pub/Sub queue built into the platform, and here you would just need to subscribe to the specific queue and listen for the events. To achieve the latter, you would need a small serverless function to listen for these events and to call the Slack API.

Note that here we will, technically, be using paid services on Google Cloud Platform, as both Cloud Build, Cloud Pub/Sub, and Cloud Functions are billable components. However, since all the components above provide a generous free tier, you will need to work hard to get passed the free tier with this setup.

• Cloud Build: Free first 120 builds-minutes per day for Basic machine type (n1-standard-1).
• Cloud Pub/Sub: Free first 10GB per month (pricing).
• Cloud Functions: Free first 2 million invocations per month (pricing).

1. Before you begin

1.1 Prepare your GCP project

I assume you have a Google Cloud Account, and that you have signed in to your account.

1. Select or create a Google Cloud Platform project, e.g. from the Manage resources page.
2. Make sure that billing is enabled for your Google Cloud Platform project.
3. Enable the Cloud Functions and Cloud Pub/Sub. You can also enable the APIs using this link.
4. Use Cloud Shell right from the browser, or you can Install and initialize the Cloud SDK on your own machine.
5. If you have installed the Cloud SDK, update and install gcloud components:

gcloud components update &&
gcloud components install alpha beta

1.2 Prepare your Slack App

I assume you have Slack installed and that you have created and signed-in to your account.

Create a new Slack app:

1. Choose the app’s name and your Slack team. Click Create.
2. Click Incoming Webhooks.
3. Activate incoming webhooks.
4. Click Add New Webhook to Workspace. An authorization page opens.
5. From the drop-down menu, select the channel to which you would like notifications sent.
6. Click Authorize.
7. A webhook for your Slack application has been created. Copy the webhook URL and save it for later use.

2. Create a Cloud Function

We need to create a Cloud Storage bucket to stage your Cloud Functions files. Use [STAGING_BUCKET_NAME] that is a globally-unique bucket name (such as [PROJECT-ID]_cloudbuilds):

gsutil mb gs://[STAGING_BUCKET_NAME]

You should see the following output:

Creating gs://[PROJECT-ID]_cloudbuilds/[STAGING_BUCKET_NAME]...

Next, create a directory on your local system for the application code:

mkdir ~/gcb_slack
cd ~/gcb_slack

Then, create the following two files in the gcb_slack directory.

File 1: package.json

{
  "name": "google-container-slack",
  "version": "0.0.1",
  "description": "Slack integration for Google Cloud Build, using Google Cloud Functions",
  "main": "index.js",
  "dependencies": {
    "@slack/client": "4.10.0"
  }
}

File 2: index.js

Note: Make sure to update SLACK_WEBHOOK_URL in the code below.

const IncomingWebhook = require('@slack/client').IncomingWebhook;
const SLACK_WEBHOOK_URL = "<INSERT YOUR WEBHOOK FROM STEP 1.2>"

const webhook = new IncomingWebhook(SLACK_WEBHOOK_URL);

// subscribe is the main function called by Cloud Functions.
module.exports.subscribe = (event, callback) => {
 const build = eventToBuild(event.data.data);

  // Skip if the current status is not in the status list.
  // Add additional statues to list if you'd like:
  // QUEUED, WORKING, SUCCESS, FAILURE,
  // INTERNAL_ERROR, TIMEOUT, CANCELLED
  const status = ['SUCCESS', 'FAILURE', 'INTERNAL_ERROR', 'TIMEOUT'];
  if (status.indexOf(build.status) === -1) {
    return callback();
  }

  // Send message to Slack.
  const message = createSlackMessage(build);
  webhook.send(message, callback);
};

// eventToBuild transforms pubsub event message to a build object.
const eventToBuild = (data) => {
  return JSON.parse(new Buffer(data, 'base64').toString());
}

// createSlackMessage create a message from a build object.
const createSlackMessage = (build) => {
  let message = {
   text: `Build \`${build.id}\``,
    mrkdwn: true,
    attachments: [
      {
        title: 'Build logs - Your Custom Message Goes Here',
        title_link: build.logUrl,
        fields: [{
          title: 'Status',
          value: build.status
        }]
      }
    ]
  };
  return message
}

3. Deploy the Cloud Function

To deploy the subscribe function with a Cloud Pub/Sub trigger, run the following command in the gcb_slack directory:

gcloud functions deploy subscribe --stage-bucket [STAGING_BUCKET_NAME] \
    --trigger-topic cloud-builds

where [STAGING_BUCKET_NAME] is the name of your staging Cloud Storage Bucket that you defined earlier.

You should see an output confirming the creation of the cloud function and status: READY.

After you’ve completed deployment of the Cloud Function, when a build event occurs, you will receive a Slack notification.

Also, feel free to customize your app, like adding a custom icon, as I did with mine. ☝️

• Posting via Confluence REST API
• Creating a Lambda Function in AWS
• Schedule it!

Some mundane tasks can easily be automated. In my case, I needed something that could post to our Confluence instance at a specific time every week. This is because we use blog posts in Confluence for announcing our weekly volunteer meetings and as a simple attendance management.

Posting via Confluence REST API

Confluence, a team collaboration software written in Java and quite often used in corporate environments, offers a REST API that makes it possible to perform many operations on the content. In this case, I was interested in posting new content with some text, and I was getting tired of doing that manually every week. So, I thought: “I spend a lot of time on this task. I should write a program automating it!”.

The first take on that problem was a simple Python script:

import json
import requests

url = "https://some-confluence-url.com/rest/api/content/"
headers = { "content-type": "application/json" }
payload = { "type": "blogpost",
            "title": "Fancy meeting title",
            "space": {
                "key": "mySpaceNameGoesHere"
            },
            "body": {
                "storage": {
                    "representation": "storage",
                    "value": "Meeting description goes here."
                }
            }
            #"history": {
            #    "createdDate": '2017-01-10T14:00:00.000Z'
            #},

        }

response = requests.post(url, 
                         data=json.dumps(payload), 
                         headers=headers, 
                         auth=("myUserName", "mySecretPassword"))
print json.dumps(response.json(), indent=4, sort_keys=True)

You should be able to run this script against your end-point and post your content. Just note that I used requests library here that needs to be installed separately, for instance, by using pip:

sudo pip install requests

Also, you will need to update the following values in the script:

• url – the URL to your site
• type – can be a blogpost or a page
• title – page or post title
• space – a Confluence space where the post will belong
• value – content of the page, can contain HTML tags
• auth – username and password (please note that, for security reasons, it might be a good idea to create a separate user with restricted access rights just for posting specific content)
• createdDate – you can also add the commented-out part to add a specific blog post date

The script uses basic authentication to post the content and, if successful, returns metadata about the post as a response. If it fails, the response from Confluence end-point should point you in the right direction.

Creating a Lambda Function in AWS

Now we are one step closer to automation. The script works, and we can post content with a simple push of a button. What now?

Well, now I needed something to run that script and something to trigger that action. The trigger is the time as I wanted to run our script weekly, but first I needed to deploy our script to the Cloud. Scheduling and triggers would come later.

Since we had some infrastructure on AWS already, I decided to deploy the script on the same platform. I wanted to deploy it as a simple stand-alone function in the Cloud – in AWS world it is called a Lambda function.

I started by wrapping our code into a function and making it AWS Lambda function compatible – to define a function that takes two arguments: event and context. I choose to call the function blogpost_handler:

#!/usr/bin/python
# -*- coding: utf-8 -*-

# File name: poster.py

import requests
import json
import datetime

def blogpost_handler(event, context): 

    # Script is run on Sunday, need to use date for Tuesday
    next_tue = (datetime.datetime.now()
                    +datetime.timedelta(days=2)).strftime("%Y-%m-%d")

    url = "https://some-confluence-url.com/rest/api/content/"
    headers = { "content-type": "application/json" }
    payload = { "type": "blogpost",
                "title": "Meeting: "+next_tue,
                "space": {
                    "key": "mySpaceNameGoesHere"
                },
                "body": {
                    "storage": {
                        "representation": "storage",
                        "value": "Meeting description goes here."
                    }
                }
            }

    
    response = requests.post(url, 
                             data=json.dumps(payload), 
                             headers=headers, 
                             auth=("myUserName", "mySecretPassword"))
    
    print json.dumps(response.json(), indent=4, sort_keys=True)

    return response.json()

Now, I needed to package the code to make it ready to deploy:

# 1. create folder
mkdir blogposter
cd blogposter

# 2. create and copy the code above into poster.py
touch poster.py

# 3. install requests package locally
pip install requests -t .

# 4. zip contents of the folder and create a zip file in a parent directory
zip -r9 ../pyposter.zip *

And we are ready to deploy to AWS! Start with creating a new Lambda Function and selecting a blank function for this job.

I didn’t choose any triggers for now and continued to the configuration page. When presented with function configuration you need to give it a name, description, runtime, and a .zip file with the code. At the end, you will need to define a handler (which will typically be filename.function_name), and a role.

At the end of the wizard, you can run it manually by pressing the Test button. If you did all the steps above, this should now create a new post on your Confluence. Congratulations, you have now set up a stand-alone function in the Cloud!

Schedule it!

Now that I have automated the task and deployed it to the Cloud, I needed something to trigger that function. In this case, I wanted to schedule it to run weekly, so function was set to be triggered by the CloudWatch events. It offers a good support for scheduling Lambda expressions.

I defined event source as a cron expression, and a target as a Lambda function I created in the previous step.

# 9:05, every Sunday
5 9 ? * 1 *

Now you (and I) have a function that is scheduled to run weekly and does not require a dedicated machine to run. It also has some good options for logging and sending alarms in case it fails.

• 1. Technical Aspects
• 2. Legal Aspects
• 3. Rapid Development
• 4. Documentation
• 5. Testing and QA
• Bonus: Video

Apache Maven is a build automation tool used primarily for Java projects. It has been around for a while, and it does not seem to be going anywhere anytime soon (whether some of you like it or not). Recently, it has been confirmed yet again, this time in ZeroTurnaround’s Java Tools and Technologies Landscape Report 2016 (see the Build Tools section).

The good thing about Maven is that you can do almost anything with it and its plugins. With such a great ecosystem of plugins, able to do nearly anything, one might wonder where to begin when setting up a new Maven project or improving your old one.

I usually like to think of five main categories – or pillars – that we will be looking into in this post. Each category will have a set of example plugins that are meant to serve merely as a starting point.

In this post, I will assume that you have some experience with build tools in general and Maven in particular.

1. Technical Aspects

First of all, you would like to make sure that all the technical stuff is in place. You might want to automate the packaging, the checks if the project is running the latest version of all artifacts, that all the dependencies are met, and that the unused dependencies are removed. You might even want to define your own rules for all the things that cause troubles, or just simply annoy you down the line, making the build fail if they are not met.

With all that automation in place, you will be getting predictable results and nice packaging from the first day of the project.

Some of the plugins that should be mentioned here:

• Versions plugin does the versions management of artifacts in a project’s POM file
• Dependency plugin helps you analyzing dependencies, building dependency trees, showing unused dependencies, etc
• Assembly plugin helps you packaging all the dependencies, modules, site documentation, and other files into a single distributable archive
• Enforcer plugin lets you make your own rules! You can set up your build to break if some of your requirements are not met

2. Legal Aspects

With all the technical stuff out of the way, we might want to make sure that the legal side is taken care of as well.

Yes, I know, it might be less fun thinking about licenses than writing code, but it is still something that has to be done. You still have to release your code under some kind of license, and you will have to make sure that the third-party licenses do not violate your own licensing. So, why not leave that job to a plugin?

The following plugin will manage the license of a maven project and its dependencies; it will also update file headers, download dependency licenses, check third-party licenses, etc.

• License plugin

3. Rapid Development

Now, back to coding. Or even better – to seeing the results of your hard work. The chances are that you will need some kind of web or application server for running your code, and you want to able to deploy to that server in no time. Another kind of plugins that will be helping you from the very first day of the project.

Some of the plugins that can be mentioned here:

• Apache Tomcat plugin
• Jetty plugin
• WildFly plugin
• …or any other deploy plugin, depending on your application

4. Documentation

Every decent project must also be properly documented. However, this is something that developers might postpone until the end. Well, no more! This kind of plugins will help you to get started early and will help you to produce some beautiful (maybe?) and maintainable docs.

You might even consider coupling these with some rules in the Enforcer plugin, but tread carefully as too many, and too strict rules can, and usually do, backfire.

• Site plugin
• Asciidoctor plugin

5. Testing and QA

By now, your code should be looking great, with all the right licenses, and up and running in no time. So, how about squashing some [virtual] bugs? The list below might help you setting up a proper QA environment and fixing bugs before the come crawling to your production servers.

• Surefire plugin
• Failsafe plugin
• SonarQube plugin
• FindBugs plugin
• PMD plugin

Bonus: Video

A video of a talk I gave about this topic at JavaZone in Oslo (in Norwegian).

• 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.