Back to Flutter Inner Source homepage
inner source

Continuous Integration on GitHub

A typical inner source service has:

This allows the local team or division to deploy to their preferred topology with their local security, service management and operational response setup and still leverage the value of a shared codebase with contributions from other divisions. This document describes how you can use GitHub continuous integration tools to automate the link between your shared codebase with its many deployments.

From Source to Production

Typically a service will follow these steps to production:

  1. Source: A codebase in a Flutter-Global repository with access controls and a branching strategy that allows cross-divisional contribution.
  2. Validate: Check proposed code changes in a pull request by running a series of tests that must pass: compile and/or lint commands, unit test suites, static analysis and security tool tests.
  3. Package: Resolve any external dependencies to build a new version of the desired deployment package(s) e.g. docker, rpm.
  4. Integration Test: Run available integration tests against the candidate deployment package with other dependent mocked packages.
  5. Publish: Publish the tested deployment package to a registry so it is available to all divisions.
  6. Deploy: Configure the package and deploy it to a specific topology (e.g. AWS, on-prem VM, k8s).
  7. Deployment Test: Run available deployment tests including non-functional checks e.g. performance, failover or capacity tests.
  8. Release: Promote the test deployment through the various required environments to rollout to production traffic.
  9. Warranty: Observe the release with heightened operational awareness to confirm success, with rapid rollback invoked on suspicion of failure.

Tools Available

The tools available to all Flutter divisions are currently limited to the GitHub platform:

The following tools are NOT available across all divisions, but are used within individual divisions or teams:

Shared vs Division Context

Each of the steps from source to production can be either:

It is recommended to use a shared context for steps 1-5, and a divisional context for steps 6-9. These choices will depend on the requirements and history of your specific capability with some common problems encountered with the recommended approach for each step included in the table below:

Step Context Typical Problem
Source Shared Branching strategy too simple for multi-division deployment.
Validate Shared Group licenced/deployed static analysis tools or checks not available.
Package Shared Private build dependencies only available within a divisional Artifactory.
Integration Test Shared Tests require access to divisional mock services (e.g. account systems).
Publish Shared Immature shared GitHub service account management.
Deploy Divisional Multiple packaging formats required to support divisional preferences.
Deployment Test Divisional Unclear responsibilities split with “integration test” step results in wasteful duplicated testing.
Release Divisional No cross-divisional health/ready endpoints.
Warranty Divisional No cross-divisional observability & telemetry standards.

Such problems are topics of active experimentation within various of our inner source products.

Make a Contribution
← Previous
Creating a Repository