It is very fashionable to apply a single word to pretty much ANYTHING to try to get in on the latest trend. The current ‘Whatever-Ops’ trend (MarketingOps, ChatOps, OpsOps) is one such example. For a while, though, we’ve been having the word ‘Continuous’ thrown in front of a whole lot of activities in the software development world: Continuous Delivery, Continuous Improvement, Continuous Management. There’s a reason for this… repeatable processes are a key ingredient to predictable delivery. And predictable delivery means money in the bank!

Why Continuous?

Regardless of the framework implementation details behind a given delivery philosophy, the words we choose give a sense of what is important. The word ‘agile’ makes us think of the ability to react quickly. A ‘lean’ process implies we aren’t wasting. Making something ‘continuous’ leads us to believe that we aren’t just guessing: we know how to do this, again and again, and we aren’t stopping… ever.

It does not matter how you bring your team together to get the work done because at some level there is always a need to repeat your process from one job to the next. Maybe that is writing web service logic, maybe that is building an Android app, or maybe that is operating radar technology for a major airport. In all cases, whatever was done today will probably need to be done again tomorrow.

Applying to Software delivery

You can call it Application Lifecycle Management (ALM), DevOps, SDLC, whatever you would like. At some point, we’re all saying the same thing: let’s get this done, let’s know when that is going to happen, and let’s not go broke doing it. Oh wait, is that the Iron Triangle I hear there? Yes. Yes it is. You can try to escape the realities of the triangle all you like, but we are prisoners to its’ icy grip.

That being said, there are a few continuous philosophies that can help you execute delivery better.

1. Continuous Improvement

   Be better than you were yesterday. Do not be paralyzed trying to obtain the ultimate process, instead, get working and refine how the team works together along the way. Make sure you question everything you are doing and look for ways to optimize the process. Baby steps are key, so try to plan out where you are, where you want to be, and how to get there.

   If you’re looking to get started here, you might want to take a look at a presentation I did on advancing your processes with continuous improvement.

2. Continuous Build

   Always compiling. This is a key first step in leaving the “but it worked on my machine” world. Ensure you have a build server that listens for check-ins and makes sure that what is in source control can be built into something that might potentially be working software. You might not have tests, you might not be deploying anything, but at least you’re checking it compiles.

   If you’re looking for a tool, I prefer TeamCity. Be careful if you are using the free version as there are limited build definitions. In that case, you may not want to waste build definitions on Continuous Build and upgrade those to Continuous Integration builds.

3. Continuous Integration

   Together forever. This is likely the most adopted ‘continuous’ process in the software delivery world. Grab everything on a build server, compile, and push everything somewhere else. You might run some unit tests at this point, but the key is that everything is definitely in a deployable state. One could even hope that you could deploy to production! This process proves to you that you know everything is in a good state, that you know how to deploy your software, and you know that it is working together with other systems.

   One thing I see teams miss often is the data schema. Data structures are just as much a part of the application as the code, so make sure you are deploying database changes!

4. Continuous Delivery

   Getting your money’s worth. The key to getting a return on your investment in the development of software is making sure that the time between Needing something and Having something is as short as possible. You can’t do this unless you are always delivering something. That means not sitting for 2 years burning through millions of dollars of budget and not letting anybody use any of the features you built because “the whole list of requirements isn’t done yet”. Continuous Delivery isn’t about every check-in going to production, it’s about having a repeatable and short cycle (90 days or less) of getting your investments out to production so you can start reaping the rewards.

   It is important to note that this isn’t just a change to your development process. To get something live usually involves ALL aspects of the business. That means management, operations, support, development, testing, security, networking… you can see why DevOps discussions are all the rage!

5. Continuous Deployment

   Checking in to production. This is the combination of a mature Continuous Integration model, Continuous Delivery, advanced automated testing, monitoring software, and feature toggling. Do minutes count? Are you operating a high level of revenue through your application? Do you want a high degree of Return on Investment and minimal time from conception to delivery? Then do this.

   This is the ultimate in shortest time between Needing and Having. You will need to get here slowly as there is an investment needed to get the processes in place to support this. Individual feature costs will be higher, but you’ll get your features more immediately. In Continuous Deployment, every time one of your developers is done work, it needs to be ready to go out to production. If it isn’t good enough, it needs to be stopped. This means catching breaking software changes before they get to the real end users, usually through a suite of automated tests. If something does get through, advanced monitoring will catch unexpected behaviour and allow you to react.

   Companies who have a large portion of their business driven through an application can’t afford to have their systems go down and wait a few weeks for a fix. Imagine a major commercial site like Etsy or Amazon being completely offline or unable to execute transactions for a single day.

Continuous Everything is here to stay

The business need to be able to react and deliver in a repeatable manner is not going away. Our teams need to put in place the tools and processes required so we can be deliberate about improvement and delivery. Start small. Be better.

And then do it again!