BossaBox

This is the playbook for engineering-playbook

Continuous Integration

image

We encourage engineering teams to make an upfront investment during Sprint 0 of a project to establish an automated and repeatable pipeline which continuously integrates code and releases system executable(s) to target cloud environments. Each integration should be verified by an automated build process that asserts a suite of validation tests pass and surface any errors across the developer team.

We encourage teams to implement the CI/CD pipelines before any service code is written for customers, which usually happens in Sprint 0(N). This way, the engineering team can develop and test their work in isolation without impacting other developers and promote a consistent devops workflow throughout the engagement.

These principles map directly agile software development lifecycle practices.

Goals

Continuous integration automation is an integral part of the software development lifecycle intended to reduce build integration errors and maximize velocity across a dev crew.

A robust build automation pipeline will:

Build Definition Managed in Git

Code / manifest artifacts required to build your project should be maintained in within your project(s) git repository(s)

Build Automation

An automated build should encompass the following principles:

Build Task

Unit Testing

Code Style Checks

Build Script Target

No IDE Dependencies

DevOps security checks

Build Environment Dependencies

Automated local environment setup

Document local setup

Infrastructure as Code

Manage as much of the following as possible, as code:

Decoupling infrastructure from the application codebase simplifies engineering teams move to cloud native applications.

Terraform resource providers like Azure DevOps is making it easier for developers to manage build pipeline variables, service connections and CI/CD pipeline definitions.

Sample DevOps Workflow using Terraform and Cobalt

image

Why

IAC DevOPS: Operations by Pull Request

Infrastructure Advocated Patterns

IAC Principles

Automate the Azure Environment

IAC CI Workflow

Developer Read-Only Access to Cloud Resources

Secret Automation

Infrastructure Integration Test Automation

Infrastructure Documentation

Configuration Validation

Applications use configuration to allow different runtime behaviors and it’s quite common to use files to store these settings. As developers, we might introduce errors while editing these files which would cause issues for the application to start and/or run correctly. By applying validation techniques on both syntax and semantics of our configuration, we can detect errors before the application is deployed and execute, improving the developer (user) experience.

Application Configuration Files Examples

Why Validate Application Configuration as a Separate Step?

What is Json Schema?

JSON-Schema is the standard of JSON documents that describes the structure and the requirements of your JSON data. Although it is called JSON-Schema, it also common to use this method for YAMLs, as it is a super set of JSON. The schema is very simple; point out which fields might exist, which are required or optional, what data format they use. Other validation rules can be added on top of that basic premise, along with human-readable information. The metadata lives in schemas which are .json files as well. In addition, schema has the widest adoption among all standards for JSON validation as it covers a big part of validation scenarios. It uses easy-to-parse JSON documents for schemas and is easily extensible.

How to Implement Schema Validation?

Implementing schema validation is divided in two - the generation of the schemas and the validation of yaml/json files with those schemas.

Generation

There are two options to generate a schema:

Validation

The schema has 30+ validators for different languages, including 10+ for JavaScript, so no need to code it yourself.

Integration Validation

An effective way to identify bugs in your build at a rapid pace is to invest early into a reliable suite of automated tests that validate the baseline functionality of the system:

End to end integration tests

Avoid checking in broken builds

Reporting build failures

Test Automation Data Dependencies

Code Coverage Checks

Git Driven Workflow

Build on commit

Avoid commenting out failing tests

Branch policy enforcement

Branch strategy

Deliver Quickly and Daily

“By committing regularly, every committer can reduce the number of conflicting changes. Checking in a week’s worth of work runs the risk of conflicting with other features and can be very difficult to resolve. Early, small conflicts in an area of the system cause team members to communicate about the change they are making.”

In the spirit of transparency and embracing frequent communication across a dev crew, we encourage developers to commit code on a daily cadence. This approach provides visibility to feature progress and accelerates pair programming across the team. Here are some principles to consider:

Everyone commits to the git repository each day

Isolated Environments

One of the key goals of build validation is to isolate and identify failures in staging environment(s) and minimize any disruption to live production traffic. Our E2E automated tests should run in an environment which mimics our production environment(as much as possible). This includes consistent software versions, OS, test data volume simulations, network traffic parity with production, etc.

Test in a clone of production

Pull request update(s) trigger staged releases

Promote infrastructure changes across fixed environments

Testing in production

Developer Access to the Latest Release Artifacts

Our devops workflow should enable developers to get, install and run the latest system executable. Release executable(s) should be auto generated as part of our CI/CD pipeline(s).

Developers can access latest executable

Release artifact is published for each pull request or merges into main branch

Integration Observability

Applied state changes to the mainline build should be made available and communicated across the team. Centralizing logs and status(s) from build and release pipeline failures are essential for developers investigating broken builds.

We recommend integrating Teams or Slack with CI/CD pipeline runs which helps keep the team continuously plugged into failures and build candidate status(s).

Continuous integration top level dashboard

Build status badge in project readme

Build notifications

Resources