We recommend that you use declarative infrastructure to deploy your foundationin a consistent and controllable manner. This approach helps enable consistentgovernance by enforcing policy controls about acceptable resource configurationsinto your pipelines. The blueprint is deployed using a GitOps flow, withTerraform used to define infrastructure as code (IaC), a Git repository forversion control and approval of code, and Cloud Build for CI/CD automationin the deployment pipeline. For an introduction to this concept, seemanaginginfrastructure as code with Terraform, Cloud Build, andGitOps.

The following sections describe how the deployment pipeline is used to manageresources in your organization.

Pipeline layers

To separate the teams and technology stack that are responsible for managingdifferent layers of your environment, we recommend a model that uses differentpipelines and different personas that are responsible for each layer of thestack.

The following diagram introduces our recommended model for separating afoundation pipeline, infrastructure pipeline, and application pipeline.

The diagram introduces the pipeline layers in this model:

• Thefoundation pipeline deploys the foundation resources that are usedacross the platform. We recommend that a single central team is responsiblefor managing the foundation resources that are consumed by multiple businessunits and workloads.
• Theinfrastructure pipeline deploys projects and infrastructure that areused by workloads, such as VM instances or databases. The blueprint sets up aseparate infrastructure pipeline for each business unit, or you might prefer asingle infrastructure pipeline used by multiple teams.
• Theapplication pipeline deploys the artifacts for each workload, such ascontainers or images. You might have many different application teams withindividual application pipelines.

The following sections introduce the usage of each pipeline layer.

The foundation pipeline

The foundation pipeline deploys the foundation resources. It also sets up theinfrastructure pipeline that is used to deploy infrastructure used by workloads.

To create the foundation pipeline, you first clone or fork theterraform-example-foundation to your own Git repository. Follow the steps in the0-bootstrap READMEfileto configure your bootstrap folder and resources.

After you create the foundation pipeline in the0-bootstrap stage, thefollowing stages deploy resources on the foundation pipeline. Review the READMEdirections for each stage and implement each stage sequentially.

The infrastructure pipeline

The infrastructure pipeline deploys the projects and infrastructure (forexample, the VM instances and databases) that are used by workloads. Thefoundation pipeline deploys multiple infrastructure pipelines. This separationbetween the foundation pipeline and infrastructure pipeline allows for aseparation between platform-wide resources and workload-specific resources.

The following diagram describes how the blueprint configures multipleinfrastructure pipelines that are intended for use by separate teams.

The diagram describes the following key concepts:

• Each infrastructure pipeline is used to manage infrastructure resourcesindependently of the foundation resources.
• Each business unit has its own infrastructure pipeline, managed in a dedicatedproject in thecommon folder.
• Each of the infrastructure pipelines has a service account with permission todeploy resources only to the projects that are associated with that businessunit. This strategy creates a separation of duties between the privilegedservice accounts used for the foundation pipeline and those used by eachinfrastructure pipeline

This approach with multiple infrastructure pipelines is recommended when youhave multiple entities inside your organization that have the skills andappetite to manage their infrastructure separately, particularly if they havedifferent requirements such as the types of pipeline validation policy they wantto enforce. Alternatively, you might prefer to have a single infrastructurepipeline managed by a single team with consistent validation policies.

In theterraform-example-foundation,stage 4 configures an infrastructure pipeline, and stage 5 demonstrates anexample of using that pipeline to deploy infrastructure resources.

The application pipeline

The application pipeline is responsible for deploying application artifacts foreach individual workload, such as images or Kubernetes containers that run thebusiness logic of your application. These artifacts are deployed toinfrastructure resources that were deployed by your infrastructure pipeline.

The enterprise foundation blueprint sets up your foundation pipeline andinfrastructure pipeline, but doesn't deploy an application pipeline. For anexample application pipeline, see theenterprise applicationblueprint.

Automating your pipeline with Cloud Build

The blueprint uses Cloud Build to automate CI/CD processes. Thefollowing table describes the controls are built into the foundation pipelineand infrastructure pipeline that are deployed by theterraform-example-foundationrepository. If you are developing your own pipelines using other CI/CDautomation tools, we recommend that you apply similar controls.

Branching strategy

We recommend apersistent branchstrategy for submitting code to your Git system and deploying resources throughthe foundation pipeline. The following diagram describes the persistent branchstrategy.

The diagram describes three persistent branches in Git (development,non-production, and production) that reflect the correspondingGoogle Cloud environments. There are also multiple ephemeral featurebranches that don't correspond to resources that are deployed in yourGoogle Cloud environments.

We recommend that you enforce apull request(PR) process into your Git system sothat any code that is merged to a persistent branch has an approved PR.

To develop code with this persistent branch strategy, follow these high-levelsteps:

1. When you're developing new capabilities or working on a bug fix, create a newbranch based off of the development branch. Use a naming convention for yourbranch that includes the type of change, a ticket number or other identifier,and a human-readable description, likefeature/123456-org-policies.
2. When you complete the work in the feature branch, open a PR that targetsthe development branch.
3. When you submit the PR, the PR triggers the foundation pipeline to performterraform plan andterraform validate to stage and verify the changes.
4. After you validate the changes to the code, merge the feature or bug fix intothe development branch.
5. The merge process triggers the foundation pipeline to runterraform applyto deploy thelatest changes in the development branch to the development environment.
6. Review the changes in the development environment using any manual reviews,functional tests, or end-to-end tests that are relevant to your use case. Thenpromote changes to the non-production environment by opening a PR that targetsthe non-production branch and merge your changes.
7. To deploy resources to the production environment, repeat the same process asstep 6:review and validate the deployed resources, open a PR to the productionbranch, and merge.

What's next

• Read aboutoperations bestpractices(next document in this series).