Tuesday, February 10, 2015

"From complete chaos to Octopus Deploy" Part 2: Where to begin?

Introduction to this blog series

How do you automate the non-existing deployment routines of an organization with over 100 different customers, each having their own environments? How do you convince the leaders, developers and customers to give you the resources needed in order to automate everything?  Is it really possible to introduce a routine that works for everyone?

Where to begin? 

I had my task at hand: Automate the deployment process for more than 100 different customers spread across approximately 30 different hosting vendors. But where to begin?

I started out by installing the Octopus Deploy server so that I had somewhere to click around and explore my possibilities while I read up on the basic concepts of Octopus Deploy. However, it didn't take me long to realize that before I dug too deep into the technicalities, I needed some sort of goal and a roadmap. I asked myself: "How do I want a standard deployment process to look after I've introduced Octopus Deploy to the organization?"

From this a goal was created:


As you can see from the diagram we were already using Git for source control and TeamCity as a build server and luckily for us, Octopus Deploy and TeamCity go very well together.

So this was my goal, but I still needed a way to get there. Needless to say, this goal would have to be further specified later on as "Deploy project" could mean anything from "Remove server from load balancer, deploy web application, deploy windows service, add server to load balancer, repeat for remaining servers" to "Automatically email release notes to customer, deploy web application, warm up web application". But at this point, specifying exactly what would happen in the "Deploy project" step was impossible.

Creating a roadmap

Next up, I began planning a roadmap to reach this goal I'd set for our "Standard deployment process".

My roadmap turned out something like this:
1. Find the most "average" customer project we had
2. Try to make the project "fit" the deployment process I had in mind, documenting every step on the way.
3. If successful, repeat step 1-2 for a more complex project. Do this for at least three different projects varying in complexity.

I decided I would focus only on one environment to begin with, and that is an internal demo server we use for almost all our ongoing projects, called Epinova.Demo. If I reached my goal of setting up my "standard deployment process" for at least three different projects towards the Epinova.Demo environment, I would move on to the customers own environments: Test, Staging, Acceptance and Production. However, I wanted to make sure that the "standard deployment process" was foolproof before moving on to external environments.

Finally, I had a plan and a goal! I ran this by a couple of my colleagues to see if they had any input as to which projects would be good for testing this out, and we managed to find some great ones. I also asked them if they could see any immediate flaws with my goal of what our "standard deployment process" would look like, and they all gave me the thumbs up. Thanks guys!

But enough of the planning and setting goals, what we all want is to get technical isn't it? And that's exactly what we'll be doing! In tomorrows post: The basic concepts of Octopus Deploy

No comments:

Post a Comment