Skaffold/Kustomize Automated Deployments in Production

Table of Contents

1. Requirements
- 1.1. Jenkins Configuration
- 1.2. Project Manifest
2. Automated Deployment Trigger
3. Production Release Process
4. Deployment Safeguards
5. Rollback Instructions
- 5.1. Option 1: Git-based Rollback
- 5.2. Option 2: Manual Jenkins Rollback

This document outlines the requirements and procedures for executing automated deployments to the production environment using Skaffold and Kustomize in conjuction with the Jenkins Shared Library.

1. Requirements

For automated deployments to execute successfully, the following configuration requirements must be met.

1.1. Jenkins Configuration

The jenkins.yaml file must be updated with the following values to enable production deployments.

enableTagRelease: true

prod: # Production build environment overrides
  skip: true
  deployStageOnly: true # Disables all but the deploy stage
  deployNamespace: prod
  enableAutoDeploy: true
  enableManualDeploy: true

1.2. Project Manifest

Your project must contain a manifest.json file in the root directory with the following structure.

{
  "version": "vX.Y.Z-conf##",
  "NS": "prod"
}

Where vX.Y.Z is the semantic version and conf## represents the configuration iteration (e.g., conf01, conf02).

During the deployment, the semantic version (X.Y.Z) in manifest.json is strictly compared to the version in the parent pom.xml. The deployment will only proceed if these versions match.

2. Automated Deployment Trigger

An automated deployment is triggered under specific conditions:

The Jenkins job must be configured to scan Release/* branches.
A deployment is attempted only when a commit at HEAD of a scanned release branch includes a change to the manifest.json file.

There should only be a single Jenkins job for production, configured for this auto-deployment process.

3. Production Release Process

Follow these steps to cut a new release for an automated production deployment.

Update manifest.json

Modify the version field in manifest.json for the new tag you intend to create. The configuration version should be higher than conf01, as conf01 is reserved for initial SQA deployments.
```
{
  "version": "v1.0.0-conf02",
  "NS": "prod"
}
```

Create a Git Tag

Add an annotated tag pointing to the commit where manifest.json was updated.

git tag -a v1.0.0-conf02 -m "Tag for production release of v1.0.0 using configuration v1.0.0-conf02"

Push Changes

Push both the commit and the new tag to the remote repository.
```
git push --follow-tags
```

4. Deployment Safeguards

The JSL autodeployment script ensures all of the following conditions are true before proceeding:

The environment it is running in is production.
The branch being executed against matches the Release/* pattern.
The commit at HEAD contains a change to the manifest.json file.
The semantic version in manifest.json matches the version in pom.xml.

If any of these conditions are not met, the production deployment will be aborted.

5. Rollback Instructions

If a rollback is necessary, you have two options.

5.1. Option 1: Git-based Rollback

This is the preferred method for rolling back.

Update the manifest.json file to the version of the git tag you want to restore.
Commit and push this change to the Release/* branch to trigger a new deployment with the old version.

5.2. Option 2: Manual Jenkins Rollback

This option can be used as an alternative.

Navigate to the Jenkins job and select "Build with Parameters".
Enter the specific git tag you wish to roll back to in the appropriate parameter field and trigger the build manually.