iTouch

App’en som skal lages er et spill, hvor poenget er å taste en gitt tekst feilfritt, raskest mulig. Spillet skal støtte flere samtidige spillere, og alle spillere skal fortløpende se hvordan konkurrenter ligger an underveis, samt status på egen tasting i form av fargekoding av tastet tekst.

Jeg ser for meg en arkitektur der vi kjører JavaScript på server, JavaScript+HTML på klienter, og sanntidsoppdatering av konkurrentstatus over Web Sockets.

Tanken er at på hvert tastetrykk, sender klienten inntastet tekst til serveren for validering. Serveren sender så tilbake et statusobjekt som sier noe om hvorvidt tastet tekst er feil, hvor mye av tekst som gjenstår osv. Det blir så opp til klienten presentere denne statusen til brukeren.

Litt om teknologi

Til Web Sockets-kommunikasjonen skal jeg bruke rammeverket NowJS, som er ganske fascinerende. Det lar deg synkronisere JavaScript-variabler og -funksjoner mellom klient og server, slik at man kan kalle funksjoner på server direkte fra klient, og faktisk også funksjoner definert på klient(er) direkte fra server. NowJS baserer seg på veletablerte SocketIO.

Serverkoden kjører på Node.js, som er blitt en defacto plattform for serverside JavaScript.

Testdrevet utvikling

I JavaScript er det p.t. en rekke testrammeverk tilgjengelig. Jeg har valgt å bruke Jasmine, mest fordi jeg liker BDD-syntaksen, og at man kan benytte rammeverket til å teste både klient- og serverkode. I dag ville jeg nok gått for Buster.JS, men mer om Buster senere.

Man kan fint kjøre Jasmine-tester standalone i en nettleser, men det er fornuftig å benytte seg av en test runner, eksempelvis JS Test Driver. Bloggpost’en til kollegaer Torstein og Børge: ”Getting started with JS and TDD”,  gir en grundig innføring i hvordan Jasmine er i bruk, samt hvordan man integrerer med JS Test Driver.

Det avgjørende her er å få lastet ned riktige biblioteker, lagt disse inn i en fornuftig mappestruktur, og fått satt opp en jsTestDriver.conf-fil til å reflektere denne.  I tillegg kan det være fornuftig å installere “jstdutil”. Dette verktøyet lar deg kjøre kommandoene “jstestdriver” og “jsautotest” fra kommandolinja. Sjekk siden til Christian Johansen for installasjonsbeskrivelse.

Prosjektet mitt benytter altså Jasmine som testrammeverk, og JS Test Driver for å kjøre testene. Når disse tingene er på plass, er man klar til å skrive første test!

Første test

Dette blir litt som å skrive første setningen i en bok, eller i denne bloggposten for den saks skyld. Jeg tenker det enkleste å teste i min kode måtte være mekanismen som validerer inntastet tekst. Jeg ser for meg at vi oppretter en scoringobjekt som tar inn en tekst, og returnerer et statusobjekt som sier noe om hvilke bokstaver i teksten som evt. er feil.

Vi spesifiserer forventet oppførsel i filen spec/scoring.spec.js:

it("should validate text with 2 errors",
function() {
    var typedText = "DeTte Er en test";
 
    expect(scoring.validate).toBeDefined();
 
    var results = scoring.validate(originalText, typedText);
 
    expect(results.errors.length).toEqual(2);
    expect(results.errors).toEqual([2, 6]);
});

og kjører kommandoen ”jstestdriver –tests all –reset”, eller enda bedre ”jsautotest”. Vi får beskjed om å opprette scoring-modulen i namespacet TDD, med funksjonen “validate”. Og etter litt TDD’ing ender vi opp med en mer eller mindre komplett scoring.spec.js  med tilhørende implementasjon scoring.js.

Arkitektur

Før vi går videre med tester, kan vi titte litt på kodearkitektur. I tillegg til scoring-modulen, trenger vi funksjonalitet for å administrere selve spillets gang. La oss gi denne modulen navnet “game”. På klientsiden trenger vi en modul som styrer kommunikasjonen med server og oppdatering av skjermbilder; game_controller.js

Hvis vi skisserer opp systemet, så har vi et avhengighetsbilde som ligner dette:

Vi vet at game benytter NowJS-rammeverket for å formidle sanntidsinformasjon, i tillegg til scoringmodulen for å kalkulere status. Samtidig skal game_controller.js kommunisere med game.js vha. NowJS.

Når man nå skal sette sammen disse bitene, er det viktig å tenke at de skal være løst koblet. Dette kan man få til ved å spesifisere eksterne avhengigheter ved opprettelse av modulene. F.eks., får game.js sprøytet inn en referanse til scoring og NowJS når den blir opprettet, og kode for å opprette et game-objekt blir:

var game = TDD.game.create({
    originalText: "En tekst",
    scoring: TDD.scoring.create(),
    everyone: this.everyone
});

Dette gjør det lett å enhetsteste game.js, da man enkelt kan stubbe/mocke disse avhengighetene.

Mer testing

Nå har det liten hensikt å gå i gjennom all kildekode og tester i teksten her, men vi skal se litt mer på hvordan utvalgt funksjonalitet er implementert og testet.

Når det gjelder game-modulen, skal denne bla. ha funksjonalitet for å

• registrere deltakere
• sette i gang en ny omgang
• distribuere forløpende status til alle deltakere

Hvis vi ser nærmere på det siste punktet, så skal status sendes fortløpende til alle deltakerne i sanntid over Web Sockets vha. NowJS. Web Sockets-kommunikasjonen er fullstendig abstrahert bort av rammeverket, og alt man trenger å gjøre er å legge til funksjoner i det spesielle ”now”-objektet som blir synkronisert mellom server og klient. Rammeverket fungerer slik at man kan adressere server via now-objektet på klienten, samt adressere alle klienter via everyone.now-objektet fra serveren.

Når man vet hvordan dette rammeverket fungerer, er man i stand til å spesifisere testen:

it("should validate text and distribute scores upon validation request",
function() {
    var typedText = "Dette er en";
    var status = {
        "errors": [1],
        "percentage": 98
    };
    spyOn(this.game.scoring, "validate").andReturn(status);
    spyOn(this.everyone.now, 'receiveScores');
 
    this.game.validate(this.everyone.now, typedText);
    expect(this.everyone.now.receiveScores).toHaveBeenCalledWith({
        clientId: "123",
        name: undefined
    },
    status);
});

Her bruker vi spy-egenskapene til Jasmine, til å legge til en forventning om at når man kaller ”validate”-funksjonen på serveren, så skal ”receiveScores”-funksjonen kalles på alle klienter.

Selve this.everyone.now er en stub vi selv spesifiserer:

this.everyone = {
    now: {
        validate: function() {},
        receiveScores: function(clientId, score) {},
        startGame: function() {},
        displayTextToBeTyped: function() {},
        hideStartButton: function() {},
        showStartButton: function() {},
        clearText: function() {},
        gameOver: function() {},
        user: {
            clientId: "123"
        }
    }
};

Igjen, er det bare å implementere spesifikasjonen og kjøre testene:

Firefox 10.0 Mac OS [PASSED] Game.should massage original text
Firefox 10.0 Mac OS [PASSED] Game.should validate text and distribute scores upon validation request
Firefox 10.0 Mac OS [PASSED] Game.should NOT end game when text is errornous
Firefox 10.0 Mac OS [PASSED] Game.should end game when text is complete with no errors
Firefox 10.0 Mac OS [PASSED] Game.should start game on request
Firefox 10.0 Mac OS [PASSED] Validation of text and scoring.should validate typed text
Firefox 10.0 Mac OS [PASSED] Validation of text and scoring.should validate text with 2 errors
Firefox 10.0 Mac OS [PASSED] Validation of text and scoring.should calculate score when typed text is 100% complete
Firefox 10.0 Mac OS [PASSED] Validation of text and scoring.should calculate score when typed text is 0% complete
Firefox 10.0 Mac OS [PASSED] Validation of text and scoring.should calculate score when typed text is incomplete
Total 10 tests (Passed: 10; Fails: 0; Errors: 0) (8.00 ms)
  Firefox 10.0 Mac OS: Run 10 tests (Passed: 10; Fails: 0; Errors 0) (8.00 ms)

Hva med klienten?

Det er like enkelt å teste klientkode som serverkode, selv om man må hanskes med en DOM. Det avgjørende her er å gjøre klientkoden ”unobtrusive” og ikke mikse JavaScript og HTML-markup mer enn nødvendig.

Vi kan begynne med å tenke litt på hvordan markup’en på klienten skal se ut. Da spillet går ut på taste en gitt tekst, trenger vi i hvert fall et editerbart felt, og et element til å presentere tekst som skal tastes. I tillegg kan vi legge til en knapp for å starte en omgang, samt et element for å vise progress bars. Grensesnittet kan f.eks. se slik ut:

med tilhørende HTML:

<!DOCTYPE>
<html>
  <body>
    <div id="wrapper">
      <h1>iTouch</h1>
      <input id="name" type="text" placeholder="Skriv inn navnet ditt her og trykk ENTER"/>
      <button id="startButton">Start ny omgang (vent til alle er klare da)</button>
      <div id="text-to-be-typed"></div>
      <div id="typed-text" contenteditable="true"></div>
    </div>
  </body>
</html>

Med disse antakelsene, kan vi utvikle klientlogikken – test først.

Eksempelvis kan vi spesifisere at spillet skal startes når noen klikker på ”Start ny omgang”-knappen på følgende vis:

it("should do start game when start button is clicked",
function() {
    spyOn(this.game, "startGame");
 
    this.startButton.trigger("click");
 
    expect(this.game.startGame).toHaveBeenCalled();
    expect($(this.startButton).is(':hidden')).toBeTruthy();
});

Denne testen spesifiserer at startGame-funksjonen skal kalles, og at knappen skal skjules.
$(this.startButton) er et jQuery-wrappet element som er definert slik:

this.startButton = $("<button></button>", {
    id: "startButton",
}).appendTo(document);

og sprøytet inn i game_controller-modulens create-funksjon.

Slik kan vi fortsette; ta f.eks. koden som tester at tekst fargelegges korrekt. Ganske avansert GUI-messig, og ganske enkelt å teste da man kan simulere nettleser-eventer, kjøre css-spørringer osv.:

it("should color text upon text validation and update progress bar",
function() {
    var self = this;
    var originalText = "Dette er en test";
    var typedText = "Dette er En";
    var errorIndex = 9;
    var clientId = "123";
 
    spyOn(this.now, "validate").andCallFake(function() {
        self.now.receiveScores({
            clientId: clientId,
            name: "Snorre"
        },
        {
            "errors": [errorIndex],
            "percentage": 95
        })
    });
 
    this.game.now.displayTextToBeTyped(originalText);
 
    this.typedTextElement.text(typedText);
    this.typedTextElement.trigger("keyup");
 
    expect(this.now.validate).toHaveBeenCalled();
    expect($(this.textToBeTypedElement).find(":nth-child(1)").css("color")).toEqual("rgb(0, 128, 0)");
    expect($(this.textToBeTypedElement).find(":nth-child(" + (errorIndex + 1) + ")").css("color")).toEqual("rgb(255, 0, 0)");
    expect($(this.textToBeTypedElement).find(":nth-child(" + (typedText.length + 1) + ")").css("color")).toEqual("rgb(0, 0, 0)");
 
    expect(this.wrapperElement.find("#" + clientId).attr("value")).toEqual(95);
});

Når man lager JavaScript-koden “unobtrusive” (i mangel av et bedre norsk ord), blir man kvitt all spagettikode man ofte ser i $(document).ready(), og sitter igjen med en ryddig index.html.

Hmmm, hvorfor kjører vi alle testene i Firefox?

Inntil nå, har vi kjørt klientestene og servertesten i kontekst av en nettleser via JS Test Driver. Da vi at vet at serverkoden skal kjøre på Node, gir det ikke mening å la ymse nettleser-JavaScript-motorer - og ikke Nodes Google V8-baserte kjøretidsmiljø, tolke koden vår. Vi kan bote på dette ved å kjøre server testene med jasmine-node. Dette er en Node.js-modul, som installeres med npm (som nå bundles med Node-installasjonen). Da kan vi kjøre servertestene våre med:

~/dev/faggruppe/iTouch(git::master):➔ jasmine-node spec/server --verbose
Started
..........
Spec Game
  it should massage original text
  it should validate text and distribute scores upon validation request
  it should NOT end game when text is errornous
  it should end game when text is complete with no errors
  it should start game on request
Spec Validation of text and scoring
  it should validate typed text
  it should validate text with 2 errors
  it should calculate score when typed text is 100% complete
  it should calculate score when typed text is 0% complete
  it should calculate score when typed text is incomplete
Finished in 0.005 seconds
2 tests, 24 assertions, 0 failures

Dette fremprovoserer også det faktum at vi er nødt til å gjøre om scoring.js-modulen til å være Node/CommonJS-kompatibel, da Node krever dette. Dette gjøres ved å legge til disse linjene i scoring:

if (typeof module === 'object') {
    module.exports = TDD.scoring;
}

Man kan da “hente” ut en referanse til scoring-modulen som en vanlig Node-modul slik:

TDD.scoring = require("./src/server/scoring");

Buster

Her kommer vi tilbake til Buster.js. I tillegg til å være et flott testrammeverk på andre måter, gir Buster deg mulighet til å kjøre klient- og servertester med samme test runner. Buster.js er snart ute av beta, blir spennende å sjekke det ut nærmere.

Skru alt sammen

Når all JavaScript-logikken er ferdig implementert, gjenstår konfigurasjon av Node, slik at vi kan begynne å teste spillet. All denne konfigurasjonen gjøres i filen app.js. Her ser vi hvordan vi oppretter et game-objekt, med alle dets avhengigheter.

Her er et artig lite avbrekk i en ellers hektisk prosjekthverdag:

Oppsummering

Å komme fra en typisk hverdag der jeg skriver “mvn clean install” altfor mange ganger i løpet av en dag, er det utrolig frigjørende å se hvor raskt disse JavaScript-testene kjører. Når man først kommer inn i det, er JavaScript en fornøyelse å jobbe med, spesielt med tanke på egenskapene ved språket. TDD i JavaScript er definitivt ikke vanskelig, og det er like greit å lære seg teknikkene først som sist.

On a side note:

Magnar Sveen snakker om zombietdd-prosjektet sitt i morgen på Framsia at CiA 2012 – Responsive, realtime and Zombies! Meetup’en omhandler forøvrig Web Sockets og Node.js, så det er ikke helt urelatert til det som blir tatt opp her!

Are you working on unmaintainable JavaScript code? Are you afraid to make changes to your 5000+ lines long JS file? If so, you’ve probably not written tests or done TDD. Fear not! Read on, and we will show you how to get started with writing tests and setting up the needed tools. We will show by example how to create a small, yet complex, JS web application using TDD.

JavaScript is becoming increasingly popular for developing full-fledged applications – both server and client side. Looking at the current trend of how JS is used, we can see that it’s being used for business critical applications and large-scale applications. With all this popularity and extensive use, we are under the impression that the testing and quality focus is lagging behind.

After reading this blog post, you will know how to get started with JS TDD using tools and frameworks we consider easy to use and relatively mature. If you already know why you should test your JS code, feel free to skip the background.

If you want to take a closer look at the example application, feel free to check out the entire project from GitHub @ http://github.com/bekk/jstdd.

Background

JavaScript has received a popularity boost from browser vendor’s quest to write the fastest JS engine, as well as the popular programming language node.js. In addition, jQuery has simplified the way we interact with the DOM and smooths over annoying browser differences – making JS more accessible for everyday developers. Focus have been primarily on producing functionality, and not on testing and good design/clean code. We believe that one reason is the lack of standardized or commonly available testing tools and frameworks. Another reason might be that traditionally JS have been written by UI and UX developers, who’s focus have been primarily on functionality – not on Clean Code and testability.

JS and all other dynamic programming languages is in dire need of tests since there is no compile-time checking. Tests can be used to ensure that the application behaves as expected, and gives developers confidence to make changes to existing code. Despite the obvious need for testing, many developers skimp on writing tests when developing large JS applications. All the advantages of TDD that applies for other programming languages, also applies for JS. Who does not want testable, maintainable, readable, well-designed, modular and working code? It’s well established that TDD has positive effects on code quality (read the chapter on TDD by Robert C. Martin in The Clean Coder).

Other popular programming languages like Java and C# have mature and well-documented testing-tools. At the time of writing, JS has several testing frameworks available, but only a handful mature. Looking at the options, no one really stands out as a clear choice. To make things worse, getting started with JavaScript TDD can be challenging. There are so many ways of going about setting up a complete test-environment for JS. We have looked into this and had some experience with what works and what doesn’t.

The runner

JsTestDriver is (as it’s name implies) a tool that let you run your JS tests. You can run your tests directly from your favorite IDE (at least in theory) to get into your TDD rhythm. It runs from the command line and even on your continuous integration server. In our examples we’ll be running it from the command line.

A quote from their home site says it all: “The goal of JS Test Driver is to make JavaScript unit test development as seamless as and easy as Java unit tests.”

JsTestDriver supports testing in different browsers through capturing browsers as a slave machines. It includes it’s own limited assertion framework, but also supports add-ons, which opens for a wide range of third party assertion frameworks. We will be using Jasmine BDD through an adapter.

As with everything else, there is room for improvement. JsTestDriver’s configuration can sometimes be too simple, and advanced users may feel limited. In our simple example it works great, but expect some issues when scaling up. As a note, we did not get the IDE integration in IntelliJ IDEA to work properly.

Recently Buster.js was released as beta, and is worth checking out as an alternative to JsTestDriver.

The framework

We’ve picked out Jasmine because it is a mature (compared to most other frameworks) and a popular testing framework for JS. It features BDD syntax, which gives clear and readable tests with functionality in focus. It does not depend on any other framework and does not require a DOM. It can be run in the browser, through JsTestDriver or through node.js. It is well documented and is easy to get started with.

There are a few things to consider. They don’t separate between mocks, stubs and spies. All of that is packed into what Jasmine describes as a spy. The bundled matchers are good, but few. To get readable tests, it’s often necessary to write custom matchers to match the domain language. Still, we consider this one of the few viable options for doing TDD in JS.

Installing, setting up and using Jasmine is easy, and will not be detailed here. We’re using Jasmine through JsTestDriver, and have configured it thereafter.

QUnit was considered as an option, but it’s syntax did not help us achieve as readable and clear tests as Jasmine. It’s simplicity makes it very attractive and useful for beginners, but more advanced users will want more.

Demo application

As stated in the introduction, we’ll make a little application that does an “I feel lucky” search from Flickr. One of the choices we made was to have a minimal setup. No jQuery and third-party libraries in the production code, with the intention to reduce complexity and make the example more transparent as to how things work.

Pre-requisites

If you want to use the same setup as us, we recommend doing the following.
(Or you can check out the entire project from GitHub @ http://github.com/bekk/jstdd).

Download these libraries:

• https://github.com/ibolmo/jasmine-jstd-adapter (version 1.1.1)
• https://github.com/pivotal/jasmine (version 1.0.1)
• http://code.google.com/p/js-test-driver/ (version 1.3.2)

Create the following folder structure:

.
├── lib/ # 3rd party libs lies here
│   ├── jasmine.js
│   ├── jasmine-jstd-adapter/
│   └── JsTestDriver-1.3.2.jar
├── spec/ # test/specs lies here
├── src/  # application source lies here
├── server.sh # Starts a JSTD server (symlinked)
├── test.sh # Runs the test (symlinked)
└── jsTestDriver.conf # JSTD configuration for our project

server.sh and test.sh are just shortcuts to scripts bundled with js-test-driver.

Configure jsTestDriver.conf to match your setup.

Getting familiar with the framework

We started off with a simple test to get familiar with the syntax and to verify that everything is set up correctly. Consider it a warm-up exercise.

describe("Jasmine", function() {
    it("makes testing JavaScript awesome!", function() {
        expect(true).toBeTruthy();
    });
});

Running it

Running it the first time might seem a bit overly hard, but once you’re set up it’s easy to run the tests. Before you start the server, you need to write a little config file. Take a look at ours if you need an example.
Starting the server can seem a bit tedious, but we found a shell-script that starts the server. All we had to do was modify the path to suit our project structure (see server.sh). Running it is just a matter of typing ./server and seconds later the server is up and running.

Example output from a test run:

Running all tests
Chrome: Runner reset.
....
Total 1 tests (Passed: 1; Fails: 0; Errors: 0) (1.00 ms)
Chrome 12.0.742.112 Mac OS: Run 4 tests (Passed: 1; Fails: 0; Errors 0) (1.00 ms)

Next task is capturing browsers. We spun up browsers on each others computers and went to http://[my address]:9876/capture and the browser became a slave. Excellent! We used Safari, Firefox and Chrome to test. Make sure to keep the browser running while testing.

Captured browser

JsTestDriver supports distributed test-running, but that is not something we will explore in this blog post. Now all that is left is telling the server to ask the browsers to run the tests. With the scripts, it’s just a matter of typing ./test in the shell and the tests are run.

The flow for starting the first time is the following:
1. Start server
2. Capture browsers
3. Run tests

After than you just type ./test each time you want to run the tests.

Working on LuckyFlickr

Start with the tests

We decided to start with writing tests to verify output on the result page. The simplest possible test we could think of was to test for a message when no result was found.

Next, we added a new test to verify that if a result were received, the parser would pick the first result and display the image on the result page. Since we were doing unit testing we didn’t want to go all the way to Flickr when we ran the test, so we created a simple stub that returned some JSON data on the expected flickr format so we could run the test in isolation. The specs for the parser read:

• “outputting result”
• “should not output an image when there are no results”
• “should output the image from the result”

Note: When reading these specs, read them like “Outputting result should not output an image when there are no results”.

When pondering what to do next, we figured we could create a test for the component that would fetch data from flickr. Since we wanted to get out data from another site, we decided to use JSONP to overcome the cross-site problem. We also wanted the component to send the flickr request asynchronously, so we had to write a test that would handle that. To fix this we created setup code to temporarily replace the default XMLHttpRequest implementation in JS with our own. That way we could control what the response would be. We decided to let it respond with the same JSON stub as in the parser test.

• “when querying flickr”
• “should create a global function that handles the JSON-P callback”
• “should do a search and call the callback function”

The last step was to create some tests to make sure the GUI was displaying the result in the right container in the result page. On this step, we saw that some of the components came together, and introduced the need for mocking. We mocked the result given by the “fetcher”. Doing so, we’re not dependent on a connection to flickr.com. We created 2 tests for this. The first asserts that the result from flickr is displayed in the result container, and the second one asserts that “Loading” is displayed while it is fetching data from flickr.

The result

Since our focus was unit testing, our implementation ended out with three separate “units” that each did one important thing. We have a “fetcher” that goes out and fetches the result from Flickr, a “result parser” that knows how to parse the JSON data structure from Flickr and finally the component that enables the user to do a search. No enterprisy patterns, no unneeded complexity, no silver bullets. Just enough to make things work. Also, the design emerged from writing the tests first.

Our experiences

We experienced a couple of notable challenges when doing TDD in JS. Doing TDD in it self is not a problem. Some challenges appear when doing browser-specific things with JS. Such as asynchronous callbacks, handling the DOM and the AJAX browser API.

The DOM is an issue. When not using jQuery, there are a lot of quirks that can mess up tests in specific browsers. Also, doing DOM-operations without jQuery results in a lot of ugly code that affects readability.

Testing AJAX without support from the test framework is problematic, and is why several tools exist and mitigate this (Sinon.js, Mockjax, etc.). Before we changed to JSONP, we wanted to do this with no extra support, and ended up with an extremely simplified version of what the mentioned tools provide. But for most people it would be simpler to use an existing tool to help you do AJAX-testing.

But all these things mentioned above are relatively easy to overcome and the upside of being able to write tests for your JS code easily outweighs the small quirks you may experience. And you won’t regret spending time on writing tests when your code base is expanding and you need to make a change.

Give me more!

Sinon.JS – Standalone test spies, stubs and mocks for JavaScript. Works with any unit testing framework.
QUnit – alternative to Jasmine. Developed by the jQuery-team
Cucumber.JS – early stages. Could be good.
Buster.js – a new test framework (currently in beta) from Christan Johansen (the man behind Sinon.js)

For 25 år siden ble det utgitt en bok Peopleware – Productive Projects and Teams. Dette er en klassiker, og jeg synes det er sunt å minnes på de prinsippene som den omhandler. I tillegg til hardware og software er det en viktig del som vi kan kalle peopleware. Det er det menneskelige aspektet ved utvikling. Det er bare én måte å få frem de systemene og løsningen som vi utvikler, og det er gjennom mennesker. Dette er smarte, høyt utdannede mennesker med en driv for teknologi.

Disse folkene er katalysatoren for det vi lager. Hvordan oppnår vi da de beste resultatene? Svaret er ikke kynisk eller maskinelt. Peopleware er fortsatt utrolig relevant, og det er ikke til å kimse av etter hele 25 år. Årsaken er at folk fortsatt er folk. De har de samme behovene, motivasjonene og relasjonene. Det er lett å fokusere på hvor raskt vår bransje utvikler seg teknologisk. Men folkene bak, de som gjør det hele mulig, de som skaper selve verdien. De er like menneskelige som før.

Det er en utbredt illusjon i databransjen, at det vi jobber med er high tech. Vi jobber med avanserte, kompliserte tekniske systemer. Det er teknologi på sitt ypperste. Datamaskiner er noe av det mest imponerende og kraftige mennesker har utviklet. Og nøkkelen til å lykkes er å forstå og benytte den mest avanserte, den høyeste, teknologien. Når de teknologiske grensene pushes går vår verden fremover, og fremskritt og konkurransefortrinn blir mulig.

Mennesker vs. teknologi

Men tilfellet er at databransjen ikke er high tech. Dette er ikke rakettforskning. De fleste systemer har ikke behov for eller berører avansert datavitenskap eller teknologi. Mange prosjekter er avarter av create, read, update og delete, eller handler om å vise data som allerede finnes på en ny måte til brukeren. Det er som oftest ingen fysikk eller matematikk bak systemene vi lager. Selv om hardwaren er avansert og datamaskinen fundamentalt kompleks, så kan vi ikke lure oss selv til å tro at vi er i high-tech-bransjen. Det er fristende å tenke slik. At å løse de tekniske, teoretiske problemene er nøkkelen til suksess. Det er på en måte en “enkel” løsning. Det er mer håndterbart å finne den optimale algoritmen enn å forstå hvorfor Arne ikke jobber produktivt. Men suksessfulle prosjekter og effektive team handler ikke om teknologi. Det handler ofte om menneskene bak. Vår bransje er teknisk, men det er ikke teknologien som skaper suksess. Om det bare hadde vært så enkelt.

Har du noen gang vært på et dream team? Fått følelsen av at dere sammen jobber nær optimalt og har høy produktivitet? Har du noen gang jobbet i det motsatte? En samling mennesker som ikke får utrettet store ting. Et team på papiret, men ikke i praksis? Resultatetene fra et dream team er ikke basert på teknologien de bruker, men heller av dynamikken mellom menneskene i teamet. De utfyller hverandre. De kommuniserer godt. De vet hvor de har hverandre, og hvordan de kan bruke hverandre. Teamet er støpt. De har høy suksess med sine prosjekter, og grunnen er at de kan bruke all innsats på å løse prosjektets problemer og klientens behov, i stedet for andre ikke-verdiskapende utfordringer.

Hva kjennetegner et slikt team? Et tegn er at de er kvalitetsorienterte. De vet hvilke kvalitative ting som gjør prosjektet vellykket, og de fokuserer på dem. Kvalitet i datasystemer ses ofte på som en kostnad, og noe man oppnår ved å ofre andre ting, som for eksempel penger og tid. Men the dream team oppnår suksess med kvalitet som en drivfaktor. Kvaliteten gir to verdier: Man unngår bortkastet tid på å “rydde opp” om man gjør det ordentlig fra første stund. Og kvalitet er en motivasjonsfaktor i seg selv.

I stedet for å “cut the corners” vil the dream team gjøre det ordentlig. Det man oppnår med dette er en jevn fremgang uten skitne overraskelser som for eksempel at man ikke har noen enhetstester, eller at man har hardkodete verdier som senere ønskes å endres. Progresjonen blir kanskje lavere enn et forhastet team, men den er forutsigbar uten teknisk gjeld og andre overraskelser.

Jeg ble engang forsøkt rekruttert av et større IT-selskap. Jeg spurte dem rett ut: Hvorfor bør jeg jobbe hos dere? Svaret deres var: Fordi vi er den beste aktøren i markedet og har de mest fornøyde kundene. Vi er de beste og mest suksessfulle. Rekruttererne tenkte nok at dette var imponerende, men jeg tenkte “what’s in it for me?”. Folk har lyst til å realisere seg seg selv, og sine behov. Ikke bedriftens behov og finansielle målsetninger. Heldigvis finnes det en synergi her. Ved å oppfylle arbeidernes behov, kan bedriftens mål nås. Kvalitet er en motivasjon og drivkraft i seg selv. Forteller du et team at kvaliteten i det de gjør ikke er så viktig, så vil selvrespekten og moralen følge derhen. Mennesker har en iboende kraft til å realisere seg selv, å lage ting som er så bra som de har kraft til å få til.

Et slikt støpt team utvikler elitiske holdninger. Det er et godt tegn. De er stolte av seg selv, og har tro i sine evner. Slike team vil også tendere mot å være selvledende. Siden motivasjonen er høy, og de ønsker å nå organisasjonens mål vil de selv ta grep for å få dette til. Fra et manager-perspektiv er dette en drømmesituasjon; og bør være et mål i seg selv.

Miljø

Mennesker er i høy grad et produkt av omgivelsene rundt en. Disse omgivelsene kan løfte en frem og få det beste ut av en, eller de kan stikke kjepper i hjulene. Har du noen gang jobbet på kontoret sent på kvelden eller i helgen? Kontorlandskapet er tomt, det er stille og øde. Der sitter du, på din sedvanlige plass. Har du lagt merke til at man ofte er høyst effektiv i dette miljøet? Man har kanskje satt av en liste med oppgaver man må få ferdig. Det ble ikke plass til dem i den vanlige arbeidstiden, så man setter opp en økt på kvelden eller i helgen. Man pløyer gjennom de oppgavene. Man går hjem med følelsen av at i dag var jeg effektiv. God progresjon i dag, godt jeg tok meg tid til den ekstra økten.

En viktig årsak er nok rett og slett at du fikk være i fred. Det er en tendens for åpne kontorlandskap i vår bransje. Fra åtte om morgenen til fire om ettermiddagen er det folk rundt deg. Disse folkene skaper støy, uro og avbrytelser. På grunn av den innebygde forsinkelsen vårt sinn tar for å komme ordentlig i gang med en mental oppgave kan disse forstyrrelsene hindre produktiviteten. Vi jobber i en kunnskapsbransje, og tankekraft er essensen i produktene vi skaper. God konsentrasjon er avgjørende, men til dels ikke mulig i et støyende og kollektivt kontorlandskap. Det er en kontradiksjon egentlig; vi har høy utdannelse, jobber med kompliserte abstrakte konsepter som ikke har noen fysisk manifestasjon. Men allikevel er en lukkbar kontordør en luksus bedriften ikke tar seg råd til.

I Peopleware foretok de en programmeringsøvelse hvor et spesifisert system skulle implementeres. De gruppene som gjorde det godt ble sammenlignet med de som ikke nådde milepælene på samme tid:

Resultatene er kanskje ikke overraskende. De som gjorde det best hadde avlukkede kontorer som de delte med 0, 1 eller 2 andre. De svakeste jobbet i åpne områder. Mange kan nok si seg enige i at kollektive rom hemmer konsentrasjonen. Men har du kvantifisert hvor mye plassbesparelsene koster i produktivitet?

Management

Hva er jobben til en manager? Han driver ikke direkte med verdiskapningen. Det er det utviklerne som gjør. Det er de som løser kunden og brukernes problemer. En av managerens viktigste oppgaver er å få de under ham til å gjøre en god jobb. Den beste jobben gitt deres forutsetninger. Det finnes mange ulike synspunkter på hvordan man får dette til. En viktig management-oppgave er å sette deadlines. Slike frister kan brukes som et virkemiddel i seg selv. Parkinsons “lov” sier at arbeid utvider seg selv til å fylle tiden det er satt av til. Vi kjenner alle godt til rasjonalen bak. Om man har press på seg skynder man seg. Om noe ikke haster kan man ta seg bedre tid. Dette leder til en logikk som er mye brukt i management. Tighte, kanskje urealistiske deadlines virker motiverende og øker produktiviteten. Bare pass på å ikke avslør at deadlinen er kunstig tidlig!

I praksis fungerer det ikke. Utviklerens produktivitet og arbeidsmetode er avhengig av deadlines, men en urealistisk deadline kan være høyst demoraliserende. En undersøkelse ble foretatt blant flere titalls prosjekter. Det ble sett på hvem som utførte tidsestimatetene, og hvor høy produktiviteten var for hver oppgave. Hvor utvikleren gjorde estimatet var produktiviteten 8. Dette er så klart et relativt tall. Hvor utviklerens sjef gjorde estimatet var produktiviteten 6.6. Haha, tenker man så klart. Dumme manageren tror han vet bedre enn gutta på gulvet!

Men i tilfeller hvor en ekstern system-analytiker gjorde estimeringen var produktiveten enda høyere med 9.5. Hva er grunnen til dette? Det kan være at systemanalytikeren er en profesjonell estimerer med god erfaring fra tilsvarende implementasjoner. At hans estimater er nærmere det egentlige innsatsbehovet kan være motiverende i seg selv. Realistiske deadlines er gir dermed høyst produktivitet. Et interessant resultat oppsto i oppgaver hvor intet estimat i det hele tatt var gitt. Her var produktiviteten 12, og dermed høyest. Dette kontradikterer helt tydelig Parkinsons lov, og setter i tvil dens effektivetet som management-verktøy.

Dream manager

Et dream team krever en dream manager. Men hva kjennetegner en slik manager? Det er kanskje ikke hva en tradisjonelt forbinder med ledelse. Et dream team har en iboende egenskap å gjøre det godt, og en dream manager enabler dette. Det er ikke så lett å måle en managers evne til å enable sitt team, men det er allikevel en av det viktigste egenskapene. Det motsatte ville vært defensivt management. En defensiv manager stoler ikke på sine “undersåtter”. Han er opptatt av sitt eget bilde, og forsvarer det mot eventuelle utfordringer. Han ser på seg selv om drivkraften bak teamets progresjon og suksess, og underminerer deres evne til fatte de riktige avgjørelsene selv.

Et godt motivert og fungerende team er en drivkraft i seg selv. En god manager vil utnytte disse kreftene og enable og løfte teamet. Hindre i veien elimineres, og byråkratiske eller organisatoriske problemer løses. Manageren er oljen i teamets maskineri. Disse egenskapene er ikke alltid like lette å observere på overflaten. Kanskje manageren virker overflødig på grunn av teamets selvstendighet og effektivitet. Men nettopp dette kan være resultatet av en managers dedikerte arbeid bak kulissene.

Folkevare

Data og systemutvikling er tilsynelatende en teknologisk, komputasjonell bransje. Men faktum er at det er menneskene som jobber med dette som er drivkraften. De teknologiske utfordringene er interessante og nyttige som et minstemål. Men løsningene bunner alltid ut i mennesker som jobber sammen. Mennesker med sine behov, sine mål og sine motivasjoner. Disse endrer seg ikke i samme takt som prosessorkraft og minnestørrelse.

Det er ikke like lett å analysere sosiologien bak utvikling som det er å drøfte teknologien, men x-faktoren i systemutvikling er menneskene bak. Mens maskinvare og programvare skyter fremover, er det fortsatt de samme type mennesker som jobber med disse tingene. Kun ved å forstå disse temaene kan man få det meste ut av teknologien og lykkes i sine prosjekter.

Konklusjonen er at kvalitet kan være så mangt. Selv i faggruppen har vi fortsatt hvert vårt syn på hva kvalitet er.

Her er våre tanker: hva er dine?

Vegard Hartmann

Kvalitet er for mange et subjektivt begrep og kan derfor være vanskelig å sette ord på. Når jeg tenker på noe som har kvalitet så tenker jeg på noe som er solid, robust og som varer lenge.

Dette passer imidlertid kanskje ikke like godt for software. Der kan det hende at egenskaper som stabilitet, funksjonalitet og fleksibilitet er mer dekkende for å beskrive kvalitet.

Kvalitet dreier seg om egenskaper, ISO 9000 definerer kvalitet som “Degree to which a set of inherent characteristics fulfills requirements”. Requirements, eller krav, er i denne sammenhengen behov eller forventninger man har til løsningen.

Men hvilke behov og forventninger har man egentlig til løsningen? Og vil ikke disse variere fra person til person? Jeg synes Gerald Weinberg har satt ord på en veldig fin definisjon av kvalitet: “Quality is value to some person.” Dette er en enkel definisjon som er lett å huske.

For å levere kvalitet må man finne ut av hvem som er interessenter i løsningen det er snakk om og hva som gir verdi for disse personene.

Børge Bardo

Kvalitet for meg er at systemet oppfyller det kravene sier og samtidig gir en merverdi for kunden. Systemet må kunne brukes på en effektiv og hensiktsmessig måte av brukere. Det oppfyller ikke-funksjonelle krav som er viktig for forretningen slik at systemets funksjonalitet er tilgjengelig når det skal.

Systemet er lett å endre og utvide med ny funksjonalitet i takt med endrede og nye krav. Er lett å skrive tester og har allerede tester som beskriver systemets oppførsel. Det er skrevet på en måte som gjør at det er lett å sette seg inn og at jeg blir i godt humør når jeg leser koden.

Øyvind Kvangardsnes

Kvalitet! Alle vet hva det er, men vi har stooore problemer med å forklare hva det faktisk betyr. Det er jo fordi uttrykket ikke på noen måte er entydig.

I mitt hode er kvalitet den gode følelsen man får når noe bare funker. “Noe” og “funker” er operative ord; betydningen avhenger 100% av hvem man er og hva man snakker om.

Når vi lager programvare, så er det mange som bryr seg om kvaliteten.
Hva de bryr seg om varierer; stikkord kan være brukervennlighet, responstid, kodelinjer, time-to-market, internpolitikk, driftbarhet, ressursbruk, logging osv.

De bryr seg om hva, eller hvordan, eller hvorfor.

Jeg vil levere kvalitet! Når de som bryr seg sier “det funker bra”, så vet jeg at jeg er på sporet

Torstein Nicolaysen

Kvalitet er en følelse og opplevelse.
Du vet ikke nødvendigvis om den er der, men du merker om den mangler. Det er noe som er lett å kjenne igjen, men vanskelig å definere.

Kvalitet er vanskelig å skape, og kan kun skapes gjennom fokusert og dedikert arbeid av noen som er bevisst, kunnskapsrik og lidenskapelig opptatt av håndverket sitt.

Resultatet er noe som fungerer slik det skal – og ofte litt bedre. Det er prikken over i-en som vi forventer skal være der.

Det er det som gjør jobben morsom. Det er det som gjør kunden fornøyd. Kvalitet er det vi leverer når vi presterer som best!

Bent Kristiansen

Kapasitet, ytelse, brukervennlighet, stabilitet og tilgjengelighet er viktige kvalitetsfaktorer.

Kvalitet er avhengig av “interessehaver”. IT-systemer har ofte mange interessehavere/kravstillere, som igjen har forskjellige kriterier for hva de opplever som kvalitet. For sluttbruker er kvalitet Look and feel, respons og at de finner enkelt fram. For driftsansvarlige er kvalitet blant annet gode systemlogger med korrekte loggnivå, slik at det umiddelbart kan tas tak i eventuelle kritiske feil som oppstår.

Kvalitet er tidsavhengig. Endringer i funksjonsbehov og infrastruktur, samt trender gjør at system kan bli utdatert på kort tid. At systemet er godt dokumentert gjennom funksjonelle tester og enhetstester gjør at det er fleksibelt i forhold til videreutvikling.

I’m convinced this isn’t just a fad, and we’re on the brink of a revolution in the software industry – a paradigm shift in which developers and sysadmins start to work together, to train each other, and ultimately to blur the boundary – welcome to the world of the Devop.

Så vi snakker også om en Devop, som en rolle? Gjerne for meg, men da som tillegg til et begrep som handler om det å få kontroll over og kvalitet på utrulling og drift. Det er ihvertfall det jeg ønsker å legge i det.

Det hadde gjort seg med en norsk oversettelse. Noen forslag?

• tid/resurser: man lägger tid på något som kan automatiseras
• kompetens: om den personen försvinner som sköter deploy, vad gör man då?
• dokumentation: den uppdateras inte ordentligt och det är svårt att förklara allt i detalj, med ett enklare dokument som beskriver en enklare process är det betydligt mer värdefullt
• pengar: allt ovan tillsammans gör att man har en process som snarare blir en belastning än stärker organisationen.

Så hur sätter man då upp en agil web-deployprocess i .Net? Resten av denna post kommer ge dig en enkel men grundläggande beskrivning hur du får till en smidig web-deployprocess i .Net med web deploy 2.0 och slutligen automatiserad med Teamcity. Den målbild vi är ute efter är följande:

Det är en rätt så rakt fram uppsättning. Man har utvecklare som sitter på utvecklingsdatorer som kommunicerar med den källkodsmiljö man har som t.ex. git eller TFS. Når en utvecklare pushar kod till källkodskontrollen så triggar det ett bygg på byggservern som då hämtar senaste versionen. Om bygget går bra, dvs. det bygger och de testar man har definierat går bra, så deployar byggservern till den miljö som koden var avsedd för.

Det är sex steg som vi kommer gå igenom för att få detta på plats:

1. Web deploy 2.0 och IIS 7
2. Projektspecifika inställningar
3. Config-transformationer
4. Att bygga ett deploypaket
5. Deploy av ett deploypaket
6. Konfigurering av Teamcity för kontinuerlig deployment

Web deploy 2.0 och IIS 7 konfigurasjon

Denna post fokuserar bare på deploy till IIS 7 och som verktyg för att göra utföra deployen kommer Web deploy 2.0 (Web deployment tool) från Microsoft att användas. Detta må man göra på de servrar man vill göra en deploy till, men när det är konfigurerat så ska man inte behöva göra så mycket mer efter utom eventuellt sätta skapa en eller annan site.

Följande checklista är det som ska göras för Wen deploy 2.0 och IIS 7.

• Installera Web deploy 2.0 från http://www.iis.net/download/webdeploy.
• Aktivera “Web Service Management” (detta gäller för Windows 2008) genom att gå till “Control Panel\All Control Panel Items\Programs and Features” och sedan “Turn Windows features on or off” för att där aktiver “IIS Management Serivce” enligt bilden nedan.

• Starta “Management Service” (detta gäller för Windows 2008) genom i “Internet Information Services (IIS) Manager” markera den server som du vill deploya till. Där klickar du på “Management Service” under “Management”-kategorin. Inne på “Management Service” så startar du servicen och registrerar vilken port den kör på.
• Gå sedan in på “IIS Manager Users” som också ligger under “Management”-kategorin och skapa dig en deployanvändare. Denna användare är den som kommer användas vid deploy till servern, notera att den inte behöver vara en windows- eller AD-användare.
• För att ge våran deployanvändare rättigheter så går man in på “Management Service Delegation” under “Management”-kategorin. Där väljer man “Add rule…” templaten man ska använda är vanligtvis “Deploy Application with Content”. De inställningar jag skulle lägga till är följande:
• Under “Providers” skulle jag lägga till: createApp och setAcl
• “Run As”: där skulle jag sätta en faktiskt windows- eller AD-användare som man skapat för att göra deploy till servern.
• I nästa steg så lägger du till den “IIS manager” som du skapade tidigare.
• För att ge våran användare som vi skapat rättigheter att göra något med en site så måste vi lägga till den till en site. Så istället för att ha IIS severn markerad till vänster så expanderar man “sites” och väljer den site man vill deloya till. När siten är valt så går man in på “IIS Manager Permissions” och lägger till sin användaren som man skapat.

Det var allt vi behöver göra för att installera Web deploy och konfigurera IIS.

Projektspecifika inställningar

Det är inte mycket man behöver göra på projektnivå, men det är en sak som är relativt viktig och det är att definiera default värden för vart din applikation ska deployas när man väl gör det. Genom att högerklicka på din applikation i Visual Studio och välja “Properties” och sedan “Package/Publish Web” så hittar du ett fält som heter “IIS Web site/application name to use on the destination server”. Här definierar du vart du vill deploya din applikation i olika scenarior som test, stage och produktionsbygg t.ex. Helt enkelt en inställning per byggkonfiguration. Det går vid senare tillfälle definiera att man vill göra en deploy till ett annat ställe, men man bör sätta dessa så korrekt som möjligt.

Config-transformationer

Visual Studio 2010 kommer inbyggt med stöd för att enkelt transformera Web.config för ett projekt. När du skapar att MVC projekt till exempel så skapas det med en Web.config fil samt två transformationsfiler som heter Web.Debug.config och Web.Release.config.

Transformationsfilerna kommer användas när du gör en deploy med ett deploypaket, notera att transformationerna inte görs när du bygger ditt projekt. Att skapa dessa transformationsfiler är relativt enkelt och det går att läsa om de olika transformationerna du kan göra här: http://go.microsoft.com/fwlink/?LinkId=125889.

Att bygga ett deploypaket

Det finns två sätt att bygga deployment paket på, genom Visual Studio 2010 som är en trivial uppgift och genom att använda sig av msbuild vilket är lite mer komplicerat men som vi måste lära oss om vi vill göra en deploy från en byggserver som Teamcity.

Att bygga ett deployment paket i Visual Studio 2010 kan inte bli enklare än det är. Du högerklickar på den webapplikation som du vill bygga och väljer “Build Deployment Package”. Visual Studio kommer då att bygga ett deploypaket åt dig för den konfiguration som är vald. När du bygger dit deploypaket så skapas en “Package”-katalog under “<project dir>\obj\<build configuration>”. “Package”-katalogen innehåller följande:

• PackageTmp – en temporär katalog som innehåller resultatet av bygget innan det skapas ett deploypaket av det.
• <project name>.deploy.cmd – som är ett färdigt exekverbart script du kan använda dig av för att göra en deploy.
• <project name>.zip – det paket som du kan installera.
• <project name>.SetParameters.xml – om du har definierat parametrar för ditt paket så kan du sätta de här (går inte igenom detta i den här blogposten)
• <project name>.SourceManifest.xml – definierar uppgifter som ska göras när du gör själva deployen, t.ex. sätta rättigheter (går inte igenom detta i den här blogposten)

Att bygga ett deployment paket med msbuild är inte så mycket mer komplext egentligen, men den genomsnittliga .Net-utvecklaren är kanske lite rädd så fort man ska börja använda sig av en konsollapplikation så hoppas följande triviala rad visar på att det inte är så komplicerat. Så det man behöver göra för att bygga ett deploymentpaket med msbuild är att köra följande:

msbuild <project name>.csproj /T:package /P:Configuration=<Configuration>

Parametrarna som används definierar att vi vill köra en msbuild target som heter “Package” som bygger själva deploymentpaketet och sedan definierar den andra parametern vilken konfiguration vi vill använda oss av när vi bygger, t.ex. Debug eller Release. Samma typ av filer ska skapas av det kommandot och de lägger sig på samma ställe.

Nu när vi vet hur man bygger ett deploypaket är nästa steg att utföra själva deployen.

Deploy av ett deploypaket

Deploy går att göra på fyra olika och enkla sätt

• Direkt i IIS,
• Direkt i Visual Studio,
• Genom att exekvera den körbara fil man fick när man byggde paketet,
• Genom att exekvera ett msbuild kommando som bygger och gör en deployment.

Att installera ett paket i IIS är trivialt. I IIS Manager så högerklickar du på den site som du vill göra din deploy till och väljer “Deploy->Import Application…”. Då får du en dialog där du ska leta upp den zip-fil som skapades när du byggde ditt deploymentpaket. Sen ska det bara vara att klicka next och finish. Detta sätt att deploya på är bra om man eventuellt inte har direkt tillgång till servern som man ska göra deploy till, då kan man bara leverera det som ska deployas till en som har rättigheter så gör han uppgiften.

Att göra en deploy från Visual Studio är i stort sett lika enkelt som att göra det direkt i IIS. I Visual Studio så högerklickar du på det webprojekt som du vill göra en deploy av och väljer “Publish…”. Här ska du fylla i de uppgifterna vi satte upp i IIS, dvs. service URL, vart vi ska göra våran deployment och den IIS användare som vi definierade IIS. Du kanske behöver kryssa för “Allow untrusted certificate” och antagligen så vill du kryssa för “Mark as IIS application on destination”.

Att använda sig av den exekverbara filen man fick när man byggde sitt deployment paket är ett enkelt sätt att göra en deployment på. Om du befinner dig på servern och har kopierat allt i den “Package”-katalog som skapades så är det enda du behöver köra om du står i “Package”-katalogen följande:

<Project name>.deploy.cmd /y

Så mycket enklare än det kan det inte bli, men tyvärr är vi inte klara. Om vi skulle vilja göra en deploy till en annan server behöver vi ange lite mer information så då ser vårat kommando ut ungefär så här:

<Project name>.deploy.cmd /y "/M:<Deploy server>?site=<site name>"
/u:<IIS user>
/p:<IIS user password>
-allowUntrusted /A:basic

Notera att det är citat-tecken runt server- och siteparametrarna, detta är för att annars så splittas parametern upp på “=”. När detta brukas i Teamcity så behöver man ha dubbla citat-tecken av någon anledning. En sak till är att om man försöker göra en deploy till en site som inte är default i applikationen så behöver man eventuellt gå in och ändra till rätt site i filen <project name>.SetParameters.xml.

Men för att göra det ännu enklare på våran byggserver så ska vi istället använda oss av msbuild för att göra deploy, vilket gör att vi kommer göra både bygg av deploypaket i samma steg. Det msbuild kommando man behöver är följande

msbuild <project name>.csproj /P:Configuration=<configuration>
/P:DeployOnBuild=True
/P:DeployTarget=MSDeployPublish
"/P:MsDeployServiceUrl=<your deploy service>?site=<your site>"
/P:AllowUntrustedCertificate=true
/P:MSDeployPublishMethod=WMSvc
/P:CreatePackageOnPublish=True
/P:UserName=<your IIS user>
/P:Password=<your IIS user password>

Det är många parametrar men alla är väldigt tydliga med vad de gör. Att vi har allt i ett kommando gör nu när vi ska konfigurera upp Teamcity att vi får ett byggsteg mindre än om vi haft det i två olika delar.

Så då när vi nu har definierat det kommando som vi behöver för att göra en automatisk deploy från Teamcity är det dags för det sista steget.

Konfigurering av Teamcity

Jag kommer enbart fokusera på hur man gör deploy från Teamcity, jag räknar med att läsaren redan vet hur man triggar ett bygg på check-in av kod eller liknande.

Det första vi gör är att definiera ett antal byggparametrar enligt figuren nedan.

Som du ser är detta parametrarna som användes i sista exemplet på hur man gör en deploy. Det underlättar om du definierar de som system parametrar då msbuild scripten i byggkonfigurationen använder sig av de parametrarna automatiskt. Det tar oss till nästa steg, när du har definierat alla de byggparametrarna så skapar du ett bygg steg inställningarna enligt bilden nedan om du använder .NET 4.0. Givetvis så är det bra om du anger ett namn på konfiguration och sökvägen till den csproj-filen för den webapplikation som du ska bygga.

Ett sista steg om du vill enkelt ska kunna ladda ner det deploypaket som skapades är att lägga till en artifakt under “General Settings”. Sökvägen man ska lägga till är den till din “Package”-katalog, vilket borde vara något i stil med:

<Path to project>\obj\%build.configuration%\Package

“Path to project” är den sökväg som du har till projektet när byggservern har checkat ut koden.

Att vi har allt i parametrar gör det väldigt enkelt att skapa en ny konfiguration för att göra en deploy till en annan server eller site, allt du behöver göra är att kopiera konfigurationen och sedan ändra de parametrar som behöver ändras.

Avslutning

Det var alla steg som man behöver göra för att få upp en relativt automatiserad process för att deploya dina webprojekt. Web deploy 2.0 har mycket mer funktionalitet än det som gåtts igenom i denna blogpost, men detta borde få dig att komma igång med automatiseringsprocessen. Om du vill lära dig mer om hur du till exempel sätter rättigheter på kataloger eller ändrar värden i registret så rekommenderar jag följande två blogginlägg:

Modifying directory permissions with Web Deployment – http://leethams.wordpress.com/2010/06/12/modifying-directory-permissions-with-web-deployment/
How to extend target file to include registry settings for web project package – http://blogs.msdn.com/b/webdevtools/archive/2010/02/09/how-to-extend-target-file-to-include-registry-settings-for-web-project-package.aspx

Min generelle oppfatning er at løsninger blir stort sett bedre, hverdagen enklere for både drift og programmerer, og applikasjonene mer driftbare når også programmerere har ansvar for produksjon.

Erfaringen min peker på at ingen tilgang bidrar til:

1. Manglende fokus på driftbarhet og automatisering

Ansvarsfølelsen for produksjon blir lav til forsvinnende blant oss programmerere. Jeg har hørt utviklere oppriktig si “jeg er ferdig når det er i QA, PROD er ikke mitt ansvar”. Om det kommer massive ytelsesproblemer og bugs i produksjon – hvor koden faktisk brukes – betyr det ikke så mye. Jeg har sett logger i applikasjoner bli dårlige til ubrukelige. Alt eller ingenting logges. Det lages heller ingen monitorerings- eller diagnoseverktøy (f.eks. fordi vi ikke får tilgang til å bruke dem uansett). Og utrulling forblir basert på manuelle rutiner.

2. Færre releaser og lengre tid til markedet

Når det er så tungt og vanskelig å utføre prodsetting, så er det lettere å utsette releasene. Dette fører igjen til enda større kompleksitet og risiko for feil. Det inntreffer gjerne astronomiske problemer når det først releases. Drift igjen får en aversjon mot releaser, og optimaliserer for å slippe dem.

3. Økt responstid for feilretting (bugs)

Økt kommunikasjonsoverhead betyr at det tar lengre tid å finne ut hva som skjer… Samarbeidet blir tyngre og iblant må vi tilogmed (både drift og utvikling) streve for at det ikke skal surne helt til. Utviklere blir masekoppene, som tror de vet bedre; drift blir de som ikke svarer, ikke bryr seg, osv.

= Mindre forretningsverdi

Dette oversetter ganske direkte til dårligere kvalitet*, tapte muligheter og tapte inntekter/økte kostnader. (* lavere kvalitet betyr økte kostnader, tap av brand value, osv.)

Jeg tror verken systemadministratorer eller programmerere er særlig interesserte i å ha det slik. Vi vil heller ha bra og enkle systemer å drifte, levere ny forretningsverdi og gjøre kunder og brukere fornøyde, og ha et bra samarbeid.

OK. Det finnes alltid et unntak her og der. Noen systemer har blitt lappet sammen med tape, plaster, sysaker og endel kreativ tenking (fra både utvikling og drift). Disse klapper gjerne sammen om en leser av en logfil. Der kan det godt gjelde “if it ain’t broken, don’t fix it” (med mindre det -må- fikses). Heldigvis jobber jeg ikke så ofte med slike systemer. De siste fire årene har jeg utelukkende jobbet med systemer som endrer seg hver dag og støtter stadig endrende markeder og forretningsprosesser.

Kunnskap

Argumentet “hvis utviklere slipper til øker sjansen for å rote noe til” synes jeg er noe billig. Jeg bestrider heller ikke at det skjer at utviklere klarer å rote ting til på aldeles grufulle måter. Jeg har da sannelig også erfart at driftere har rotet ting til royalt. Det er naturligvis sant at vi kan rote ting til om vi jobber med prod, vi er jo bare mennesker, men problemet er mye mer komplisert. Vi kan være enige i at vi i begge leirer har ulike nivåer av kompetanse innen forskjellige felter. Noen trenger mer tilsyn og hjelp enn andre, det er allikevel ikke det som er kjernen.

Stort sett så handler det om endring vs. stabilitet

I dag er IT-systemer såpass tett integrert i forretningsprosessen til bedrifter at de ikke kan endre på det ene uten det andre. Eller i andre ord: endringer av IT-systemer er viktig for endring av bedrifter og omvendt. Kanskje gjelder dette spesielt i store bedrifter (eller store statlige etater).

En stor hindring for driftssiden er naturligvis avtalene som idag brukes. De er ofte rettet mot stabile systemer (SLA-mål), og ikke endrende systemer. Det er naturlig at om jeg skulle ta på meg drifterhatten så ville jeg vært ganske skeptisk til å la Per Programmerer få gjøre hva han ville så lenge det ikke har noen konsekvenser for Per, men jeg mister masse driftsinntekter på grunn av nedetiden han skapte.

Alle mine erfaringer tyder også på at endringer betyr problemer. I en ideell verden ville aldri systemer (forretning eller IT) endre på seg og ingenting vil feile. Systemadministrasjon (drift) ville da være ganske enkelt. Det vil ikke være behov for å finne ut hvorfor noe skjedde feil med siste endring. Og det vil ihvertfall ikke haste å fikse problemene. Dessverre er virkeligheten kompleks. Å hindre programmere tilgang til produksjon er i beste fall å angripe symptomet; ikke årsaken.

Samtidig er tilgang alene naturligvis ingen sølvkule.

Felles ansvar gir også bedre samarbeid

Tilgang til produksjon må også medføre økt ansvar for produksjon. Vi må som programmerere slutte å ta snarveier og lære å administrere systemene vi utvikler. Hvis ikke vi klarer det selv, hvordan kan vi forvente andre skal kunne det? Samtidig som jeg synes det er utopisk å tenke at alle programmerere kan drifte systemer, synes jeg det er en like stor utopi å tenke at alle systemadministratorer / applikasjonsdriftere kan løse driftsproblemene alene. (Det finnes naturligvis noen få systemadministratorer/appdriftere med programmeringskunnskaper, og programmerere med appdrift/systemadministrasjonskunnskaper – vi kan se bort fra de nå, det er ikke alle som er heldige nok å ha den kombinasjonen i teamet sitt). Jeg tror dessverre at utviklere ikke vil lære mer om driftbarhet om de ikke jobber med det og ser hvor mye dritt applikasjonene klarer å produsere. Hvis programmerere ikke får lov å jobbe med det, kan kanskje heller ikke drift forvente særlig driftbare applikasjoner? En fin og svært enkel tilnærming å få til bra samarbeid og læring på kryss av drift/utvikling er… Wait for it… Å integrere systemadministrasjon/programmerere (drift/utvikling)!

Arbeide sammen… daglig

Sitte sammen, løse problemer sammen daglig. Det både høres enkelt ut og er igrunnen ganske enkelt. Til tross for svært gode resultater de gangene det gjøres, så er det min erfaring at det skjer alt for sjeldent. Når vi sitter sammen kan vi få til ekte læring, forbedring og innsikt. Bestillingsdokumentregimet, e-post, og et sjeldent møte eller telefon nå og da er i mitt syn en ganske ineffektiv form for kommunikasjon.

Min erfaring fra stor statlig etat var at det dessverre var litt for sjeldent (men ikke aldri!) at vi jobbet driftere og utviklere sammen for å løse felles problem. Normen var nettopp bestillinger, eskalering av bestillinger, e-post, purring på e-post, telefon, oppgitt telefon… Etter hvert gikk det så langt at vi måtte ta et møte – plutselig flyttet vi fjell og løste all verdens av problemer.

Spesielt når det handler om kommunikasjon av svært komplekse problemstillinger er det lett å misforstå, anta ting feilaktig, og det er lett at dårlig stemning oppstår.

Vi samarbeider mye mer og bedre med drift der jeg jobber nå. Det fungerer, selv om det ikke er helt daglig – enda. Vi (utviklere) har samtidig full tilgang til produksjon, og får lov å prodsette selv. Det er naturligvis en iboende risiko til at vi vil rote det til skikkelig; vi har klart oss bra og nærmer oss snart hundre releaser. Samtidig er det vi som får SMS og epost først når feilene kommer. Vi har mange mål for kvalitet, et er å alltid være tilgjengelig, et par andre, mer gjennomførbare er å aldri vekke noen på natta og å ikke få en eneste telefon etter en prodsetting. For å få dette til må vi alle være ansvarlige for å holde applikasjonene kjørende i produksjon.

Til slutt for å ta bilanalogien: Jeg bygde Ferrarien – ihvertfall motoren, kjørecomputeren og styringssystemet. Jeg integrerte også med stabilitetssystemet, bremsene, airbaggene, lysene, tenningssystemet og girkassen. Jeg var med å passe på at det hele passet inn i chassiset og tilpasset sammen med designerne de øvrige komponentene. Hvis jeg skal finne ut hvorfor den plutselig stoppet i tunnellen på E18 da det var 19 grader i lufta ingen kø, så holder det ikke å få tilsendt bilder av motoren eller kjørecomputeren… Selv om jeg kanskje ikke kan så mye om veier og vær, så tror jeg det er enklere om jeg får se på motoren og finne ut hvordan den ble brukt da det skjedde framfor å studere bildene.

Eller kanskje bedre, for å parafrasere min kollega, Jonas, sin kortere versjon: “å fikse motoren via e-post er som å fikse motoren gjennom eksosrøret”.

(Kunne naturligvis også løst det til en viss grad ved å investere masse penger på å bygge et digitalt diagnosesystem med masse sensorer som tok opp relevante data via kjørecomputeren, og få tilsendt dette, men da snakker vi F1-Ferrari…)

I kapittel 31 – Don´t Touch That Code, hevder forfatteren at utviklere ikke skal fikse feil i produksjon, og at dette bør forhindres ved at utviklere ikke gis tilgang til noe annet enn utviklingsmiljøet. Nærmere bestemt:

… a developer — even a senior developer — should never have access beyond the development server

og

Under no circumstances — ever, at all — should a developer have access to a production server.

Det er fornuftig at feilretting ikke bør skje direkte i produksjonsmiljøet. Selv har jeg imidlertid aldri opplevd dette, og har ikke intrykk av at dette utgjør et stort problem i de fleste utviklingsprosjekter. Derimot har man mange andre utfordringer, og en del av disse kan løses bedre nettopp ved å la utviklerne ha tilgang.

Feilanalyse

Ved daglig drift kan det oppstå feil eller andre hendelser som man har lyst til å se nærmere på. I slike tilfeller er det viktig å ha gode logger og at utviklerne har rask og enkel tilgang til disse. Dette er enklest å oppnå ved at utviklerne har direkte lesetilgang til loggene. Dersom man har en politikk som ikke tillater dette, ender man gjerne med lange og tidkrevende epostvekslinger mellom utviklings- og driftspersonell for å få tak i loggene det gjelder, noe som er tungvint og irriterende for alle parter – spesielt dersom det er snakk om kritiske feil der tidsfaktoren er viktig.

Monitorering

Loggene kan også benyttes til å gjenskape feilsituasjoner og/eller monitorere feilsituasjoner “live”, noe som kan være en svært effektiv og nyttig fremgangsmåte i gitte situasjoner. Slik oppfølging blir ofte enklere og mer fleksibelt dersom man har bygget applikasjonen slik at logginnstillinger og eventuelle andre parametre kan justeres mens applikasjonen kjører. Slik monitorering og justering er det utviklerne, som kjenner applikasjonen som sin egen bukselomme, som bør gjøre. Hvis utviklerne ikke har live tilgang til miljøet, nekter man seg i praksis et viktig verktøy ved feilsituasjoner.

Administrasjon og støtteverktøy

Ofte kan støttefunksjoner til en applikasjon være nyttige, enten det er operasjoner som er del av daglig drift eller ad-hoc-funksjoner som kan være nyttige ved spesielle situasjoner. Eksempler på dette kan være automatisk monitorering og varsling basert på logg-data eller interaksjon med applikasjonen som f.eks. invalidering av cache eller av-/påslåing av funksjoner på gitte tidspunkt. Mange slike støttefunksjoner kan utføres ved enkle kommandolinjescript. Igjen er det ofte utviklere som er best egnet til å lage slike støttefunksjoner, spesielt av ad-hoc-art, da det er de som best vet hvikle muligheter man har i applikasjonen.

Utrulling

Applikasjonsutrulling er også et område der utviklere kan spille en viktig rolle. Utviklere gjør gjerne utrulling på lokal maskin flere ganger daglig, og kjenner dermed denne fasen bedre enn noen. De er også ofte de som er best skikket til å forenkle, forbedre og automatisere denne prosessen.

Å arbeide for å forbedre kommunikasjon, samarbeid og forståelse mellom utviklings- og driftsorganisasjonene kan være veldig nyttig og givende i mange prosjekter. Nærhet og samarbeid mellom utvikling og drift kan ofte være av avgjørende betydning for smidighet både ved utrulling av applikasjoner og ved oppfølging og overvåkning av daglig drift. DevOps er et uttrykk som er mye i vinden om dagen, og som fokuserer på nettopp dette. Artikkelen DevOps: What It Is, Why It Exists and Why It’s Indispensable gir en fin introduksjon til DevOps.

Utviklere bør altså ikke gjøre bugfixer i form av kodeendringer, omkonfigurering av programvare eller denslags direkte i produksjon. Dersom dette er et problem, bør det kunne forhindres — for eksempel ved noe så enkelt som rettighetsinnstilling på brukerne. Det er naturligvis ikke slik at utviklerne fullstendig skal ta over produksjonsmiljøet, men man gjør seg selv en bjørnetjeneste dersom man ikke benytter seg av den applikasjonsspesifikke ekspertisen utviklerne bestitter — også ved kjøretid i produksjon.

Identifiser situasjoner hvor manuell verifikasjon gjøres i dag

Vi ønsker eksempelvis å vite om eksterne og interne avhengigheter er på plass, og at det ikke har oppstått åpenbare systemfeil når utvikler setter opp et utviklingsmiljø, ny kode distribueres til et test eller produksjonsmiljø, eller når forvalting kontaktes i forbindelse med systemfeil. Disse tre situasjonene forklares mer deltajert nedenfor.
Oppsett av utviklingsmiljø
Når utviklere setter opp hvert sitt utviklingsmiljø verifiseres det at oppsettet er i orden ved å:

• Kjøre enhetstester, integrasjonstester og akseptansetester
• Manuelt teste hovedfunksjoner i en eller flere applikasjoner/nettsider

Distribusjon av kode til test eller produksjonsmiljø
Når ny kode er distribuert til et miljø, gjør man vanligvis verifisering ved å:

• Manuelt teste hovedfunksjoner i en eller flere applikasjoner/nettsider
• Manuelt teste ny funksjonalitet

Forvaltning
Når det kommer henvendelser om systemfeil til brukerstøtte eller driftsansvarlige, gjøres ofte feilsøking ved å:

• Manuelt teste en eller flere funkjsoner i systemet
• Kontrollere systemloggen

Manuell verifikasjon i situasjonene beskrevet ovenfor er tidkrevende og kan være vanskelige å utføre.

Hvordan gjøre automatisk miljøverifikasjon?

I BEKK har vi god erfaring med å lage skript, nettside og/eller applikasjon som sjekker avhengigheter og funksjoner i et IT-system.

Skript

For å verifisere et miljø i forbindelse med oppsett eller installasjon kan det være bra å lage et skript som returnerer resultat fra verifiseringen uten å vise det visuelt. Skriptet startes helt til slutt etter bygg og deploy er utført. Dersom noe i miljøverifiseringsskriptet feiler, returneres en feilkode, og mer detaljert feilmelding logges. Skriptet bør lese konfigurasjonsfiler til tjenester og konfigurasjonsfil for eventuelle klienter som distribueres, etter distribusjon. Da får vi kontrollert at det ikke er feil i kode som bygger konfigurasjonen under distribusjon til de forskjellige miljøene.

Nettside

Skal man verifisere et kjørende miljø for en internett- eller intranettløsning er det bra å ha en side som kjører forskjellige tester i løsningen, og som viser resultatet visuelt. Adressen til siden gir man til interesserte som har behov for den, som: testteamet, systemadministrator, superbrukere, support og drift. Siden bør tilgangsstyres.

Applikasjon

Hvis systemet har distribuerte klienter anbefaler vi at det distribueres en egen applikasjon for diagnose, eller at det settes opp et menyvalg under hjelp-menyen som starter systemdiagnosen (dersom man har autorisasjon).

Det er essensielt at innstillinger og endepunkter leses fra klientens konfigurasjon. Diagnose-applikasjonen bør kjøre i samme brukerkontekst som den distribuerte klienten.

Hva kan/bør verifiseres på denne måten?

Egentlig er det ingen grenser for hva man kan verifisere på denne måten, men ikke gjør det for avansert. Da blir det vanskelig å vedlikeholde. Miljøverifikasjon skal ikke erstatte systemintegrasjonstester eller akseptansetester.

Verifisering av tjeneste-endepunkt til eksterne og interne tjenester, databasetilkoblingsstrenger og noen basis-operasjoner er tilstrekkelig, og svært nyttig etter vår erfaring.

Noen regler:

• Miljøverifikasjon bør gjøres så enkelt som mulig
• Miljøverifikasjon bør ikke ta lang tid å kjøre (<1 min)
• Vurder å benytte tråder (for å få raskere total responstid)

Start med å få på plass sjekk om én tjeneste svarer, for å komme i gang. Legg til mer etterhvert. Det kan være en god idé å inkludere løsning på kjente feilsituasjoner, slik at feilsøking går fortere.

Hva er dine erfaringer?

Hva er dine erfaringer med verifisering og feilsøking i forbindelse med oppsett og distribusjon av kildekode til ulike miljøer?

You can see the talk here:

The rest of the videos from NDC is available at NDC’s agenda page.

Ved å innføre virtualisering av utviklingsmiljøet så oppnår man en rekke fordeler. Det er på tide å ta utviklingsmiljøet et hakk videre.

Hva

Virtualisering av utviklingsmiljøet innebærer å pakke avhengigheter som database, appserver etc. inn i en virtuell maskin. Denne virtuelle maskinen kan man sette opp slik at den etterlikner produksjonsmiljøet ned til de minste detaljer. En av de store fordelene her er operativsystem i produksjonsmiljøet. Mange utviklere sitter på enten OS X eller Windows, og deployer til *nix-baserte servere.

De aller fleste utviklingsprosjekter har en eller flere eksterne avhengigheter, det være database, eksterne tjenester, LDAP, applikasjonsservere etc. Selv om vi som utviklere prøver å unngå det, så avhenger også kodebasen som oftest av spesifikke versjoner av en eller flere avhengigheter. Disse avhengighetene kan man få samlet i en pakke.

Hvorfor

if (!produksjonsmilø.equals(utviklingsmiljø)) { throw new EnvironmentException("#fail!");}

Hvor mange mennesker kan si at de aldri har hatt en bug i produksjon som de ikke klarte å gjenskape på det lokale utviklingsmiljøet?

cost_of_change = Developers.all.count * time_spent_doing_pointless_task * hourly_rate

Hvor lang tid bruker en ny utvikler på teamet for å sette opp utviklingsmiljøet? Hvis man driver forvaltning på flere prosjekter samtidig, hvor lang tid bruker man på å bytte mellom de?

Hva gjør du når harddisken kræsjer på utviklingsmaskinen? Hvor lang tid bruker du på å installere f.eks. ruby (i riktig versjon), maven, database, sette opp riktige miljøvariabler etc. Ca. én arbeidsdag er vel ikke helt utenkelig.

Vi introduserer bugs i koden hver eneste dag, og det å oppdage disse tidlig er svært viktig. Hvis man har en lang utviklingssyklus og det tar lang tid før en feature er i produksjon kan det fort bli dyrt å rette en bug som ble innført for flere uker siden.

Fordi vi liker å finne bugs tidlig har mange av oss blitt glad i enhets- og integrasjonstesting, samt at de aller fleste prosjekter benytter seg av kontinuerlig integrasjon. Kontinuerlig integrasjon er i mine øyne helt uunnværlig, men hvis jeg kan finne en bug FØR den havner i kildekontrollsystemet så vil det være det mest optimale.

Vi kan gjennom dette identifisere noen egenskaper som kjennetegner et godt utviklingsmiljø:

Utviklingsmiljøet bør være:

1. Likt produksjonsmiljøet
2. Likt for alle utviklere på teamet
3. Uavhengig av eksterne systemer (les: systemet bør kunne kjøres i sin helhet på lokal maskin)

I tillegg vil jeg introdusere et par til

4. Oversiktlig
5. Raskt å sette opp for nye utviklere
6. Under kildekontroll

Hvordan?

include 'vagrant'

Mye av dette kan løses med god dokumentasjon, godt oppsatte byggeverktøy og diverse scripts, men når vi helautomatiserer prosessen vil vi oppnå noen klare fordeler.

Inn kommer Vagrant.

Vagrant gjør to ting:

1. Automatisert skripting av virtuelle maskiner
2. Automatisert oppsett/installasjon av ‘avhengigheter’. (kalt provisioning)

Vagrant er pakket som en ruby-gem og er et skript-verktøy/dsl på toppen av VirtualBox og automatiserer import, oppstart og konfigurasjon av virtuelle maskiner.

Vagrant gjør også installasjon av applikasjonsservere, databaser og andre avhengigheter lekende lett ved å inkludere støtte for Chef og Puppet, to verktøy for serveroppsett og konfigurasjonshåndtering.

Synes du (som meg) at Chef og Puppet blir litt tungt å sette seg inn i, er det veldig enkelt å lage sin egen provisioner-plugin og bruke f.eks Sprinkle istedenfor.

Strategy => "#{win}"

For å lage virtuelle bokser kan man benytte følgende strategi.

Ta utgangspunkt i ett basis-image som tilsvarer operativsystemet som du benytter i produksjon. Lag så et vagrant-prosjekt som installerer app-server, database, etc. i riktig versjon. Gjør denne boksen så lik produksjon som mulig. La denne boksen være en “grunnboks” for videre jobbing. Oppsettet på denne boksen skal ikke endre seg ofte. En full gjenbygging av denne boksen vil kunne ta litt tid.

I selve utviklingsprosjektet ditt oppretter du en ny vagrant-boks som baserer seg på “grunnboksen”. Her legger du inn skreddersydd konfig og oppgaver for prosjektet, setter opp deling av mapper, port-forwarding, oppgaver for tømming av database. Denne boksen bør kunne slettes og kjøres opp i løpet av kort tid, så oppgaver som tar lang tid bør legges til grunnboksen, eventuelt i egne tasks.

På grunn av mappedeling kan man fortsette å bruke sin egen editor, og endringene vil gjøres samtidig i den virtuelle maskinen og på verten. Byggeverktøy kan kjøres både i den virtuelle maskinen og lokalt.

“However beautiful the strategy, you should occasionally look at the results.”
 - Winston Churchill

Som i de fleste tilfeller ender vi opp med en liste med fordeler og ulemper:

Fordeler

• Utviklingsmiljøet ligger under kildekontroll og kan gjenskapes ved å kjøre en enkel kommando
• Nye teammedlemmer kommer raskt igang med utvikling.
• Endringer i produksjonsmiljø kan replikeres i utviklingsmiljø, og rulles ut raskt på utviklermaskiner
• Kortere feedback-loop
• Eksterne systemer som f.eks. LDAP trenger ikke mockes
• Åpner for 100% separert kontinuerlig integrasjon for systemer som deler tjenester
• Hvis man allerede bruker Chef eller Puppet til å sette opp prodservere så kan man gjenbruke konfigurasjonen
• Modular oppbygning, så det er lett å lage utvidelser og plugins

Ulemper

• Byggehastigheten går ned hvis bygget kjøres på den virtuelle maskinen. (F.eks. maven tenderer til å være ca 1,5 ggr. tregere når bygget blir kjørt virtuelt)
• Enda en teknologi i prosjektet
• Vertsmaskiner med lite RAM kan bli trege

Tips og triks

Setter man opp ssh-agent forwarding kan den virtuelle maskinen sjekke ut kode fra f.eks. github.

I Java-prosjekter som bruker Maven lønner det seg å sette opp det lokale maven-repoet som en delt mappe.

Vagrant har støtte for å kjøre opp flere virtuelle maskiner i samme prosjekt, og man kan da f.eks. simulere database på en egen maskin. Det åpner også for å teste avansert clustring og fallback-mekanismer lokalt.

Jeg har også laget et lite eksempel på en virtuell maskin for java-utvikling, sjekk ut kildekoden fra github her. Denne inneholder også en enkel implementasjon av en provisoner for Sprinkle. Ellers er dokumentasjonen til Vagrant anbefalt lesestoff, Getting started er et fint sted å begynne.

Ressurser:

• vagrant-java-example
• Getting started
• mitchellh-vagrant
• sprinkle cheat sheet
• vagrant dokumentasjon
• vagrant-rake-plugin

Følg meg på twitter

Etter en del prøving og feiling føler vi at vi har fått opp en relativt stabil og bra «rigg», og har også funnet ut at Grinder er nyttig å ha til mye mer enn ytelsestesting. Så derfor er det tid for erfaringsdeling!

Jeg tenkte å dele denne posten opp i tre deler:

1. Litt generelt om ytelsestesting, Grinder, og hvilke andre “testtyper” man kan bruke Grinder til.
2. Hvordan sette opp en fullt fungerende Grinder-rigg fra scratch
3. En del eksempler på fungerende ytelsestest-script for Grinder.

Før du begynner, så anbefaler jeg deg å klone eller laste ned eksempelprosjektet jeg har lagt ut på github – [Direkte link til ZIP-fil]

TL;DR: for deg som ikke gidder lese mer:

Klon prosjektet fra GitHub

Min mening er at alle har godt av å sette litt fokus på ytelse, selv om du kanskje bare lager et internsystem som brukes av et fåtalls mennesker. De fleste av oss fokuserer på kodekvalitet og brukervennlighet, hvorfor ikke sette av litt tid til ytelse også? Med automatiserte tester kan du lett måle hvordan ytelsen endrer seg over tid (Grinder kan lett integreres med byggesystemer som Hudson for å måle ytelsestrend over tid). Du får også et helt annet forhold til applikasjonen din når du vet hvordan den oppfører seg ved forskjellig last, rett og slett et selvprodusert DDOS-angrep om du vil.

Etter å ha brukt Grinder i flere måneder har vi også funnet en rekke flere bruksområder der vi har kunnet gjenbruke riggen vår, og til en viss grad også ytelsestestscriptene uten videre forandringer:

1. Ren ytelsestesting: Å kjøre i gang en del tråder og la de teste systemet over en viss tid, for så å få ut en rapport med detaljert statistikk fungerer glimrende (heldigvis, siden det var litt av hovedpoenget vårt med Grinder)
2. Stresstesting: Her kjørte vi så og si de samme testene som under ytelsestestingen, bortsett fra at vi gjorde det i en mye større skala. Jeg kan ikke gå altfor mye i detaljer, men la oss bare si at 400mbit/s trafikk ut fra serverclusteret vårt i over en time var «barnemat» for Grinder! (og heldigvis også applikasjonen)
3. Langtidstesting: For å gjøre en såkalt «langtidstest» så tonet vi rett og slett ned aggresiviteten til Grinder drastisk, og lot det stå og surre i tre-fire dager. Grinder er såpass fleksibelt at du kan sette det i gang, for så å bare «kill’e» det og likevel få gode rapporter.
4. Lastbalanseringstesting: Systemene våre er trygt plassert bak BigIP for lastbalansering. I forbindelse med oppsett av dette brukte vi Grinder for å kontrollere at lastbalanseringsalgoritmene og oppsettet fungerte slik vi ville, både med stor og liten trafikk.
5. Avbruddstesting: Vi har gjort flere typer avbruddstesting ved hjelp av Grinder. F.eks kunne vi lett teste hvordan «hot-backup» database-fallback-servere oppførte seg når vi var under stor last og simulerte databasefeil. Vi testet også hvordan maks potensiell trafikk endret seg når vi tok ned en og flere av applikasjonsserverene.
6. Generell hjelp under utvikling: Grinder har også kommet til nytte under utviklingsprosessen, det er alltid nyttig å kunne sette i gang en viss mengde automatisert trafikk mot sin egen maskin når man utvikler ulike deler av løsningen.

Regner med at du er overbevist om at du trenger Grinder nå, så vi hopper rett over på det praktiske.

Riggen av Grinder jeg har tenkt til å vise deg er i stor grad basert på standard Grinder-konfigurasjon, men vi har likevel gjort en del småendringer for å få det mer fleksibelt. Målet med riggen var følgende:

1. Å kunne skrive en rekke ulike test-script som gjør forskjellige ting (f.eks noen som bare fokuserer på ren lese-last, mens andre fokuserer mer på operasjoner som involverer databaseendringer, og igjen andre som inneholder «random» operasjoner for å simulere reell last)
2. Å kunne lage ulike scenarier, som gjør av vi kan kombinere et vilkårlig antall av scriptene nevnt over. F.eks kan ett scenarie være «ytelsestest på QA», mens et annet er «langtidstest uten skriveoperasjoner med innslag av random operasjoner».
3. Å enkelt kunne konfigurere hvor testen kjører, f.eks om den skal gå mot DEV-server, QA-cluster eller localhost.

Illustrasjon av forholdet mellom Scenarier og Script

Jeg har forsøkt å oppsummere strukturen med en liten illustrasjon. På den kan du se litt tydeligere konseptet med scenarier som gjenbruker ferdiglagde scripts, og samtidig setter opp en del konfigurasjon og parametere for dem. Så vi har kort sagt følgende to elementer:

Scenarier:

• Bestemmer hvilke script som skal kjøres i denne testen.
• Bestemmer parametere til scriptene (kan være alt, men rot-URL er et godt eksempel).
• Bestemmer hvor mange prosesser Grinder skal kjøre i gang, og hvor mange tråder hver av disse skal kjøre.
• Bestemmer hvor mange ganger hver tråd i hver prosess skal kjøre hvert script.
• Kan i tillegg konfigurere en rekke andre innstillinger, slik som gradvis opptrapping av trafikken, minnebegrensninger, JVM-parametere, om det skal kjøres mot Console (interaktivt java-program for å styre test-parametere live) osv.

Scripts:

• Inneholder instruksjoner for hvordan en enkelt test skal kjøre
• Kan likevel bestå av flere «tester», f.eks for å skille mellom kall mot ulike deler av systemet gjort i samme test.
• Skrevet i «Jython», dvs python-syntaks med mulighet for å inkludere hva som helst av Java-biblioteker (siden Grinder kjører på topp av JVM’en).

Vi har i tillegg et script kalt sequence.py, som tar seg av å kjøre alle scriptene du vil ha med i scenariet ditt. Dette er en modifisert utgave av et offisielt eksempel fra Grinder-dokumentasjonen. Det finnes også mulighet for å kjøre de ulike scriptene innad i en tråd på en prosess i parallell, men det har ikke vi helt sett behovet for (siden vi uansett kjører så mange tråder i parallell).

Jeg tror jeg kutter forklaringen her, og går heller rett over på eksemplene. Vi liker tross alt kode bedre enn forklaring av kode, gjør vi ikke?

#1: Det klassiske vg-eksempelet

Alle som har vært provisorisk IT-support for diverse familie og slekt har vel over telefon forsøkt å forklare hvordan man pinger vg.no til en forvirret mor eller bestemor. Dette eksempelet er ikke noe bedre, her forsøker jeg å forklare deg hvordan du kan laste http://www.vg.no fra Grinder. Og for å unngå at du ufrivillig DOS’er VG har jeg satt lave verdier for antall tråder og gjennomkjøringer (velger du å øke dem så tar jeg ingen ansvar for hva du måtte få av sinte telefonsamtaler…)

Vi begynner med å lage et scenarie. Hvis du har lastet ned koden og følger med, så ligger det i mappen «scenarier», kalt vg.properties. Følgende er de viktigste delene (i den nedlastbare koden har jeg beholdt alt det andre som følger med i eksempelscenariet til Grinder, så du kan se hva du har av muligheter)
Her er alle variablene med grinder foran predefinerte Grinder-variabler. Vi sier at vi kjører scriptet kalt sequence.py, vi skal kjøre det med en prosess som igjen har fire tråder. Disse trådene skal kjøre scriptet totalt fem ganger hver. Barneskolematte her nå: hvor mange ganger kjører scriptet? Take your time, jeg venter… … … 1 x 4 x 5 = 20 ganger. Ikke så vanskelig det vel?

Scriptet sequence.py tar tak i alle variabler scriptXXX, og kjører hver og en av dem. Her har vi bare ett script, så da kjøres bare det, men vi kunne fint lagt på «script2=t002dagbladet». Legg merke til at vi ikke har med filendelsen her!

Vi lager deretter scriptet vårt, t001vg.py, og legger det i mappen «src». Følgende superenkle kode gjør kallet mot vg.no:

Import-statementene skjønner du sikkert, de to neste linjene er der for at sequence.py skal kunne kjøre dette scriptet, og de tre siste linjene er den «virkelige koden vår». Her lager vi en test, med et testnummer (siden dette scriptet er test 001, og vi gjerne vil kunne ha flere «undertester» i ett script, så nummererer vi testen 101, altså test #1 undertest #01. Trust me, du vil se fordelen med dette senere!). Vi gir den et enkelt navn også. Så lager vi en HTTPRequest, som vi wrapper i testvariabelen vår. Dette gjør at vi får Grinder til å instrumentere dette for oss. Til sist bruker vi denne wrappede requesten til å gjøre et GET-kall mot http://www.vg.no.

For å kjøre denne herligheten bruker du kommandolinja. Jeg har laget et lite script for deg, kalt /bin/startAgent.sh . Er du så uheldig at du sitter på windows, så får du lage deg et eget script – det er relativt ukompliserte greier, så tipper du klarer det fint Scriptet tar inn en parameter: navnet på scenariet. Så stå i rotkatalogen vår, og kjør følgende kommando:

./bin/startAgent.sh vg

Når dette har surret og gått seg ferdig, så kan du se resultatene i mappen «log». Her har du to filer, data… og out… I den første finner du hele datagrunnlaget for alle testene som er gjort, men dette har du sannsynligvis ikke lyst til å se på selv (med mindre du er en excel-ninja). Filen out… er mye mer interessant. Her kan du se all output fra scriptene som har kjørt, og helt nederst har du en flott oppsummering av de ulike testene som har kjørt:

Om du ser for deg at vi hadde kjørt flere script i samme scenarie, så skjønner du kanskje hvorfor vi nummererte testene som vi gjorde. Det ville vært litt kjipt om vi hadde nummerert flere tester i ulike script «1», da ville statistikken blitt ødelagt! Merk også at du ville fått flere eksemplarer av filene om du kjørte flere prosesser, da hver prosess har hver sine filer.

#2: Et litt mer avansert eksempel: Twitter’s REST-api

Nå skal vi begi oss ut på et litt mer intrikat eksempel. For å holde ting så enkelt som mulig, så lager vi et nytt scenarie som «jsoneksempel.properties». Denne er såpass lik den forrige (med unntak av at vi kaller et nytt script), så jeg limer den ikke inn her.

Her kaller vi ett enkelt script (slapp av, vi kommer snart til fler-scripts-scenarier), nemlig t002json.py. Følgende kode er vårt eminente script:

Føler du at du trenger en liten forklaring? Det skal du få:

1. Vi starter etter alle import-statementene med å hente to variabler fra scenarie-fila
2. Grunnen til at vi setter “delayReports” er for å kunne kjøre “setSuccess” på slutten om vi får exception. Hvis vi ikke utsetter rapporteringa, så vil ikke dette funke.
3. Vi definerer deretter en error-output og en log-output, som skriver til filene error… og out…
4. Så wrapper vi to ulike requests, på samme måte som i VG-eksempelet
5. Vi kjører alt i en try-løkke for å kunne feile “gracefully” og logge det som en feilet test
6. Vi gjør en GET mot twitter’s søke-tjeneste, deretter gjør vi litt “JSON-magi”
7. Så looper vi gjennom et JSON-array med alle twitter-resultatene.
8. For hver enkelt tweet logger vi brukerens ID
9. Vi laster også ned profilbildet til hver enkelt bruker

Da er det bare for deg å kjøre scriptet, og se hva som skjer.

./bin/startAgent.sh jsoneksempel

Jeg tipper du vil få et resultat som ligner litt på dette:

Prøv gjerne også å endre variabelen «sokeord» i scenarie-filen.

#3: Et eksempel med mye snadder

Det siste eksempelet er ikke direkte kjørbart, fordi her har vi involvert en rekke artigheter du kan få bruk for i dine ytelsestester. Det betyr at scriptet har noen eksterne avhengigheter som jeg ikke kan legge med i nedlastningen. Det er altså ikke ment for å tas direkte i bruk, det er mer tenkt som en inspirasjon til hva man kan gjøre. Ved å gjøre enkle tweaks kan du kjapt få det til å fungere.

For å nevne noen av tingene som skjer her:

1. Vi importerer inn en egenlaget klasse kalt TestDataGenerator. Denne må du lage selv, ideen vår her er at den kan gi oss en brukerkonto med en viss ID. F.eks kan du bruke denne til å laste inn en stor tekstfil med testdata statisk, slik at du slipper å gjøre dette hver gang i Grinder, for deretter å be om å få en enkelt brukerID fra denne listen i hver testgjennomkjøring
2. Vi importerer vanlig Random fra java.util, og bruker denne til å generere et random tall i hver test som vi bruker som input til klassen jeg nettopp snakket om.
3. Vi setter på noen HTTP-headere. Dette kan f.eks brukes for å aktivere en bakdør vi kun bruker under testkjøring.
4. Vi kjører Basic Auth mot serveren. Dette er nyttig dersom du f.eks har QA-serveren din åpent på nettet for å kunne kjøre distribuerte tester mot den, men likevel ønsker å sperre den for andre enn deg selv.
5. I tillegg catcher vi exceptions, og setter testen til feilet. Dette skjer f.eks om vi får noe annet enn gyldig JSON tilbake fra serveren. Legg også merke til at vi da må sette «delay reports» i grinder, ellers fungerer ikke dette.

Muligens er det også mer snasne ting vi gjør her som jeg har glemt å nevne. Hovedpoenget med dette tredje eksempelet var uansett ikke å gi deg noe som funker «out of the box», men heller gi deg en rekke små triks du selv kan bruke i dine script.

Konklusjon

Konklusjonen er at du nå ikke lenger har noen unnskyldning for å ikke ytelsesteste systemene du lager. Og ingen unnskyldning for å ikke langtidsteste, stressteste, avbruddsteste og lastbalanseringsteste heller for den saks skyld.

Så last ned all koden, test det ut, og sett det opp for ditt prosjekt. Lykke til

Ressurser:

• Grinder’s nettsider: http://grinder.sourceforge.net/
• Jython’s nettsider: http://www.jython.org/
• Grinder TCPProcy: http://grinder.sourceforge.net/g3/tcpproxy.html – Dette er en utrolig fet greie! Du starter den, setter opp en proxy i nettleseren din, surfer litt rundt, for så å stoppe den. Da generer den et fiks ferdig ytelsestest-script for deg (riktignok med en del «ekstrastasj» du bør fjerne, f.eks alle sleep-kallene.)

Bilder er fra stock.xchng, credit: 1, 2, 3

UK-based super hacker and long time Cucumber contributor Rob Holland announced iCuke yesterday. iCuke is a Cucumber extension that lets you write automated functional tests for iPhone apps. Here is a little teaser…

iCuke from Aslak Hellesøy on Vimeo.

For questions about iCuke, please use the iCuke mailing list.

Erfaring 1: Gratis flydata bidrar til økt datakvalitet og tjenesteorientering

Umiddelbart etter lanseringen kom kommentarene, spørsmålene og forslagene. Systemutviklere og flyspottere tok raskt tak i tjenestene og meldte tilbake om inkonsistens og mangler i datasettene. Å bli utsatt for ”amatørers” (da i ordets egentlige betydning) nysgjerrige og kritiske blikk har vært en verdifull og nyttig erfaring for Avinor. Denne “kollektive kvalitetssikringen” har bidratt til å øke kvaliteten på de aktuelle datasettene.

En annen konsekvens av frislippet har vært en mer generell dreining i tankesettet internt i Avinor. At data som tidligere kun har vært i bruk internt nå er eksponert eksternt har økt fokuset på tjenesteorientering, samt bidratt til å tydeliggjøre ansvarsforholdet mellom ulike enheter i organisasjonen. Det oppleves nå som enklere å snakke om både bruk, gjenbruk og utvikling av tjenester.



Erfaring 2: Gratis flydata bidrar til “kollektiv innovasjon”

Eksempel på iPhone-app med flydata fra Avinor

Det er ikke bare Avinor som har hatt nytte av at flydataene nå er tilgjengelig eksternt. Publikum nyter også godt av frislippet.

Kort tid etter lanseringen dukket det opp løsninger som nå hjelper Avinor med å holde det reisende publikum oppdatert på flytrafikkavviklingen. I dag benyttes Avinors API til flere ulike applikasjoner på både iPhone- og Android-plattformen, samt tjenester på en rekke større norske nettsteder.

Dette var alle tjenester som Avinor selv gjerne ønsket å utvikle, men aldri hadde anledning til å prioritere. Men som antatt i forkant; slipper vi dataene fri så vil andre lage løsningene “for oss”. Resultatet blir det samme; folk får tilgang til flytider.

(Som motvekt til iPhone-hysteriet utviklet forøvrig Avinor selv en enkel webløsning som fungerer på alle mobiltelefoner.)



Erfaring 3: Gratis flydata er positivt for omdømmet til Avinor

Lanseringen av API’et har bidratt til at Avinor ved flere anledninger har fått positiv medieomtale. De siste månedene har blant annet NRKbeta, Dagbladet.no og Teknisk Ukeblad hatt oppslag hvor Avinor trekkes fram som eksempel til etterfølgelse. Rett nok har omtalen vært relativt ”smal”, men all positiv omtale er eh… positivt (særlig når man tar i betraktning at Avinor stort sett bare er interessant for mediene når ting ikke går på skinner).

Internt har lanseringen også hatt en positiv omdømmeeffekt. Open data både føles og er moderne. Og Avinor har vært relativt tidlig ute på dette området. Per i dag har ikke altfor mange statlige virksomheter sluppet sine data til fri bruk, og innen internasjonal flytrafikk er eksemplene enda færre. Tanken på det kan gjøre en og annen ansatt i Avinor stolt. Open data bør definitivt være en målsetning, men foreløpig er det ingen selvfølge. Kudos til de som går foran.

- – - – -

Kommentar: Betydningen av erfaring 3 skal ikke overdrives. Verdien av erfaring 1 og 2 skal derimot ikke underdrives. Undertegnede er forøvrig en av flere BEKKere som jobber for Avinor.

Årsaken er at det indikerer at man har sluttet å engasjere seg. Man godtar ubrukelige regler, på tross av utvilsom støyfaktor og null verdi. Det tyder på at man ikke bryr seg om koden sin. Og kode er det mest sentrale vi produserer, kommuniserer og vedlikeholder.

Standard informasjon

Standard logginformasjon inkluderer typisk tidspunkt, alvorlighetsgrad, program- og komponentnavn i tillegg til selve meldingen. Et godt loggrammeverk tilbyr tilpasning av både innhold og format av disse parametrene.

Riktig feilhåndtering forutsetter fornuftig kategorisering og identifisering av feilhendelse. Feilkategori og unik feil-ID er en viktig del av kontekstinformasjonen.

Brukernavn

Brukernavn for den innloggede brukeren kan med fordel logges. Enkelte applikasjonsservere tilbyr denne funksjonaliteten forutsatt at du benytter de innebygde mekanismene for autentisering og logging. En teknikk man kan benytte i egen kode er å ha brukernavnet på trådkonteksten (for eksempel  en ThreadLocal variabel i Java). Når en feil oppstår henter loggmekanismen brukernavnet fra trådkonteksten og skriver det til loggen. Mange sikkerhetsrammeverk bruker også denne teknikken, det kan derfor hende at brukernavnet allerede ligger klart for bruk.

Støtte for vilkårlig kontekstinformasjon

Når en feil oppstår er det gjerne nyttig å legge til spesifikk informasjon om tilstand og kontekst. Det kan også være behov for å supplere mer informasjon oppover i kall-stacken. Rammeverket bør derfor ha støtte for å legge til vilkårlig kontekstinformasjon, for eksempel som skissert under.

public class AbstractException() {
   ...
   public void leggTilFeilinformasjon(String navn, Object info) {
      feilinformasjon.add(navn, info);
   }
}

Selvbeskrivende objekter

Når man skal logge tilstand for de ulike objektene er det en stor fordel at disse kan beskrive seg selv. Det er feil ansvarsfordeling dersom en feilhåndteringsrutine må pakke ut og formattere kontekstinformasjonen som skal logges. En slik tilnærming vil også sannsynligvis føre til inkonsistens og duplisering.

Java-mekanismen for selvbeskrivende objekter er den velkjente toString()-metoden. Ved å implementere toString() på en god måte vil tilstand kunne logges enkelt og konsistent. I tillegg er det enkelt å lage automatiserte tester for denne funksjonaliteten, og disse kan også fungere som dokumentasjon. Komponenter som Apache ToStringBuilder kan være nyttig for implementasjon av toString().

Stacktrace og uventede feil

God feilhåndtering betyr få stacktrace i loggen. Ideelt sett oppstår behovet for stacktrace kun ved programmeringsfeil; gitt at applikasjonsfeil og systemfeil er riktig håndtert og har tilstrekkelig kontekstinformasjon. Imidlertid, når en uventet feil først oppstår er stacktracen en uvurderlig del av kontekstinformasjonen. Man kan med forlel skille ut disse i en egen logg for utviklere; drift ser ofte på stacktrace som et verdiløst irritasjonsmoment.

Oppsummering

God kontekstinformasjon er en sentral mekanisme for riktig feilhåndtering. Drift og utvikling kan med stor sannsynlighet forstå og gjenskape feilsituasjonen, og dermed også rette feilen raskt. Teknikkene for kontekstinformasjon er enkle å implementere, forutsatt at feilhåndtering er en prioritert og forstått del av prosjektet.

Brukeren

Brukeren av systemet er først og fremst opptatt av at en feil har oppstått, at situasjonen er håndtert og ikke medfører senere problemer. Det er selvfølgelig irriterende og kan være problematisk når feil inntreffer, uansett er det kritisk at situasjonen ser ut til å være under kontroll. Brukeren bryr seg sjelden om årsaken til feilen, men vil gjerne kunne identifisere den spesifikke situasjonen når hun snakker med supportapparatet.

Forretningssiden

Forretningssiden (funksjonelt ansvarlige i utviklingsprosessen) forstår primært funksjonelle feil, og antar ofte at utviklere og leverandører tar seg av andre feiltyper. De ønsker generelt en applikasjon uten kritiske feil, men vil sjelden sørge for at feilhåndtering blir riktig prioritert i utviklingsprosessen.

Kunde/Bestiller

Den som sitter på budsjettet og bestiller applikasjonen har forventninger om en fungerende applikasjon, men har vent seg til at ingen applikasjoner er feilfrie. De er vanligvis ikke tilstrekkelig involvert i prosjektet til å påvirke og vektlegge feilhåndtering. Noen stiller imidlertid med testledere som kan være erfarne nok til å ivareta dette ansvaret og sørge for at unntaks- og feilsituasjoner blir testet.

Drift

Drift vil vite hva de skal gjøre når feil oppstår. På kort sikt er drift kun interessert i å gjøre grep slik at systemet kjører videre og ikke har havnet i en ugyldig tilstand. Selv om årsaken til feilen kan være interessant vil driftpersoner sjelden ha behov for detaljerte beskrivelser. Imidlertid vil de gjerne ha en oversikt over potensielle og kjente feilsituasjoner, kunne gjenkjenne feilkategoriene og kanskje bygge opp en erfaringsbase over tid.

Utviklere

Utviklere vil vite alt:

• Hva var årsaken til feilen?
• På hvilken server skjedde den?
• Når oppsto situasjonen?
• Hvilken tilstand hadde brukeren og applikasjonen?
• Hva var kontekst i feilsituasjonen?
• Kan den gjenskapes?

Ettersom utviklere ofte står for feilhåndteringen vil utviklerbehovene prege implementasjonen. Dette resulterer gjerne i detaljerte feilmeldinger i alle sammenhenger; i brukergrensesnittet, loggfiler og konsoller.

Tilpasning til brukernes behov

For bedre feilhåndtering må man i større grad skille mellom ulike brukergrupper og deres behov. Her er noen mulige tilnærminger:

• Utviklingsprosjektet må ta hovedansvaret for feilhåndteringen. All erfaring tilsier at man ikke kan forvente at forretningssiden eller bestiller vil sørge for at behovene beskrives og prioriteres. Dersom kunden ikke har en erfaren testleder bør prosjektene selv bekle denne rollen.
• Unngå detaljerte feilbeskrivelser i brukergrensesnittet, men oppgi gjerne en unik feil-ID slik at det er mulig å finne tilbake til den spesifikke feilen.
• Involver drift i hele utviklingsprosjektet slik at de kan bidra til kravstilling og kommunisere sine behov på lik linje med funksjonelle krav.
• Sørg for konsistent feilkategorisering som drift kan bruke for å kjenne igjen feil.
• Bruk gjerne forskjellige logger for drift og feilretting. Drift har i utgangspunktet ikke behov for de detaljerte feilbeskrivelsene som man har i forvaltning.
• Sørg for å legge til kontekstinformasjon i feilsituasjoner.

Når man feilsøker kan man skille mellom to ulike behov:

• Feilkategori beskriver hvilken feil som har oppstått. Den kategoriserer hendelser av samme type, og brukes for å forstå hva som har skjedd.
• Identifisering av feilhendelsen forteller hva som har skjedd til en bestemt tid i en spesifikk sammenheng. Typisk er dette nyttig for å finne ut hva som har skjedd når man feilsøker en bestemt feilsituasjon meldt av en bruker.

Feilkategorisering

Feilkategorisering har flere alternative tilnærminger:

• Hver feilkategori representeres med en egen Exception. Java SE APIet er et eksempel på denne tilnærmingen. Dette resulterer typisk i mange Exception-klasser  definert på ulike steder i pakkestrukturen. Tilnærmingen kan derfor kalles distribuert.
• Et fåtall sentrale Exception-klasser definerer feiltypene (gjerne Applikasjonsfeil, Systemfeil og Programmeringsfeil). For hver feiltype defineres en ID som feiltypen bærer med seg (typisk en Enum spesifisert i constructor). Denne tilnærmingen kan ses på som sentralisert.
• Kombinasjoner av disse, for eksempel et fåtall sentrale Exception-klasser med distribuerte subklasser.

Sentralisert feilhierarki

Uavhengig av tilnærming er hensikten å gjenkjenne feilen og forstå hvorfor den oppstår. En driftsperson vil kanskje lage en erfaringsbase for kjente feilkategorier. En utvikler som skal feilrette har også god nytte av god feilkategorisering for å finne årsaken.

Min erfaring er at applikasjoner lykkes best med en sentralisert tilnærming, der man definerer feilkategoriene som en felles Enum. Rammeverk (f.eks. Java SE API og Spring Framework) velger gjerne en distribuert tilnærming; ettersom dette ikke er applikasjoner har man ikke det samme behovet for sentral oversikt over feilkategoriene.

Enum Kategori { INGEN_PENGER, FEIL_ROLLE, UTESTENGT };
...
 
public class AbstractException() {
   public AbstractException(Kategori kategori, ...) {
      ...
   }
}

Kategorisereing av feil ved hjelp av Enum

Identifisering av feilhendelse

For å finne ut av en spesifikk feil ønsker man å identifisere den unike hendelsen som forårsaket feilen. Typisk er dette en situasjon der en bruker melder en feil eller når man feilsøker en hendelse som andre har rapportert tidligere. Å kunne identifisere denne ene feilen i en stor loggfil er gull verdt. Dette krever at hver enkelt feil blir logget med en unik ID.

En teknikk som fungerer bra nok i de fleste sammenhenger er å bruke tidspunktet feilen oppstår (i millisekunder) som ID. Denne IDen vises i feilsammenheng og skrives samtidig til feilloggen. Sannsynligheten for at to eller flere feil oppstår i samme millisekund er tilstede, men denne teknikken vil uansett begrense utvalget til et minimum. Funksjonaliteten for å lagre IDen implementeres i Exception-superklassen.

public class AbstractException() {
   private final long uid;
   public AbstractException(...) {
      uid = System.currentTimeMillis(); // skrives til loggen
   }
}

Eksempel på identifisering av Exception-instans med timestamp.

Oppsummering

God feilhåndtering forutsetter riktig kategorisering av feil i tillegg til støtte for å identifisere hver enkelt feilhendelse. Som alltid krever dette at man har et bevisst og målrettet forhold til feilhåndtering gjennom hele prosjektløpet. Det er fullt mulig å unngå at feilkategorisering og idendifisering av feilhendelse blir klattet på mot slutten av et prosjekt; å involvere driftpersoner som kravstillere på lik linje med annen funksjonalitet er en god start. God kontekstinformasjon i en feilsituasjon er også viktig, dette blir et eget tema i denne serien.

• Applikasjonsfeil
• Systemfeil
• Programmeringsfeil

Applikasjonsfeil skyldes at funksjonelle forutsetninger ikke er tilfredsstilt. I praksis er dette gjerne ugyldig eller feilformatert input som for kort fødselsnummer, e-postadresse uten @, dobbeltføring av betaling eller en kunde som har utilstrekkelig bonusnivå for å utføre en handling. Applikasjonsfeil kan sies å være forventet og skal håndteres på lik linje med andre krav. Det kan være krevende å forutse alle slike feilsituasjoner. Erfaringsmessig har forretningsfolk god oversikt over de vanligste funksjonelle problemene, mens teknikere er flinke til å tenke på grenseverdier og inkonsistens. En iterativ tilnærming med teknikker som test-drevet utvikling, brukerhistorier og BDD vil avsløre de fleste applikasjonsfeilene. I utgangspunktet skal det ikke være nødvendig å feilrette og rulle ut en ny versjon av applikasjonen for denne typen feil. For å håndtere applikasjonsfeilene som allikevel slipper ut i produksjon er det viktig med hyppig utrulling slik at man kan fange opp disse etterhvert som man får praktisk erfaring med systemet.

Systemfeil skyldes feil i applikasjonens omgivelser eller infrastruktur. Typisk er dette en disk som går full, et nettverk som blir utilgjengelig eller en server blir overbelastet. Slike feil er også til en viss grad forventet; de opptrer sjelden, kan være vanskelig å forutse, men i praksis er det gjerne rimelig enkelt å teste slike feilsituasjoner. Ved systemfeil kan det gi mening å kjøre fail-over om mulig, alternativt vente en stund for deretter å prøve operasjonen på nytt; denne type feilhåndtering tilbys gjerne av meldingssystemer. Feilretting og ny utrulling skal ikke være nødvendig for denne feiltypen.

Programmeringsfeil skyldes at utviklere ikke har gjort jobben sin. De oppstår når applikasjonen ikke klarer å håndtere uventede hendelser på på robust vis. Typiske eksempler på dette (i en Java-applikasjon) er når systemet spyr ut feil av typen NullPointerException, NoSuchElementException og IndexOutOfBoundsException. Godt håndtverk med teknikker som TDD og automatisert testing, parprogrammering og kodegjennomgang er effektive tilnærminger for å minimere denne typen feil. Når en programmeringsfeil oppstår krever det en feilretting og påfølgende utrulling av ny versjon.

Tabellen under gir en oversikt over feiltypene og om de bør fanges og håndteres i applikasjonen, om det er mulig å vente litt og prøve operasjonen på nytt samt om den krever feilretting og utrulling av ny versjon:

Dårlig feilhåndtering er dessverre alt for utbredt i vår industri. Antall stacktrace i loggen er en indikator på hvilken kvalitet applikasjonen har; applikasjonsfeil og systemfeil skal være håndtert mens programmeringsfeil skal være luket ut i utviklingsprosessen. Et bevisst forhold til feiltyper og hvordan de bør håndteres er et godt utgangspunkt for å lykkes på dette området. Riktig feilhåndtering krever imidlertid målrettet innsats gjennom hele utviklingsløpet.

Hvis man tar innover seg gjeldsbegrepet så er det i praksis ikke gjelden, men rentene som kjennes på kroppen. Vi mener at det er mer hensiktsmessig å måle tekniske renter enn teknisk gjeld. Rentene kan man enkelt finne ved å se på differansen mellom hvor lang tid det tar å implementere en oppgave i et nyoppstartet utviklingsprosjekt i forhold til i forvaltning. Hvis man bruker 1 time på å lage en avkryssningsboks i nyutvikling og 8 timer i forvaltning, kan man regne med at 7 av disse timene er renter. Hastigheten man en gang hadde er nå redusert, differansen velger vi å se på som tekniske renter. Dette er tid som er lite nyttig og oppleves som frustrerende, tid som vi gjerne ønsker å bruke til noe annet.

I BEKK forvaltning har vi mange prosjekter med en hel del nedskrevet og noe glemt gjeld. Vi har undersøkt om vi kan måle de tekniske rentene på denne gjelden og om dette kan gi oss et bedre bilde av hvilke utfordringer vi står ovenfor. Målet er å kunne gjøre forvaltning av applikasjoner på en bedre måte.

Ved å notere når man betaler tekniske renter fant vi raskt ut hvilken størrelseorden gjelden var på. Samtidig ser vi i hvilken del av applikasjonen gjelden befinner seg. Delen med gjeld er den delen av systemet man jobber med når rentene betales. Grafen under viser hvordan vi ser for oss en slik rentebetaling gjennom utviklingsløpet. Hastigheten eller “Valuta for pengene” på y-aksen og tid langs x-aksen.

De faktorene vi har tatt for oss vil hver for seg senke utviklingshastigheten. Hver av faktorene peker på et området hvor vi betaler renter og derfor har teknisk gjeld. Det finnes mange flere punkter og de varierer selvfølgelig fra prosjekt til prosjekt. Dette er vår liste, du kan sikkert finne flere punkter vi hadde satt pris på om du legger de til i kommentarfeltet.

Figuren over viser at hvis man for eksempel mister fokus på å skape verdi så vil hastigheten synke over tid. Hvis man i tillegg mister overføring av kompetanse vil utviklingshastigheten reduseres ytligere på grunn av manglende kompetanse hos de som skal gjøre jobben framover. Konsekvensen av de ulike punktene akkumulerer slik at de totalt bidrar til en reduksjon av utviklingshastigheten.

Verdifokus
Prosjekter som har gått lenge har ofte en tendens til å bli preget av at prosjektet i bunn og grunn består i å rette feil. Det har tapt verdifokus i og med at man jobber med ting som ikke nødvendigvis gir mest verdi for pengene. I disse situasjonene har man ofte mistet overblikket og retningen for hvorfor prosjektet er i drift. Samtidig som koden man skriver blir vanskelig å vedlikeholde når de store linjene ikke tydelig kommer fram.

Kompetanse
Ofte ser vi prosjekter som sprinter mot lansering og i det prosjektet er ferdig går hele teamet over på nye prosjekter. Med de forsvinner også viktig kunnskap. Vi ser at ved å overlappe forvaltningsteamet med utviklingsteamet (dette kan gjøres på mange måter) slipper vi å gjenoppdage rutiner og konvensjoner. Tid man kan bruke på viktigere ting.

Automatiserte tester
Prosjekter av en viss alder har ikke automatiserte tester, eller tester i det hele tatt. Renter blir her betalt ved å opprette tester og regresjonstester for de delene av systemet hvor man skal gjøre endringer. Det å få tilbakebetalt disse rentene kan ta mye tid, men vi obsererer gang på gang at det er helt essensielt for at utviklinghastigheten skal øke.

Byggerutiner
Hvis noe gjør vondt, gjør det ofte. Hvis du gjør noe ofte, automatiser det. Det sier seg selv at slike oppgaver er repetitive, og hvis du gjør dem ofte tar de mye tid. Som igjen gjør at du bruker mye tid på å gjøre disse oppgavene.

Historie
Vi har i noen prosjekter brukt mye tid på å finne bakgrunnen for en designavgjørelse. I andre prosjekter har dette vært dokumentert ved god og uttrykksfull kode eller i form av en god og forståelig commit melding. Dette er steder hvor informasjonen er knyttet til kontekst (revisjon eller integrasjonspunkter) og hvis integrasjonspunktet endrer seg vil man med større sannsynlighet slette koden, i motsetning til dokumentet som omhandler det.

Hvert av punktene beskriver hvordan vi identifiserer at vi betaler renter og hvordan vi løste våre problemer. Det vi ønsker å få fram er ikke nødvendigvis størrelsen på den tekniske gjelden men hvordan man identifiserer den ved å se på betaling av renter. Ved å identifisere det vil man også være i en bedre posisjon for å ta problemet ved roten.

Konsekvensene ved å ta opp teknisk gjeld er ikke nødvendigvis gjelden i seg selv, men rentene du betaler på den. Dette viser seg i den ekstra tiden du bruker på oppgaver som gikk raskere før. Gjelden må håndteres for at utviklingshastigheten ikke skal bremse opp. Det koster dine kunder mye, og gir deg kjedelige oppgaver.