Service lifecycle

Just some notes about the lifecycle of an instance of a service application from deployment through to shutdown.

In a continuous delivery environment this cycle might happen multiple times per day, where each instance represents a new version of working software that has passed through a deployment pipeline.

Start up

Initialisation
 - locate and parse configuration
 - validate configuration
 - establish connectivity to downstream services
 - log success or failure details

PASS/FAIL

Ready to accept requests, but no routing in place to receive live traffic.

Smoke tests
 - final readiness checks before setting live
 - accept and process incoming requests, produce responses

PASS/FAIL

Load balancer updated to direct live traffic

Routine business of processing incoming requests

Requests come in via load balancer, get processed by service - potentially with calls to downstream services - and responses are returned.

Depending on demand, the number of instances of the service may be scaled up and down to service the volume of requests.

Shut down

Load balancer updated to exclude instance from receiving live traffic requests (connection draining to allow existing requests to each receive a response - check how well this is supported).

Log the fact that shutdown has been initiated.

Finish processing existing requests

Close all connections to downstream services.

Terminate all threads.

Process terminates.

Tapping into the Zeitgeist

A while ago there was a contest to develop a plugin for a Continuous Delivery system called Go.

I decided to "have a go," and my product was judged to be the best suited to the criteria of the competition.

When I was first contemplating producing something a colleague suggested that I  do something with Docker because that was the hot technology at the time.  Instead I opted for something that I believed would benefit my team in our use of Cloud Foundry.

Rather than going for the obvious - automating deployment to Cloud Foundry - I chose to give developers a system which could alert their CI pipeline when an app has been re-deployed.

Github doesn't seem to give statistics on downloads, so I find myself a little frustrated at not being able to tell how many people are actually making use of my first serious foray into open source software.

Experimenting with Go Continuous Delivery

If you're working on a Mac you may encounter an annoyance when installing the Go Continuous Delivery server.  It blindly insists on finding a version 6 JVM - even if a compatible later version is available.
After an initial attempt at adjusting the config, and a bit of Googling around I gave up on trying to make it work.
A week or so later I found myself using some spare time at home to develop a plugin on a Mac.  After a couple of days of having to wait until the following day to try out the functionality on my work Linux setup I came across some instructions for installing and using a Vagrant virtual box which contains a fully operational Go server.

http://www.go.cd/2014/09/09/Go-Sample-Virtualbox.html

I haven't used it extensively but it has made plugin development easier for me.

Continuous Delivery / DevOps

Something that I particularly enjoy about living in London is the time that I have each morning and evening during the commute between home and work for reading on the Underground.

One of the books that I am currently reading is Continuous Delivery - Reliable Software Releases Through Build, Test, and Deployment Automation. I found the first chapter acted as a timely reminder for my recent resignation. To paraphrase, skillful and experienced team members getting bogged down with manual deployment processes doesn't make for a fun and productive environment.

The first half of this week has been dedicated to updating 7 existing websites, and launching a completely new one. So far it has been relatively painless, but tiring.