We're Growing Our Team!Apply Today

The Fundamentals of DevOps

Getting Started with DevOps

Est Reading Time: 11 min

Devon Bleibtrey
Devon Bleibtrey

Apr 13, 2020

Welcome to the world of developer operations, a massive ecosystem of tools, processes, and ways to enhance every team across your organization. The best way we know how to define DevOps is as the supply chain management for software with a culture of experimentation, learning, and iteration, prioritizing the areas of the system where the most significant impact for the team and business can be made.

As with traditional supply chains, which transform raw materials into final products, a software pipeline takes commits of code generated by engineers, developers, user experience experts, as well as others, and transforms those commits into final products that can be shipped out to servers, edge devices, or other units which interface with customers or other programs. As in supply chain management we are working to actively streamline our development activities to maximize customer value and gain a competitive advantage in the marketplace.

Where to get started depends on you, your team, the product you're working on, and the primary objectives of your organization. To chat about how you and your team can improve your developer operations journey, grab 30 minutes on our calendar or hit us up on twitter @nextreleaseio.

4 Key Metrics

It's easy to get distracted by the shiny tools and toys within the DevOps world and get sucked into the latest trend or fad. There's nothing wrong with being cutting edge or adopting new things, but where we suggest you start is looking at the throughput and stability of your existing operations. To measure these, you can use the same gauges used by Google and the DevOps Research and Assessment organization:

  • For throughput measure your:

  • For stability measure your:

These four metrics will help you understand where you're at today and where you'll need to focus your efforts to improve your operations. Once you have these measurements, they'll act as a ballast to help keep you focused on solving issues that bring value to your team and avoid adopting tools just for the sake of it.

Depending on where you are at with each of these metrics will determine where you start your journey. The first thing to make sure you pick, if you haven't already, is what version control system you're going to use. We recommend git as most of the work being done in developer operations revolves around git. If you are using an alternative SCM, you'll probably have to roll more of your own custom solutions. Regardless of your choice, you'll need an SCM to:

  • Integrate selected DevOps tools with
  • Provide traceability of what changes within your product
  • Easily revert changes and merge conflicts

After you have an SCM, you'll want to choose which workflow for managing code changes your team follows. There are workflows for every type of team, product, and deployment style. We provide an overview of a few of them in a previous article on release strategies to help you get started with choosing one that works for your team.

Beyond these fundamentals some other areas you'll want to start looking at are:

  • Which continuous integration (CI) or continuous deployment (CD) environment aligns with your team's needs?
  • Which cloud or IoT platform or combination of them support your needs?
  • How can you automate your deployments to your various environments?
  • How can you virtualize all of your development environments, staging environments, and production environments to be the same?
  • How will you monitor deployed applications?
  • How are you securing your development pipeline and the products moving through it?
  • Is the culture of your organization causing barriers?
  • How do you measure the changes you make to your pipeline to check their impact on your measurements of success?

Building, Testing, & Releasing: Choosing a CI / CD Solution

Like the rest of the DevOps ecosystem, there are an endless amount of CI/CD solutions to pick from, CircleCI, Jenkins, TravisCI, Azure Pipelines, AWS CodeStar just to state a few.

We use CircleCI internally, which was initially driven by their early adoption of supporting Docker containers. You'll want to choose the solution that best fits your team's needs. Some questions to ask when choosing a CI/CD are:

  • What existing platforms are we using, and which CI/CD platforms easily integrate with those?
  • Do we have unique testing requirements such as MacOS build support, IoT CPU architecture support, or cross phone mobile app support?
  • How many teams are we rolling this solution out to, and should we limit the configuration options to reduce the overhead of managing the deployment?

We recommend picking one, trying it out, see what blockers or issues you run into, and then pivot or persevere based on what you uncover. DevOps is about learning what works, what doesn't and using that to iterate until you've improved a system enough that it's no longer the area you can make the most significant impact for your team.

Deploying: Cloud, IoT, and Hosting Platforms

Most people have at least heard about Amazon Web Services (AWS), Microsoft Azure, and Google Cloud. Still, there are a plethora of other platforms and niche solution providers such as Particle, Convox, Heroku, Netlify, and Docker Cloud.

Recently, the topic we have been tackling the most is which platform to use for various IoT deployments such as connected vehicles, smart manufacturing gateways with distributed sensors, and fleet management devices. Each vendor seems to have a unique way of managing automatic deployments to edge devices, and are still missing some features critical to organizations that have compliance concerns with over the air updates. Each of the cloud platform providers has very mature systems to enable you to roll automatic updates of web applications, both frontend, and backend.

We use Heroku paired with Netlify due to the ease of use and scalability. For solutions that have edge devices involved, we usually need to deploy some of the Apache project platforms using Kubernetes and will lean towards using AWS, Azure, Google Cloud, or some combination.

Some getting started questions are:

  • Which platform will allow my team to get our project in front of customers the fastest and have the lowest amount of maintenance?
  • Does our virtualization tech allow us to switch between platforms rapidly?
  • What plugins and add-ons do we need for our application to work (Databases, caches, edge devices, third party integrations)?
  • How easily are our needed plugins and add-ons integrated and managed on a given platform? Are there any performance concerns? For example, you won't want to host a database or a cache in one platform and have your application running in another.
  • Does the platform provider's data policies align with ours?
  • What type of security features does the platform provide, if any?

Operating: Virtualizing Environments

Traditionally you'd need to set up a complicated virtual machine to abstract your development environment and achieve any semblance of consistency between development, staging, and production environments. Over the last decade, there's been a renaissance, and there are now multiple ways to ensure developers are developing in a replica environment of the actual deployments. We recommend starting with Docker and its configuration management system called Docker Compose. If this is overkill for your project, then take a look at some of the community packages within the language you're using; for example, Python supports venv. This won't help you with some of the infrastructure challenges, but it might be the right choice for your team based on where you're deploying to and what you're deploying there. Others use tools such as Puppet, Ansible, and Chef. While these tools provide some interesting features we've found them to be overkill for most projects, but there might be a use case where you'll need them. Here some of the questions to think about are:

  • Where do we ship our software?
  • What does our software run on when we're developing locally, deploying to staging, and operating in production?
  • What overhead, if any, is maintaining the virtualized environments going to add?
  • What issues are being caused due to inconsistencies in local envs, staging envs, and production environments?

Monitoring Application Performance

Developer operations continue into managing your product deployments. You'll want some form of an application performance monitoring (APM) package embedded in your application to enable a reduction in identifying and resolving issues that make it out to production. There is an APM for most everything, Sentry, New Relic, and Dynatrace are some of the leaders in the application monitoring space. New Relic, Dynatrace, and others also provide infrastructure monitoring if you manage a lot of your own architecture. Then there are more generalized monitoring tools that you can transform into APMs such as Elastic, AWS Cloudwatch, Splunk, Nagios, and DataDog.

We use Sentry to monitor our frontend and backend applications for unhandled exceptions and error logs. Paired with Timber for more general logging, we're able to identify issues impacting our customers within seconds, replicate them, and resolve them as fast as we can figure out the solution. Couple of things to think about when selecting your APMs are:

  • Do we manage our own infrastructure? If so, what parts of it are creating the most issues and need monitoring first?
  • How complex is our deployment? If there are a lot of moving parts, you might need a tool with granular query capabilities.

Securing Your Pipeline & Products

DevSecOps is the emerging word being used to communicate the importance of merging security and developer operations. When doing DevOps it's essential to protect both the product you are building as well as the pipeline you're making it with. As your development pipeline matures you'll be sharing data between systems, relying on various tools to achieve the features your team needs, and will probably be running solutions on one or more platform. This makes your pipeline as ripe a target as your product itself and incidents can cause massive problems if not planned for. Security is one space within DevOps that still hasn't fully matured. There are some great tools out there for incident planning, such as OpsGenie and other tools for static code analysis like WhiteSource and BlackDuck.

We recommend you start by doing a high level risk assessment where you document as many vulnerabilities about your toolchain and product you can think of. A few things to cover when doing the assessment are:

  • Who has access to what code?
  • How do we scan our product and pipeline for vulnerabilities?
  • What is the plan for when something unexpected happens (incident response plan)?
  • How is our and our customer's data protected?

After completing the risk assessment, prioritize the risks based on the potential business harm each could cause, then begin trying to alleviate the top priority risk. After you tackle the first couple of top threats, do another risk assessment, and re-evaluate your priorities. We recommend conducting one every quarter or two as priorities, and potential impacts change as the pipeline evolves with the product.

Continuing Your Journey

We're super excited that more people are utilizing DevOps to improve their team's performance. If you have questions or would like some help with your team's operations, we're happy to jump on a call or chat about it. You can schedule some initial time, email us, DM us on twitter, or hit us up on live chat here on the site.

One of the more challenging parts to overcome with DevOps is existing cultural norms within an organization. As your team evolves, you might start to run into some of them. We'll cover techniques for overcoming these challenges in future posts, but here are some of the common traits you might need to eventually start moving to the right in a way that aligns with the unique challenges of your industry.

Low cooperation Modest cooperation High cooperation
Messengers "shot" Messengers neglected Messengers trained
Responsibilities shirked Narrow responsibilities Risks are shared
Bridging discouraged (siloed departments are advocated and enforced) Bridging tolerated (working between departments is tolerated) Bridging encouraged (cross functional teams are the objective)
Failure leads to scapegoating Failure leads to justice Failure leads to inquiry
Novelty crushed Novelty leads to problems Novelty implemented

The table above comes from a study done by Professor R Westrum, from the Department of Sociology at Easter Michigan University. The study was called A Typology of Organizational Cultures and has been confirmed by subsequent studies done within other top-performing companies such as Google to show what types of teams perform best. Those having more traits associated with the last column outperform those with more attributes from the first column.

Keep on measuring, learning, and iterating so you can always have a new problem to wake up and solve!

Automatic Release Notes. Zero Effort.

Sign up today with instant, no-hassle setup. No credit card required!

Sign Up Now