A DevOps Voyage - The Plan

Part One - The Plan

One the first voyage out we will be setting up a continuous delivery platform. The goal here is to explain how to setup a DevOps system for a small development shop, that builds web based applications. This is not a definition of DevOps, this can be found online; for example: DevOps on Wikipedia or why you should, or should not use DevOps.

I’m making a bunch of assumptions about the small project that is being deployed but the process should be dead easy.

while(!isFeatureComplete) {
    CheckCodeIntoSourceControl();
}

That’s all there should be too it from the contributor point of view. While this may initially look like an extreme simplification, it really isn’t; I’ve removed the write code portion because while it may be essential to the product, it is not essential to the process. The actual process of writing code is not included in the simple loop, it should not matter where the work artefacts come from, they could be copied from another project or new test data records.

This is the desired level of effort that should required to contribute to the product. Yes, this only discusses the actual coding activities and not the requires gathering or business analysis that goes on before hand. There are activities that are not covered by DevOps, these are two, let’s pull this out as important and perhaps we can circle back over it later.

Integrating product management into the continuous delivery processes.

All the other activities that we would expect to have in a development process are incorporated within the framework of the loop; this includes feature verification and deployment. Before we step into our simple loop we need to do some prep-work, we need to define what the system will look like for our activity.

The process

Let’s start by defining the process that we are attempting to automate:

1. source control repository
2. source code compiler (not required for non-compiled languages)
3. unit test runner
4. gated check-ins (passing unit tests)
5. automatic and gated deployments (passing integration tests)
6. continuous monitor

Next, we’ll define the environment. Whether these machines are physical or virtual is slightly immaterial, however, virtualization does give additional capability that physical machines do not. My assumption is that all machines (with the possible exception of the actual dev machine) are virtualized, at a minimum the deployment servers need to virtualized so they may be spun up and . So then, the following is a list of machines that will be used to build the process.

1. source control server
2. local ‘dev’ machine
3. build server
4. deployment platform(s*)

* It is completely possible that the deployment target server could be multiple servers, for example: application, DB, web, message, etc.. The actual number of servers is important only to the deployment script. Furthermore the number of actual deployment platforms will also vary, the likely number being two (test and production) though this can easily grow to include multiple levels of testing (UAT, Performance, Accessibility, Data Integrity, etc) and multiple production environments (by geography, early release/public beta, etc.). For the purposes of this voyage we will assume two deployment environments; testing and production.

All together the process of setting up a complete DevOps environment should not be more then a couple of days effort. Here’s the order we’ll take these things in:

1. setting up source control
   either local or remote, should also include a source controll client
2. setting up a build server
   once the source control is set up, getting things into and out of it
3. setting up a deployment server
   finally standing up a build in a test environment, also some discussion on virtualization

Within each section I’ll try to cover as much as possible from the both the why and the how.

Next up Part Two - Source Control