If you have an application deployed to a server, you are already doing DevOps. Stay with me on this. First, we need a level set, what is DevOps? There are multiple definitions (AWS-What is DevOps?, Atlassian-DevOps, Good, but Long read) and multiple flavors (DevSecOps, DevQAOps, DevSecQAOps,…), but if we boil the definition down; DevOps is the about the coordination and communication between teams to develop and deliver a product to consumers.
Back to my original statement, you are already doing DevOps. You must have a process in place to get a developed application onto a customer-facing, production server. This is true in a one-person codeshop or a Fortune 20 IT department. The differences could be the number of people involved, regulations followed for compliance, number of buttons pushed,... you get the idea. There is still a process that is followed and communicated to the departments involved that always includes Development and Operations.
Most organizations have a development group responsible for maintaining and developing an application, and an operations group maintaining the infrastructure the application runs on. The development and deployment process usually goes like this:
- Development has a new version of the application they want to deploy that adds new features and corrects bugs.
- Development creates a new artifact containing the release candidate of the application
- Validation of the release candidate
- Sign-off the the release candidate
- Hand off of the release candidate to Operations
- Operations deploys release candidate to production
- Production validation
- Development makes the release candidate the current production version and cuts a new dev version.
- Rinse and repeat.
I will say that even if all these steps are manual, you are practicing a form of DevOps. Is there room for improving this form of DevOps? Definitely, but we all have to start our journey somewhere.
DevOps is not a tool you can purchase. It is not a one time company initiative that fixes all the organizational ills. It is an ongoing process and organizational mindset. It sounds intimidating, but it should not be if we break it up into small steps. We can start by automating something in each step. It could look like:
- Development automatically compiles a list of features and bugs corrected from the work items tracked during the development cycle. This becomes the release notes
- Development automates the build process to create the artifact. This would include version information so deploying the correct version becomes easier.
- QA and Security can automate some or all of their application validations. Reports are generated from these validations and are made available to all to learn how to make the application better.
- The responsible parties could be automatically emailed to notify them a release candidate is ready for sign off.
- Operations can stand up an artifact repository like Nexus to provide a single, safe place to store release candidates.
- Deployments can be scripted to ensure consistency and prevent the introduction of errors.
- Validations from step 3 can be borrowed to run smoke tests on the production deployment to further ensure success.
- Version increment scripts and plugins can be used to ensure the application version is managed correctly.
With the exception of step 7, all of these tasks can happen independently of each other. All of this helps move the needle to a more automated DevOps experience. If only 2 and 5 are implemented, a CI/CD pipeline in the form of GitLab, GitHub Actions, Jenkins, etc can be introduced to orchestrate the release process. Each step can benefit from further automation to decrease turnaround times and increase feature deployments.
I have only outlined a generic example of a DevOps journey. I hope I have shown you that not only are you practicing DevOps, but you are not that far from having a more automated DevOps process. What kind of DevOps are you practicing? What can you do to improve it? Please share and continue the conversation in the comments.