Workflows

⁠

Our monorepo repository stores all the code of some relevant projects. The process that we use to deploy that code to our different environments is bases on a trunk strategy. All the changes on the main branch of the repository have to be deployed to staging and each tag created have to be deployed to production.

This workflow allows us to approve new changes, run unit test, prepare and deploy new features. We can divide the flow in three main phases: continuos integration, continuos delivery and continuos deployment.

Additionally, we configured a self-hosted runner to run some tasks before and after a GitHub action is executed. Those tasks guarantee an ephemeral environment that runs the last version of the database and could runs some other services locally.

On the other hand, Nx is a technology that allow us to execute a command over each service in the monorepo apps folder. Every service can define the commands that will be needed to send code throw all phases.

Continuous integration

This is the phase triggered by pull request action to the main branch of the repository. This phase is used to validate the code before it will be merged to the trunk. Usually, we validate the code syntax, semantic and runs unit tests defined on each service.

First of all, the process runs the command to update the environment database to the needed version. Then it runs the lint or the test command on each service that explicitly defines those scripts in its package.json file.

At the end of this phase, the code is merged to the main branch and trigger the next phase.

References in monorepo repository:

github workflow in /.github/workflows/mainCI.yml

test environment script in /scripts/runTestEnvironment.sh

Continuous delivery

This phase is used to prepare the code that will be deployed on staging or production environment. This is triggered with two specific actions:

The action of merge new code into the main branch prepares the code to be deployed on staging environment.

The action of create a version tag prepares the code to be deployed into the production environment.

In both environments, we use different docker images versions for each service to expose the required behavior. All docker images versions are managed into ECR service (AWS Elastic Container Repository).

In this phase, we use Nx to create docker images of all affected services using the command build on each one. An affected service is one that have been modified in the repository respect an older version, but it is different in both staging and production environment.

In case of staging, the difference es calculated respect the last commit before the new commit.

In case of production the difference es calculated respect the last tag before the new tag.

After the compilation is complete, we send the new images to ECR and create a JSON report to identify the changes. This report allows us to modify the configuration of each environment specified in the argocd repository. To do this is needed to run and action from monorepo (that also allow us to execute this process manually) using a personal access token. It is very important that this token is not expired, so you will need to

update⁠

this access frequently.

References on monorepo repository:

github workflow for staging environment in /.github/workflows/stCD.yml

github workflow for production environment in /.github/workflows/prCD.yml

build docker images script in /scripts/containerBuilder.sh

publish report to argocd repository action in /scripts/publishAndClean.sh

Continuous deployment

This phase is used to configure each environment and deploy all requested images for each service. We use the argocd repository as a declarative specification to configure our infrastructure on Kubernetes. Kustomize allow us to specify which version of image will be deployed for each service and some patches that customize the configuration.

There are two kinds of deployments:

Service deployment to support servers that need to be online all the time.

Job deployment for tasks that have been done in a specific moment and only one time. For example, db migrations and SPAs deployments.

Argocd is a Kubernetes service that allow us to apply the repository specifications to Kubernetes. When the specification of a resource on the repository changes, Kubernetes deploy the needed resources to match with this specification.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.