The Basics
Most teams can probably split their developers into two major categories:
Developers, who handle updating the codebase, fixing bugs, and all around programming. You could also include other roles, such as web and UI designers in this category. In general, it includes anyone who is involved in actually building your product. SysAdmins, or the “Operations Team. ” These people handle updating servers with new code, managing both your public-facing and internal server infrastructure, and all around keeping everything up and running.
To put it simply, DevOps is all about integrating these two teams together (hence the portmanteau of a name). It isn’t going to make your developers into sysadmins, or vice versa, but it should help them work together.
Each aspect and phase is complemented with tools that make this whole process easier. DevOps is more than just tools and automation, and implementing a set of “DevOps tools” won’t automatically make your team work twice as fast, but these tools are a major part of the process, and it’d be hard to be as efficient without some of them.
While there’s a lot of of other buzzwords thrown under the umbrella of “DevOps,” the basic concept is pretty simple. When a team is working properly, DevOps generally flows like so:
To explain, we’ll start with the monitoring phase. This involves keeping an eye on your servers, watching analytics, analyzing logs, and identifying problems with your codebase. While a large part of this is code related, a lot of it falls on the business side of things as well. Are you effectively achieving your goals? Are your clients happy? This phase is all about finding out what’s wrong so you can set proper goals. Popular monitoring tools include Nagios, AWS CloudWatch, and analytics software like Google Analytics.
Perhaps you get a ticket directly from a client, and start from the planning phase. This is where you’ll sit down with your lead developers and discuss what needs to be done to complete a ticket. If you’re using software like Jira, you’ll probably break down a large ticket into individual stories and issues that can be tracked more easily and assigned to individual developers. If you’re planning a code sprint for the next week or two, you’ll want to have your plan clearly laid out to cut down on time spent reiterating code.
Rather than testing and building only once when everything is finished, in a DevOps environment, each developer will ideally submit changes to source control multiple times a day, whenever issues are complete or a minor milestone is reached. This allows the build and testing phases to start early, and make sure no developer gets too far away from the HEAD of the master source control. This stage is mostly about proper source control management, so having an effective git service like GitHub, Gitlab, or BitBucket are crucial to keeping continuous integration running smoothly.
You don’t have to deploy every commit to production right away, but quick automated deployments are a major part of being able to push rapid releases. Plus, it takes some stress off you operations team, allowing them to focus on more important things than manually updating servers with new code.
Once new changes are deployed, the cycle starts over again. Perhaps that new feature you added is causing the staging database server to work overtime, and might need to be marked for performance review and fixed before deploying to production. If everything flows properly, DevOps stops being a fixed series of steps and simply becomes a culture that everyone follows naturally.
Continuous Integration/Continuous Delivery Pipelines
Automation and tools are a major part of any DevOps environment. Perhaps the biggest tool to have is a Continuous Integration/Continuous Delivery (CI/CD) pipeline. This is an automated process that starts with source code and handles the process of building, testing, and deploying to servers.
AWS’s CodePipeline is a good example of this. Whenever a change is detected in source control (either GitHub, BitBucket, or AWS CodeCommit), it is sent over to AWS CodeBuild for building and testing. Alternatively, Jenkins is used quite often to handle this build phase.
Usually, once a build is completed, you’ll want to send it to a testing environment before heading directly to production. Even still, automating deployments to both testing and production servers will speed up iteration times significantly. In AWS’s pipeline, this is handled by CodeDeploy. Jenkins can also handle deployment, as well as software like Ansible.
All in all, a CI/CD pipeline can automate most of the DevOps flow, from build to deployment, making it a crucial piece for any team looking to work efficiently.
