Solving problems with DevOps
What do we mean by DevOps? Despite the term being used by the software community for at least 10 years (the first session of devopsdays, which is now the biggest DevOps-focused conference, was held in 2009), today, there is no single, standard definition that everyone agrees on.
When GitLab talks about DevOps, it’s referring to a new way of thinking about the SDLC, which focuses on four things:
- Automation
- Collaboration
- Fast feedback
- Iterative improvement
Let’s look at each of these in more detail.
The primary focus of DevOps is to automate as many software development tasks as possible. This removes the challenges associated with manually building, testing, securing, and releasing. But this is of limited usefulness if it exchanges those challenges for the hassles and expense associated with assembling a collection of manual tools. We’ll see how GitLab solves that problem later, but for now, just understand that a proper DevOps workflow is fully automated.
By fostering collaboration among all the teams involved with writing software, and among all the members of each team, DevOps helps dissolve the points of friction and potential trouble that happen every time the code is transferred from one team to another. If there’s no “wall” to throw the code over – if every step in the process is transparent to everyone involved with writing and delivering the software – everyone feels committed to the overall quality of the code and feels like they’re playing for the same team. Different people still have primary responsibility for specific tasks, but the overall culture moves toward joint ownership of the code and commonly shared goals.
Fast feedback might be the most crucial and revolutionary element of DevOps. It can be thought of as the result of two other concepts we talked about previously: concurrent workflows and shifting left. When you stop to think about it, those two terms boil down to the same thing: do all the building, verifying, and securing tasks as soon as possible for each batch of code that developers check in. Do them all concurrently instead of sequentially, to ensure that they happen at the far left of the software development timeline. And run all these tasks immediately for every chunk of new code that’s contributed, no matter how small. By running these tasks early and often, you minimize the size of the code changes that are tested, which makes it cheaper and easier to troubleshoot any software bugs, configuration issues, or security vulnerabilities found by the tests.
If you’re finding and fixing problems quickly, you’ll be able to release your software to customers more often. By getting new features and bug fixes to them sooner, you’re helping them benefit from the iterative improvement of your product. By releasing smaller code changes at shorter intervals with a lower risk of breaking things and needing to roll back, you’re living up to the catchphrase of making your releases boring. In this case, boring is a good thing: most customers would rather have frequent, small upgrades that pose little risk than infrequent, massive changes that have a greater chance of wreaking havoc and needing to be reverted.
By taking advantage of automation, collaboration, fast feedback, and iterative improvement, DevOps practices produce code that’s higher quality, cheaper to develop, and delivered more frequently to users.
How GitLab implements DevOps
GitLab is a tool that enables all the software development tasks we’ve discussed, using the DevOps principles we’ve just outlined. The most important trait of GitLab is that it’s a single tool that unifies all the steps in the SDLC under one umbrella.
Remember how shifting from manual processes to automated processes solved some problems but raised a host of new problems associated with automation? GitLab’s single-tool approach solves those problems as well. Consider the benefits of having the following single, unified toolchain approach:
- One license to buy (unless your team uses the free, feature-limited version of GitLab, in which case there are no licenses to buy)
- One application to maintain and upgrade
- One set of user accounts to provision
- One database to manage
- One GUI to learn
- One place to look – one radar screen, so to speak – to see the reports and statuses of all your build, validation, security, packaging, and deploy steps
So, GitLab being a single tool solves the problems you get from using disparate automation tools. Even better, the fact that it uses a single set of components and entities, all of which are aware of and communicate well with each other, enables and encourages the collaboration, concurrency, transparency, and shared ownership that are such critical aspects of DevOps. Once you have concurrent tasks, you get fast feedback. And that, in turn, allows for iterative improvement via boring releases.
The bulk of the rest of this book deals with the technique that GitLab uses to put those DevOps principles into practice: CI/CD pipelines. We won’t define what that term means quite yet, but you’ll learn all about it in future chapters. For now, you just need to know that CI/CD pipelines are where the GitLab rubber meets the DevOps road: they are how GitLab’s single-tool model performs all the building, verification, securing, packaging, and deploying that your code has to go through.
We’d be remiss not to mention that a large part of GitLab is dedicated to helping you plan, assign, and manage work. But that’s separate from the CI/CD pipelines, and therefore is beyond the scope of this book. We will touch on ancillary topics from time to time, simply because everything in GitLab is so interrelated that there’s no way to stay entirely within the boundaries of CI/CD pipelines. But most of the rest of this book will explain what GitLab pipelines can do, and how to use them.
