DevOps
Overview
What We’ll Cover
Software Builds
DevOps, and other related disciplines
Principles of DevOps
Continuous Integration / Continuous Delivery
Traceability & Observability
Real-Time Errors
Application Performance Monitoring
Logs
Objectives
Understand the purpose of DevOps engineers in relation to Software Engineers.
Knows the purpose of Continuous Deployment / Continuous Integration.
Know the purpose of Application Performance Monitoring.
Be able to analyze performance monitoring dashboards.
Understand the importance of observability and can identify means of increasing observability within a web application.
Software Builds
What is a build?
A software build is a product that results from preparing, installing, compiling, and/or assembling the source code for a software project.
A release is a build that has passed all tests.
A deploy is a release that has gone live to users.
“It works on my machine”
Almost every line of code has at least one or many dependencies
Dependencies are details about the environment that the code is running within that enable the code to run successfully
Code Dependencies
The operating system (mac, linux, windows) and the specific version
The language the code is written in, and the version of that language that is installed
External libraries that have been installed that the code may depend on to run, such as the web framework (express!) or a helper library, and the version of that library
Github Commits as Dependencies
Often, there are several people working on one codebase
The order of different people’s commits is important
When new code is officially merged into the main project is important
Passing Tests is a Dependency
Software tests allow developers to add to an existing project without breaking existing features
If all tests don’t pass after the code has been modified, the code should not be added to the project
In order to create a software build, all tests must pass.
Writing Code is the Easy Part
Getting code to run in a single environment can be difficult
Think about installation issues you have had on your own computer
Getting code to run on several people’s machines is more difficult
Getting code that is constantly changing to always run in the production environment might be the most difficult
DevOps
DevOps - A Philosophy
DevOps, or Developer Operations, is the idea that writing and enabling the “running” of code in multiple environments should go hand in hand
In the past, developers were not always responsible / involved in enabling their code to run in the production environment
Now, developers are more integrated into the software build process and are responsible for ensuring their code meets requirements for production builds
DevOps is New!
The idea of DevOps emerged in 2008/2009
The roles, practices, and tools of DevOps are constantly shifting
While there are many common practices, every company is a little different
DevOps, AKA…
Site Reliability Engineering
Production Engineering
DevOps Engineering
Infrastructure Engineering
Systems Engineering
Not all the same thing, but all deal with issues relating to enabling code to run in non-local environments
Principles of DevOps
Environments
Production or “prod” is the server that is live, open to the “public”, responding to actual users
Staging is a private, internal-only copy of the production server
Allows engineers to “stage” their changes before they go live to users
The last step to check to make sure nothing will go wrong when new code is deployed to production
Local or “dev” is the developers’ own computer, or a virtual machine shared by all developers on a project
CI/CD
Continuous Integration (CI): With every code contribution for a project, automatically check to make sure the code passes all tests and will run in the production environment
Continuous Delivery (CD): Deploy new builds frequently to a staging server- perhaps daily or at least weekly
Automation
Modern DevOps is centered around building infrastructure
Automation in the build process that automatically ensure code can run successfully in production
Automation on the production server to track errors and issues that happen as users are interacting with the software
Automated monitoring to understand how users are interacting with the software and learn about potential issues or possible improvements make
Automated scaling in the case of increased user / request volume on production server
Collaboration and Joint Ownership
While there may be a separate team responsible for building application infrastructure, DevOps requires everyone, from developers and product managers to QA Engineers and DevOps specialists to take responsibility for issues relating to builds/releases.
CI/CD
Containers
Containers are like virtualized operating systems that can ensure consistency between different environments
CI/CD Server
A server that exists to automatically test new code in a production environment as soon as that code is merged into a project
This can take time and significant CPU is the developer has to do it on their own machine
A separate server allows this process to happen “in the cloud”
Faster and easier for developers to contribute new code
CI/CD Pipeline
A CI/CD pipeline is a set of processes and checks all glued together using specialized tools for continuous integration
Traceability & Observability
Traceability
tracing where a product (code, design, test, etc.) comes from, where it’s going, and why throughout the development lifecycle
example: tying a function back to a user story
example: tracing a test forward to figure out how its success supports the app requirements
all about understanding how the small, detailed decisions are informed by the high level requirements
In this lecture specifically, we’ll be looking at the traceability of errors and how we can monitor them.
Observability
Being able to explain what’s happening inside an app only by looking at its outputs. A system where you:
know the inner workings of your app (from outputs)
know and understand the state that your app is in (from outputs)
understand what’s happening even if it’s new and/or unexpected
Why?
Apps are just becoming more and more complex. The better we can track what’s going on, the better we can fix bugs and the better we can get our apps to run.
How?
Errors aren’t inherently easy to track in production. So we have to think about how we are going to design our code to make it “debuggable.” We’ll also be talking about how to set up monitoring tools to help us see these errors.
Real-Time Errors
We can track errors that are happening in live software. This is part of how we can keep track of the experience that our users are having.
Local vs Hosted Errors
we can pick up on lots of problems in the dev environment
but some things will only pop up in the live environment
these errors are often more difficult to figure out
we’ll talk about tools that will help us track these
Software Development Life Cycle Review
Where are we?
Planning
Analysis of Requirements
Design
Implementation
Testing & Integration
Maintain
Application Performance Monitoring
what it sounds like – monitoring how an app is performing
key: we’re talking about a live application that could potentially be serving thousands of users, so problems are multiplied
what could these problems be?
What We’re Looking For
Bugs
duh!
we can see our actual errors using APM tools
these will pop up anytime something doesn’t work as expected
sometimes this can be a full-on error that messes with how the whole app is working, other times we can see when things just aren’t working how we expect
Bottlenecks
a point in the app where work stops or slows down
creates an imbalance in resources – overworked at the bottleneck and underworked in later stages
Latency
the amount of time information takes to travel from one place to another
like getting a response from a server, we send a request which takes time and then the server sends a response which also takes time
not inherently bad since some things just take time, but if latency increases too much, you can have a problem on your hands
Down Time
the amount of time that an app or service is not running/functioning
this can cost companies lots of money so we try to avoid it as much as we can
Logs
Logs are often how we are going to see these problems. Inside of whatever tool you’re using, you’ll be able to see the logs.
What Are Logs
Logs are files that keep records of what’s happening in the app.
We can see these on the server where the app is hosted or in a monitoring tool
If you’re on a server, you need permission to see the log files
How are they different?
These logs are similar to the console logs that we’ve been using but they’ve often got more information. And because the app is running constantly, these logs are coming in all the time and they’re being saved to the log files instead of just printing out.
We’ll be using a tool called Rollbar to monitor hosted apps in the demo and lab!