The qa branch is to reflect what is currently on QA. Code may only be pushed
to this branch via pull request which depends on both approval and a successful
workflow build of the code.
The production branch should always reflect what is on production. This
branch is to remain locked until we are ready to move code from QA to
production, at which point the following steps will be performed:
-
The
productionbranch will be unlocked via the repository settings. -
The
qabranch will be merged intoproduction -
The
productionbranch will be re-locked via the repository settings.
|
❗
|
These steps are not the service deployment steps, they are simply an outline
of steps strictly related to getting the |
The following is a full list of steps necessary to perform a deployment of the QA VDI service code onto production.
-
Unlock the
productionbranch via the repository settings. This setting can be found in the "Branches" menu under the "production" branch rule. The specific setting to uncheck is "Lock Branch". -
Merge the
qabranch intoproduction. -
Re-lock the
productionbranch via the setting described in step 1. -
Wait for the
productionbranch to build in Jenkins. -
Create a new release tag on the merge commit from
qatoproduction. -
Wait for the new tag to build in Jenkins.
-
Create a PR on the Tagger repository, forked from and targeting the
prodbranch, updating thevdi-servicetag to the new tag created in step 5. -
Assign the PR to systems and notify them of the PR.
|
|
Steps 4 and 6 are necessary to avoid known issues with our current Jenkins build setup for containerized services. |
The VDI service repository is divided into 4 categories: components, daemons, lanes, and the core bootstrapper.
Components are small shared libraries that contain code specific to a purpose that is not the core focus of the VDI service.
Daemons are background processes that perform maintenance tasks such as dataset reconciliation or pruning old, soft-deleted datasets from S3.
Lanes are event handlers that are tailored to individual event types, performing some process or processes on a dataset specified in the subscribed events.
The bootstrapper is the core of the service, and the root level Gradle project. This piece is responsible for starting up and shutting down the various project modules.
Shared library components used by one or more VDI daemons, lanes, the rest service, and/or the bootstrapper.
Dataset event handlers. Each lane is a separate process that subscribes to a Kafka channel and operates on datasets whose information is provided in the incoming events.
The rest service is the public API through which users and administrators communicate with and operate on the VDI system.
The bootstrapper is the core of the service, and the root level Gradle project. This piece is responsible for starting up and shutting down the various project modules.