What is DevOps?
The Business Value of DevOps
Who's using DevOps?
The course is part of these learning paths
Modern software systems are becoming increasingly complex, to meet quality, availability, and security demands. And these systems are changing rapidly to keep up with the needs of end-users. With all of the changes, how do you ensure stability, quality, security, and innovation? In this course, we look at how the DevOps philosophy can provide a holistic way to look at software development, deployment, and operations. And we will provide some tenets to help improve quality and stability.
You will gain the following skills by completing this course:
- Learn why automation, culture, and metrics are essential to a successful DevOps project
- Learn how DevOps can positively impact your business's bottom line
- Learn which major companies are successfully utilizing DevOps in their own engineering processes
You should take this course if you are:
- A newcomer to the DevOps or cloud world
- Looking to upgrade your skills from a conventional software development career
This Course Includes
- Expert-guided lectures about DevOps
- 1 hour of high-definition video
- Solid foundational knowledge for your explorations into DevOps
What You'll Learn
|Video lecture||What you'll learn|
|What Is DevOps?||In this lecture series, you'll gain a fundamental understanding of DevOps and why it matters.|
|The Business Value of DevOps||Need to justify the business case for DevOps? This is the lecture series for you.|
|Who's Using DevOps?||Find out who's using DevOps in the enterprise - and why their success matters for your own organization.|
If you have thoughts or suggestions for this course, please contact Cloud Academy at email@example.com.
Welcome back to our Introduction to DevOps course. I'm Ben Lambert and I'll be your instructor for this lecture.
In this lecture, we're going to summarize what we've covered.
Throughout the course, we've talked about a few of the DevOps tenets. We talked about culture, automation, and metrics.
In our first lecture, I put a definition to what's referred to as DevOps, and I did this to provide a shared vocabulary.
I said DevOps is a philosophy of the efficient development, deployment, and operation of the highest quality software possible.
And I mentioned that the ambiguity around DevOps is a strength because it allows companies to adopt the philosophy however supports them best. So a company can strive to improve both their software's quality and the development, deployment, and operational pipeline without being bound to specific technologies or to strict rules that may not work universally. Each company can tackle the different parts of the pipeline in the way that best supports them. However, over the years, there have been a few practices that stand above the others.
There are a couple of practices that seem to be fairly universal when talking about companies that have adopted a DevOps philosophy.
The first is continuous integration, or CI. CI helps with both the goals of efficiency in our development, deployment, and operational pipeline, and the goal for higher quality software.
CI is a process where developers commit their code throughout the day to a shared repository, and each commit is automatically built and tested, and the results are sent back to the developers. By automatically building and testing for each commit, you can identify errors right away.
Let's look at a real example of a continuous integration server using Jenkins. This isn't going to be an in-depth look at Jenkins, however, it should serve as an intro to help you understand the value in CI.
This is Jenkins. So, CI is all about findings problems early. Jenkins allows us to set up a pipeline that can build and test our code. And if all went well, it can create an artifact that we can use for later.
This is my simple pipeline for this app. What it does is it attempts to install any dependencies with pip, a Python package manager, and then it runs all of the tests. And if all that was successful, it will create an artifact. An artifact is really just all of your code compiled into one location. Let's see how Jenkins automatically picks up my code changes and runs through the CI pipeline.
We'll start with a simple change that shouldn't break anything. What we'll do is we'll just add a function that returns a string, and then we'll commit it with Git and push it to GitHub. See how it picked up on the changes automatically? It's set to pull Git and look for changes every 60 seconds. Let's try again and cause a failure and see what happens. I'm changing this string here because the test is expecting the string whirled with an exclamation point. So Jenkins considers this a failure and will notify the developers. You can have it notified via email, HipChat, Slack, or really however you want. Now let's fix that error and have Jenkins run through the process again. There. Now it's all fixed and Jenkins is happy again.
Okay, so this was just an overview of a CI server and how it can help you improve your code's quality.
The next commonly used practice picks up where CI leaves off and it's called continuous delivery, or CD.
CD means that you can push a button and deploy your code.
CD should pick up the artifact that your CI server created and use that in the deployment process. By using the same artifact throughout the different stages, you reduce the potential for problems caused by building your app multiple times throughout the pipeline. By rebuilding at different stages, you risk inconsistencies that could be caused by differences in software versions or changes in your build process that may not be applied to each phase.
Okay, let's take a look at what CD might look like with Jenkins. As you can see, we have a separate project for our deployment. And when we click on the Build button, we're presented with some options, including the environment we want to send it to and the version of the build we want to send. So once we select the version we want to send and click Build, it's going to deliver that to that environment. So you can see there number six is running, and once we refresh the page, it's completed.
Now that was just a crude example. It doesn't show any details of how we deployed it, and that's because CI and CD are such broad topics that they really have to be covered in a separate course.
CI and CD have become kind of the de facto standards as the current best methodologies for implementing high quality software, which is part of the DevOps philosophy. In addition, they provide a level of efficiency at all of the stages of the development, deployment, and operations pipeline, which is another part of the philosophy.
When DevOps is done right, you won't hear the word DevOps related to the work you're doing. You'll talk about the different stages of the development, deployment, and operations pipeline since they relate to real work. It would be like saying that you're “humaning”.
Sure, you are a human, and by definition anything you do is human behavior, however you would only ever talk about being a human in a larger context. Again, the same is true for DevOps. All DevOps will do as a philosophy is to provide you with a better context for looking at the software development, deployment, and operations pipeline.
So to wrap up this course, DevOps is a philosophy of the efficient development, deployment, and operation of the highest quality software possible.
Three common tenets that support the philosophy are culture, automation, and measurement.
We talked about how your company culture needs to support its goals and its employees if it's going to be successful.
We talked about automation and how it reduces human intervention to a minimum and how it adds a level of consistency and predictability, scalability, and quality.
We talked just now about CI and CD, and how they're a big part of that automation.
We talked about some of the metrics that will help you to determine if your efforts are having any impact.
We talked about some of the benefits of a successful DevOps strategy, including improved lead time, improved stability, and reduced operational costs.
And we talked about some of the companies that have successfully adopted DevOps as a philosophy, even if they don't call it DevOps.
In future courses, we'll likely cover things like CI and CD more in-depth so you can start putting what you've learned into practice.
I hope this introduction to DevOps has been useful to you and that it's helped to show that DevOps is really more than just a buzzword.
I'm Ben Lambert. Thanks for watching.
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.