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 isn’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.
#cicd #product-management #product-development #engineering #devops
