Skip to content

Intro to DevOps, Pipelines, and Deployment

Foreword to Pipelines

Software is meant to be used, tested, maintained, and documented by teams of engineers. Like all organizations, it always a challenge of scale and coordination.

Consider the following questions:

  • How do you ensure user have the latest version of the software?
  • How do you make sure the code stays organized and readable so that new developers can pick up the project?
  • How do you ensure new features don't break the project - especially when it's deployed to users?

You might be tempted to believe that this is the job of some "project leader". But keeping the record straight by "word of mouth" does NOT scale. It's easy when it's your small team of 3 engineers, difficult at 7, and impossible at 100 or more.

For companies with 50+ engineers, 6 separate new features and sub-projects, and 100000+ users, there is no one human alive that can get a handle on every situation. Cleverly designed automation is a necessity to keep the company going, which brings us to Pipelines.

Pipelines come in many forms and tools but all of them have the same primary goals:

  1. Allow large groups to add code to the codebase while organizing the different versions, and maintaining the code structure / documentation
  2. Deploy new code and data architecture (databases, servers, etc) seamlessly with ways to address bugs and fatal crashes

Depending on your team/company, you may find DevOps roles which focus entirely on these aspects rather than new features (i.e Quality Assurance or DevOps Engineer). We've covered good embedded software practices on an individual design scale, but, in this section, we'll cover how to enforce these practices with dozens of engineers and hundreds or even thousands of devices involved.