7 Ways to Get Started with DevOps Today

Transitioning to a DevOps approach can be a confusing and daunting prospect. Looking at organizations that practice DevOps, we may see a completely foreign landscape with a different organizational structure, practices, and an array of new DevOps tools for us to learn. It’s easy to forget that those companies took a long time to get where they are and that they started with much smaller, much simpler steps. One of the challenges organizations face is that they think the smallest first steps take months and loads of training. In this article, I’m going to discuss seven very small steps that you can start today. Many of these don’t require you to buy new DevOps automation tools or make changes to your organization. They can be done by the CTO or by an interested developer or system administrator. Most importantly, they can be done today; between meetings, during lunch, or on a train ride home. 1)  Invite Your Operations Team Into Your Development Process Though it may seem obvious, this small change is one of the most often overlooked. This doesn’t need to be a big organizational change. Having an operations team member attend the development team’s standup meeting or a developer sit in with the operations team while they conduct a deployment is a great way to start. The whole purpose of DevOps is to bring these two groups together and the best place to start is small interactions with the members of both teams. 2) Visualize the Work Together This goes hand/in/hand with bringing operations into your development process. If you’ve got a Scrum board or Kanban board, add a few columns to the end of it – even if it’s as simple as “Waiting for Deployment” and “Deployed.”  It’s a small change, but it sends a clear message that the work isn’t done until it is deployed and usable. After all, that amazing feature doesn’t help anyone while it’s sitting in the code repository. 3) Automate Your Test/Build Process OK, this one definitely involves solutions, but it isn’t as difficult as you might think. VersionOne offers demonstrations of its new Continuum™ for DevOps solution, while other free continuous integration tools exist. Grab a copy and run it on your local machine. Within an hour or so, you can have yourself set up to check out the code from source control, build the project, and run the unit tests. Once that’s working, you can set it to run each time code is checked in to the repository. Congratulations! You now have information about how often your check/ins build and run all tests successfully. You can even set it to send a notification when it fails and provide fast feedback to your whole team. You aren’t quite at continuous integration yet, but it’s a big step in the right direction. 4) Create a Deployment Plan Does your company set aside nights or even whole weekends for deployments? Do unexpected problems always crop up resulting in a mad dash to get the system live before your maintenance window runs out? If so, don’t worry; you’re not alone. Many applications and systems evolve over time and maybe you don’t have a good understanding of what libraries got installed to make it work or what system configurations got changed. If you had to deploy your application from scratch, what would you do? This question may lead you to many other people and departments. Once you’ve got a plan, try it out. You may find some holes in your plan. You may also find that there are some complexities in your current environment that don’t need to be there. 5) Identify Fragile Systems Are any steps in your plan or systems in your deployment problematic? Most application environments have at least one system or component that they would consider fragile. Perhaps it’s an old web server that never quite deploys correctly or a script that works fine until you try to change something. These will be prime candidates for your DevOps efforts. Creating transparency and DevOps automation around these items will make your deployment process faster and easier. 6) Smooth Out Wait States If fragile components are the biggest pain point in the deployment process, wait states are a close second. Most processes have more time built into them just waiting for people than they have time with actual work being done.  Try thinking through your process and identifying where these wait states are occurring. Then share this with your development and operations teams. See if there are a few wait states you can smooth out. 7) Link Your Work to Your Value Most of the points I’ve discussed are technical, but remember what’s driving DevOps. The reason we follow our process through deployment is because our hard work isn’t producing value until it’s in front of a user. The closer we get to the code and configuration, the more our language starts to focus on commits, builds, and artifacts. Try using business language like features and functionality in your deployment plans. Not only will this connect you more to the value your work is delivering, but it will also keep you thinking about what else needs to make it through the deployment process. Maybe this feature isn’t available until the server upgrade happens. Was that worked into your deployment process? What about the important configuration change? Then What? If you take these small steps, you’ll already be well on your way to a strong DevOps culture. But what about all those solutions you hear about? As you expand your DevOps effort, you’ll find that many of them are indispensible. The question is: which ones? Going through these initial steps can give you an understanding of how your team operates and gets its work in front of users. Once you know that, you’ll really be able to get the most out of those solutions. So learn more about how your team works, then dive into all of the amazing solutions out there to help you work better.