DevOps has been somewhat of a buzzword on the tip of many developers’ tongues for quite some time. Many job descriptions for software engineers now contain a line about DevOps in some form or fashion. Companies are hiring dedicated DevOps Engineers to meet this need in their workforces. It’s almost certainly a requirement if you want to call yourself a “full-stack” developer these days, and you can’t browse technology blogs or news without stumbling across several articles regarding DevOps.
But what really is DevOps? What does it mean to have it as a skill, and how can a software engineer practically learn and apply it in their work?
What is DevOps?
DevOps is short for “development operations”. It is a term to describe the activities that revolve around software or application development that are not coding or testing. The greatest programmer in the world can write amazing code, but if he can’t build and deploy it out to the appropriate environment, no one can consume it the way it was intended, which is why a lot of companies hire DevOps consultants. Source control, build and deployment tools, work item tracking, and automated testing tools all fall under DevOps. Coding may be at the core of development, but DevOps is the vehicle that drives the software development lifecycle.
DevOps isn’t just a set of tools, but rather the process around driving software development.
This diagram is an example of a core development loop. A programmer may spend a large amount of time in his Visual Studio environment writing and running his code locally, but it is only part of the picture.
Using source control and implementing a source control strategy is necessary for smooth collaboration when you have more than one developer modifying the same code. Developers can receive each other’s changes as they commit their work regularly to a shared repository. Conflicts in code can be resolved gracefully. Relating code to specific commits and authors adds transparency to the development of the software. Tools for code reviews add a layer of quality assurance to the development cycle, giving team leads and senior staff the ability to ensure that only good, well-written code enters the main codebase. Code can be versioned to relate to specific releases, features, and tasks, giving managers and stakeholders visibility into the state of the development cycle. Tools such as GitHub integrate seamlessly into the development environment, bringing these tools into the fold.
Integration and Deployment
A key part of DevOps involves the process of deploying the software to various environments. While developers can always build and run versions of a piece of software locally, making deployments of these versions available to other environments is necessary for testing, verification, and ultimately delivery of the final product. Deploying versions of software manually can be cumbersome, but DevOps tools such as Azure Pipelines encapsulate and simplify the process. By defining build and release configurations, these actions can be re-used and automated multiple times, across multiple environments. Often it is desired that the most recent version of the main codebase be deployed to a development environment for testing. This deployment can be defined once, re-used for every version update, and automated when it detects new code in the source control. This process is what is known as continuous integration and deployment, or CI/CD for short.
Taking the time to set up CI/CD on a project beforehand saves the developer time in the long run from having to manually deploy the software. Having a development or sandbox environment be the target for CI/CD gets versions of the software into the hands of your QA staff early and often, which gives them more to work with and increases the quality of the software overall. It also gives stakeholders potential early access to versions of the software, which could elicit better requirements, feedback, or direction. This collaborative approach to the development cycle falls in step with the Agile approach to the software lifecycle when small, deliverable iterations of the software are key to maintaining sustainable velocity on a project.
Another major tenant of DevOps is tracking features, tasks, and bugs. Even the smallest of teams or solo projects have a list of features needed to complete the software. Every development effort can be broken down into a list of discrete tasks. Tracking all of this work can be cumbersome, especially to a developer who is “in the zone” as it were, focused and getting good code written, but tracking progress, velocity, and potential blockers are crucial to the development cycle, especially when you have multiple people divvying up the work and collaborating on a single codebase. DevOps has its place in facilitating work tracking. Commits in code can be associated with specific tasks, making it simple for a project manager or stakeholder to see activity on a feature.
As new features enter the project, bugs are found, or changes, are proposed, these can be entered into a work item tracking system such as Jira or Azure Boards. Project managers or team leads can then assign out the tasks and plan them for the appropriate sprint, based on the timeline and the resources available. Code reviews, automated testing results, and deployments can automatically trigger and assign new tasks, notifying developers of new work to perform, keeping their task list healthy, and moving forward. By utilizing these tracking tools effectively teams can make the best use of their time and skills, giving themselves the best chance to deliver the product on time in a good and accurate state.
DevOps: Not Just a Buzzword
DevOps isn’t just a buzzword. It’s a powerful process and mindset that adds value to any software engineer’s toolbelt in the modern technology landscape. It crosses industries, languages, and frameworks. It requires some learning and a shift in approach for the developer who hasn’t yet put this process into practice but adds a permanent and highly practical tool to his or her repertoire.