On This Page

The process for deploying a feature branch diverges slightly from the method we’ve discussed previously. While we still leverage ArgoCD applications, we do not point them towards a Helm chart housed in the Chart Museum. Instead, we direct the ArgoCD application straight to the Git repository and the correct branch.

This approach allows the files within the chart folder to be applied immediately, eliminating the need to wait for the completion of the Tekton pipeline to see changes. This design facilitates rapid experimentation, which is crucial when developing new features that require a swift feedback loop - especially in relation to Kubernetes definitions.

However, this doesn’t mean the pipeline is bypassed. It still triggers, building the image and storing it in the image registry. Unlike the main branch deployment, where the tag format represents the application version, the tag format for a feature branch corresponds to the branch name. For instance, an image from a branch named feature-1 would look something like this: 292243477487.dkr.ecr.us-east-1.amazonaws.com/service-1:feature-1. The feature branch continues to be stored in the Chart Museum as well.

In this context, .Release.Name refers to the branch name of the deployed application.

If you’re wondering how deployments transpire without dynamically generating applications for feature branches, you’re asking a great question. The answer can be found in the pipeline’s deploy task. This is where we dynamically create an ArgoCD application and apply it to the cluster.

Let’s put this into action. We have previously made a commit on the main branch. First, let’s check what applications related to service-1 are currently on our cluster.

kubectl get applications -n argocd -o wide | grep service-1

The expected output will look something like this:

NAME             SYNC STATUS   HEALTH STATUS   REVISION
service-1        Synced        Healthy         1.0.2
tkn-service-1    Synced        Healthy         ad2d79bad4c04c966effcfab83f9764ca94327ec
deps-service-1   Synced        Healthy         3c93f6eb256d3b6865e1437867ad1eafdbf6946b

Excellent! We see that there are three service-1 related applications currently deployed and in a healthy state. Let’s break down what we have:

  • service-1: This is our application, which points to the Helm chart version 1.0.2 in this example.
  • tkn-service-1: The pipeline for service-1. It points to the pipeline folder of the main branch of application source code.
  • deps-service-1: This is the generator dependency, which points to the /each/dependencies folder in the platform repository.

Next, we’ll create a new branch and trigger a new commit to see the resulting changes. A new application is about to be created.

git checkout -b feature-1
git commit --allow-empty -m "Empty commit"
git push origin feature-1

We can run a line to describe the PipelineRun and see if it started running as it should.

tkn pr describe -n service-1-ci-cd

And also get the logs, grepping the Deploy task logs, where we want to see when the ArgoCD application gets created on the fly.

tkn pr logs -n service-1-ci-cd | grep "deploy : argocd-create-application"

And to validate the application was created sucessfully. Let’s get all applications related to the service-1 again.

kubectl get applications -n argocd -o wide | grep service-1

The expected output will look something like this:

NAME             SYNC STATUS   HEALTH STATUS      REVISION
service-1             Synced        Healthy       1.0.2
tkn-service-1         Synced        Healthy       ad2d79bad4c04c966effcfab83f9764ca94327ec
service-1-feature-1   Synced        Healthy       3c3038db32d85a1d780eac659bcafe873bc52719
deps-service-1        Synced        Healthy       3c93f6eb256d3b6865e1437867ad1eafdbf6946b

And as we can see, we have a new application service-1-feature-1.

Hostname

The ingress works the same way as the main branch, which is together with the application’s source code. By default, the template generates an ingress host endpoint in the following format:

Let’s check to see if it’s responsive.

curl -v https://feature-1-service-1.eu-north-1.training.dx-book.com/health/

And the response should be something like:

< HTTP/2 200
< access-control-allow-origin:
< content-type: application/json; charset=utf-8
* Connection #0 to host feature-1-service-1.eu-north-1.training.dx-book.com left intact
[{"ok":true}]

Cleanup

How about the cleanup of feature branches and the stale argocd applications? Whenever we delete a branch in github, a webhook will be sent to the EventListener, in the same way as the push event, when we send a new commit.

The pipeline will respond to the delete event and will execute a TaskRun to:

  1. Delete the argocd feature branch application