Let’s start with the what. DevOps, it’s an amalgamation of software development and IT operations. You may have a good enough idea of what it involves at this point. If you don’t, sit tight; I will attempt to go over both the formal definitions as well as opinionated takes on how I have seen it used.

Now on to the why. Essentially, combine agile (referring to agile software development) culture in the humans, principles in process and design, and practices in the daily tasks. It is not a question of whether to carry out DevOps, but how best to do so. DevOps is simply a cog in the machine that is software.

Okay, let’s dig in.

The problem

Before I get into listing and naming principles which you could get from countless blogs, I want to visit a real problem which can be addressed by DevOps to put it into perspective. Picture this, you work on a team to develop and support TheyTube. Yes, it’s a cheap, woke rip-off of YouTube, but let’s roll with it. You finished a new feature last week, one which you are particularly proud of. Your sense of pride, unfortunately, is hampered by the ticket that just came through, outlining a substantial gap between how most of the users use your feature and how you intended and designed it. This means that you need to go back to the drawing board, figure out how to align expectations, implement the changes, and get it to the users as fast as possible. After all, the top brass aren’t thrilled by having half-polished features out there, lowering general satisfaction with your product.

So far so good, though, right? This is just part of supporting a live software product. Well, yes, but there are several issues which you are far too aware of which are going to make this harder than necessary. Getting the new version coded up is going to be the easy part. After that is where your pains begin. Without a proper automated test process, you are left with trying the feature out yourself, getting your colleagues (who are at this point getting rather tired of this) to try it as well, and setting up a staging environment (manually) with the latest version containing your new feature and sending it off to QA for a sign-off. We’re not done yet, though—not even close. After testing, you have got to get it out to the users, and that is not a task you are particularly looking forward to either. The process begins with contacting the responsible for releases and agreeing upon a day and time to carry it out. Following this, the next step involves building the release, uploading it to the server, and manually stopping the old version, removing it, and replacing it with the new version. This means downtime for the users, as well as hell to go through in case a rollback is required. At this point you may think to yourself, “That’s not optimal, but everyone has to do things they do not enjoy at work.” Well, once you’ve gone through that hell, you have got to do it all over again when new feedback gets in, and then again, and—well you get the point.

Now imagine this isn’t a one-off. It’s the norm. Every new feature, bug fix, or update feels like trudging through mud. Your team is frustrated, leadership is unhappy, and users are losing patience. While this may paint a rather bleak picture, it’s exactly the type of situation where DevOps principles and practices can make a significant improvement.

Core Principles

At the core of DevOps there is a cycle of continuous tasks or processes (see figure 1). The reason for the cyclical nature is because one is never “finished” with DevOps as long as the product is alive and being maintained.

One thing you will notice throughout various articles is that there is no one single definition of DevOps or what it involves, as this depends heavily on the application and specific needs of the case. Thus, for the purposes of keeping things simple, I am going to use the 7 principles depicted in figure 1 as the guiding star for the core of what DevOps is. Given the continuous nature of the DevOps cycle, the word “continuous” is prepended to each of the principles in the figure, which make up “the 7 C’s of DevOps.”

While each of the principles is vitally important, I am going to focus on a select few which I believe can address the problems the team supporting TheyTube are facing.

Continuous Testing

The team is already doing a great job at continuous development. They are taking in user feedback and making changes to the platform to address the issues. The pain points begin once that part is done, and that is where continuous testing and integration come in.

The role of testing in software development is crucial and cannot be relegated to an afterthought if any sort of quality or reliability is expected. This is true for both the individual tests written as much as for the culture which drives the tests to be made. However, the key idea behind continuous testing is that tests should run automatically and frequently throughout the development cycle.

There are multiple types (or levels) of tests which are commonly used to help achieve an overall sense of security in the code that is being shipped:

• Unit tests: Testing individual units of code. This is generally testing an individual function or class to ensure it performs as it was meant. I have found that unit tests can be quite effective at rooting out the most low-level mistakes (think “off-by-one” or other simple logic mistakes).
• Integration tests: Testing multiple units of code together to ensure they work together as intended. This can be, for example, testing that multiple classes together perform the correct business logic. Integration tests generally run in-memory and rely on mocking classes which are not relevant to the test. Note, without proper unit tests in place, it can be more difficult to effectively locate the source of a problem revealed by an integration test.
• Component tests: Testing entire system components in a similar way to integration tests, but on a higher level. With component tests, we do not single out a cohesive group of units to test together or mock classes. Instead, we test that the entire system component (e.g. an API server or specific service in a microservice ecosystem) performs the business logic correctly. These often utilize network traffic for interacting with the component.
• End-to-end (E2E) tests: Testing the entire system simulating real-world users. This is a level above component tests because they interact with the system in the same way a user would. If the system includes a UI, this will often be included as the entry point for end-to-end tests.
• Others: There are multiple other types including smoke tests (check for clear signs of something wrong with the most important functionality), UI tests (test the user interface), and user testing (use individuals not involved in development to test the functionality).

Each of these types of testing has their time and place. Some projects do not need them all. For example, a simple parsing library (or package, depending on the language) may only merit unit tests given its limited scope. On the other hand, a similarly isolated library with many more moving parts (e.g. a web server bootstrapper) requires more levels of testing than only unit tests. In my opinion, it is generally a good rule of thumb to consider each necessary until a good enough reason to justify not having it comes along.

The key benefits of continuous testing come from integrating good principles of software testing into the DevOps cycle. We can gain a peace of mind by setting up good CI pipelines which run tests every time code should be merged and only allow merging when all tests pass. This way, we can be more confident that we have not unwittingly introduced a bug, given that good tests have been set in place. As you can see the two parts must work in harmony for any meaningful results, but when both parts do work, they can significantly improve efficiency by reducing the amount of time used on wild witch hunts for undetected bugs.

This article has begun the journey through what DevOps is, but there is still more to explore. In the next parts of this series, we are going to dive in to the next steps in the DevOps cycle, starting with continuous integration and delivery.