Application Lifecycle

Applications on MCaaS follow four main phases: create, build, deploy, monitor. This guide will outline the user steps that should be completed for each stage. Here is a checklist you can use when developing a new application.

Important

You will need to request access to Github, Jenkins, and Datadog before completing these steps.

Application Checklist

Create

• Github repository (<module>-<application>-<service>)

• Protected branches (development, test, staging, prod)

• Upload code (Dockerfile required)

Important

Tenant is responsible for choosing and securing their application’s docker base images.

Build

• Request Secrets

• Request Jenkins job

• Request ECR repository

• Create HelmRelease file

• Open Pull Request from feature branch to env branch

• Check Jenkins build status

Deploy

• Populate image tag for Flux (first deployment only)

• Merge Pull Request from feature branch to env branch

Monitor

• Verify container image tag in Datadog

Create the Application

Github Repository

Log into your Github account and create a repository for your application. The repository name MUST follow this naming convention to be picked up by Jenkins.

NAME	EXAMPLE
<module>-<application>-<service>	module1-robotshop-web

Important

Each microservice application should have it’s own Github repository.

Branching Strategy

MCaaS depends on a naming convention for Github branches to achieve automated builds and deployments. Each repository MUST contain these four protected, reserved branches which represent the application environments. (Exception- modules (EKS clusters) without a test environment do not need a test branch.)

• development
• test
• staging
• production

Important

Merging a Pull Request from a feature branch to an environment branch will trigger a deployment. After merging the PR, do not delete the source branch until the destination branch's Jenkins job has completed running. Otherwise, Jenkins may not see the event as a merge, and will not trigger on_merge steps in the Jenkinsfile.

Upload the Code

Each application MUST include a single Dockerfile at the parent level. MCaaS is designed so that each repository will build a single image. We do not support nested folder structures with a Dockerfile hierarchy.*

* There is an exception for this, intended for maintaining multiple images copied from upstream and pushed into ECR. This is generally used for images that will be used as base images in tenant applications. Images are not deployed directly. This option requires additional implementation on the MCaaS side. Please create a Jira Service ticket requesting more information or asking to have this set up if needed.

Build the Application

Request Secrets

If your application uses environment variables or application parameters, they will need to be created in MCaaS as Secrets. Please open a Standard FCS Support Request and specify the following:

• tenant
• module
• application
• environment
• secret name
• secret value

Secrets will be created with the following naming convention:

NAME	EXAMPLE
<tenant>-<module>-<environment>-<application>-<secret-name>	fake-module1-development-robotshop-db-connection-string

For each application MCaaS will need to create a repository in ECR to hold the Docker images built by Jenkins. Please open a Standard FCS Support Request, specifying the following:

• module
• application
• service

Repositories will be created with the same naming convention as Github repos:

NAME	EXAMPLE
<module>-<application>-<service>	module1-robotshop-web

Application's Jenkins Job

Once a Github repo is created for an application using the standard naming convention outlined above, Jenkins will automatically create a multibranch pipeline job for it. The job can be found at https://jenkins-mcaas.helix.gsa.gov/job<tenant>/job/<module>/job/<application>/<Github repo name>

Open Pull Request

Work in progress should be performed in feature branches. Feature branches should match the regex pattern /^[Ff]eature.*/ as defined by the Jenkinsfile.

Important

Opening a Pull Request from a feature branch to an environment branch will trigger a Jenkins build.

Deploy the Application

HelmRelease

The HelmRelease file specifies the deployment for Kubernetes. Each service should have its own release file in the <tenant-short-code>-flux-config repository.

The folder structure should follow the hierarchy below:

MOD/ <-- this is a sample module folder for the tenant
MOD/base <-- resources here will be deployed to all environments' clusters
MOD/development <-- resources here will be deployed to development environment cluster

MCaaS provides a repository with sample Helm charts and release files at https://github.helix.gsa.gov/MCaaS/mcaas-tenant-charts

For an in depth look at how to use these charts, see the Continuous Deployment section.

Important

The first time you deploy a service you will need to manually update the HelmRelease file with the Docker image tag from the Jenkins build console. Make sure you copy the Docker tag and not the Git SHA (example: dev-* | test-* | staging-* | prod-*)

spec:
  values:
    image:
      repository: <aws-account>.dkr.ecr.us-east-1.amazonaws.com/<ecr-repo>
      pullPolicy: Always
      tag: #Update Tag Here#

Merge Pull Request

Merging a Pull Request from a feature branch to an envrionment branch will automatically trigger a deployment.

Tip

Application deployments can be monitored in Datadog.

Validate Flux Configuration

After a successful deployment, Flux will update the HelmRelease file with the new application tag. Verify this value matches the Docker build tag from your latest Jenkins build.

Monitor the Application

Datadog

MCaaS uses Datadog to provide tenants some visibility into their applications and deployments. Datadog will allow you to view application logs, identify service failures, monitor system usage, and create custom Dashboards. To integrate your application with Datadog, see our Datadog setup page.