How to Make a DevOps Workflow Strategy

DevOps is a deployment process that helps automate a lot of processes that used to take a team hours to days to get through. When you are trying to get that process going, you need to know that everyone is on-board or else it won't work. Switching from Waterfall deployments to DevOps is a huge organizational change.

It takes everyone's approval or else you'll end up with a few people who still do manual deploys to production. Whether you're at a start-up or a huge enterprise company, getting your DevOps process ready for real use takes a solid strategy. You have to consider the big picture goals and the repetitive tasks that are currently in place before you start making suggestions for how the process should flow.

Considerations for Your Strategy

The main thing you want to focus on when you're developing a strategy is get rid of the problems you're facing with your current process. Are there a lot of bugs getting to production? Is there only one person that understands how all of the tools work together? Do you have to keep several teams on call after a deploy? Those are some huge determining factors on everything you do in the beginning.

Another important consideration is knowing what your requirements are. DevOps workflows aren't just for a single application in your organization, but for every piece of software the development team pushes changes to. What cloud infrastructures are you going to work with? Are you handling massive amounts of data or are you working with multiple apps that need high uptime?

These are the kinds of things that need to be addressed before you start investing in any tools or products because they drive all of the core decisions that will guide everything else. Many of the tools you'll be able to choose from will come from this part of building requirements for your tooling.

Set Up a Process

Make sure that all of the teams affected give input here. There will be a need to write automated tests, implement the right security tools, and a way to handle multiple environments. Look at what your current process is and start outlining the major parts.

In particular, look at how the build process works. Is there a single command you need to run, like yarn build? Or is there a more complex process to build your application? From there look at how you're getting code from a developer's local machine to the production server.

If you need to deploy to other environments first, make a note of that. If you need to clear the server cache to make sure users see the new changes, make sure that gets included.

That's why you'll see a lot of the same stages commonly used in CI/CD pipelines, like the build, test, delivery, and deploy stages. Breaking the entire deploy process up into these stages makes it easier for you to focus on the details that should be included in each one.

For example, you might need to build several code bases before you can get past the build stage. Or you might need to import a number of resources to get things working like they need to in production.

In the test stage you can do both unit testing and security testing. This usually comes right after the build phase and some testing might occur before the build. It depends on your code base and how your teams work best.

The delivery and deploy stages are going to have some similarities. You'll be dealing with credentials and secrets for different services across the multiple environments you deploy to.

You might have a staging environment set up that uses the free version of the tools you use in production. Or you could have QA environment that has data to specifically address weird edge cases. This is a good place to run integration tests to make sure everything's working together like you expected.

Once you get ready to deploy your code to production though, you need to make sure that all of your secrets are correct and encrypted, your data is correct, and there aren't any patches left for you or any of the other teams to make.

Tools and Testing

There are a lot of CI/CD tools out there and they all have great features. Some will be easier to use with your projects than others so you should check out a few of them before making a decision. There are open-source tools and enterprise tools depending on what you need.

Remember, your typical pipeline flow will look like:
Build -> Test -> Deliver -> Deploy

A few of the popular tools include: CircleCI, TravisCI, Jenkins, and GitLab.

import conducto as co

def cicd() -> co.Serial:
    image = co.Image("node:current-alpine", copy_dir=".")

    cra_node = co.Exec("npx create-react-app conducto-demo")
    installation_node = co.Exec("cd conducto-demo; npm i; CI=true; npm test")
    build_node = co.Exec("npm build")
    start_node = co.Exec("npm start")

    pipeline = co.Serial(image=image, container_reuse_context=co.ContainerReuseContext.NEW)
    pipeline["Make CRA..."] = cra_node
    pipeline["Install dependencies..."] = installation_node
    pipeline["Build project..."] = build_node
    pipeline["Start project..."] = start_node

    return pipeline

if __name__ == "__main__":
    co.main(default=cicd)

This is a simple pipeline, but it holds all of the stages we've discussed. The only thing to do from here is add more detail and more tools to get it to the state you want.

Work on Adding Automated Tests

Without automated tests, you can't trust that your pipeline will deploy good code every time. It would be like automatically sending bugs to production.

Taking the time to add good tests is a huge upfront cost and the pay off lasts for years. You'll have more maintainable code that's easier for new people to get started with. It gives you some peace of mind that there aren't any regressions from new changes.

Then you'll need to make sure that you're doing security testing. That usually means adding tools like Arachni or Snyk to your pipeline in the build phase. This does a scan of the entire application, checking for vulnerabilities and creating a report. Security testing early in the CI/CD process helps you stay ahead of breaches and keeps you clear in compliance audits.

Adding some integration testing in the delivery phase will help you catch any services that are not responding or are throwing weird behavior. These can be automated with a tool like Gauntlt and alert you of issues before they get to customers.

There aren't a lot of automated tests for the deploy stage. At that point, you would need to invest in some type of penetration testing with different sets of tools. Many hacker tools can be automated in some ways, but they aren't things you want to run on the same server customers are hitting.

As long as you're including unit tests, security tests, and maybe some integration tests depending on your application, you have covered the basics of automated testing for you pipeline. Most other types of testing will take a long time and slow down deploys.

One of the things you'll have to watch as you add tests is that you aren't slowing down the process too much. There's a balance to adding tests and keeping a pipeline "fast enough." The goal is to keep it under 5 minutes, but if it has to be longer make sure that you've added all of the optimizations you can.

Start Tracking Metrics

Once you have your process defined and pipeline built, you can start tracking the ways this DevOps strategy has improved things. Are there less support issues coming in? Can you get things together for an audit quickly? Is it really faster getting changes out?

These are just a few of the things you can check for. You can also check if your resource consumption has changed or if you need some of the services you've been using. This goes back to the reason why you started trying to implement DevOps in the first place. These metrics will prove that all of this work was worth it.

Here's a full list of the 4 key Delivery Metrics you should watch.

Final Thoughts

Switching to a leaner form of DevOps when there are distinct teams in place takes time and patience. There are a lot of things that need to be considered before a change this big is implemented. Even if you're starting a project from scratch, it's still challenging to build a CI/CD pipeline. This will evolve over time the same way your application does.

The true benefit comes when the developers push changes and anyone else can deploy them when it's time. That's the joy of a shared workflow. Some organizations will have the product team handling deployments because all they have to do is click a button and they know the changes will make it to the users. The point of making a DevOps workflow strategy is to let anyone, at anytime deploy changes to production quickly without problems.

Once you have it up and going, it will be hard to justify doing a manual deploy again.

Milecia McGregor is a software engineer and international speaker.

Want one platform to rule them all? Try out The Ops Platform with a free demo.