Deploying Feature Branches With KubeRocketCI: A Comprehensive Guide for Efficient Application Testing and Deployment

Deploying feature branches is crucial for testing activities, including manual testing of the product's functionality, running quality gates, and verifying dependencies or integrations with other components.

KubeRocketCI enables the deployment of feature environments straight from feature branches. This guide offers comprehensive instructions for managing and deploying these branches.

For a hands-on, end-to-end walkthrough on a local cluster — covering auto-triggered deployments, proof of namespace isolation, per-environment GitOps values override, and one-click teardown — see the Ephemeral Environments on Kubernetes: Feature Branch Preview Walkthrough blog post.

Preconditions

Before you start the use case, ensure to meet the following requirements:

• KubeRocketCI instance is configured with GitOps repository.
• Developer has access to the KubeRocketCI instance using the Single-Sign-On approach or via token.
• Developer has access to the KubeRocketCI platform under the Developer role.
• Application you want to add a branch to is onboarded in KubeRocketCI.

Goals

Below are the goals to complete in the use case:

• Onboard a feature branch for the application.
• Configure the GitOps approach for the Environment by adding a values.yaml file with application parameters within it.
• Deploy application with overridden parameters.

Scenario

The use case scenario contains the following stages:

• Create a feature branch: Create a feature branch and build artifact for it.
• Create a Deployment: Create a Deployment that contains an Environment and deploy application within the Environment.
• Configure application parameters: Adjust a GitOps repository by adding custom application configuration into it.
• Apply custom settings for application: Deploy application with custom parameters.

Create Feature Branch

There are two approaches to onboard a feature branch:

1. Create a Feature Branch via KubeRocketCI: KubeRocketCI creates a new branch in GitHub.
2. Onboard an Existing Branch in KubeRocketCI: Manually create the branch in GitHub using the correct naming convention and then onboard it into KubeRocketCI.

In this use case, we will follow the first approach to add a branch.

When creating a feature branch, ensure the branch name is lowercase to meet Kubernetes restrictions. As an example, we will use the feature/<jira-ticket> pattern as a naming convention for feature branches.

To create a feature branch via KubeRocketCI, follow these steps:

1. Open the KubeRocketCI portal and log into the platform:

2. Navigate to the Projects section and select the desired Project.

3. Select the Branches tab and click the Create branch button:

4. Click the Create branch button and fill in the form:

• Branch Name: Specify the name (e.g., feature/tt-000).
• From Commit Hash: Specify the commit hash or leave it empty for the latest commit.
• Branch Version: Provide a version tag for the branch.
• Review Pipeline: Leave the default pipeline.
• Build Pipeline: Leave the default pipeline.

5. Click Create to finalize the branch creation.

6. The branch will also be created in GitHub. Verify its creation in the repository:

Since we don't create a pull request to merge our feature with the main branch, we need to manually trigger the build pipeline in the KubeRocketCI portal.

7. Build the application using the Build button:

8. View the build pipeline run details by selecting the PipelineRun name:

Deploy Feature Branch

Once you have completed the onboarding process for the feature branch, you can deploy its artifacts to a dedicated feature environment.

Create Deployment

We recommend using initials to name the Deployment. For example, a user with the email firstname_lastname@example.com should use fl as the identifier.

To create a feature environment, follow the steps below:

1. Open the Deployments section and click Create Deployment:

2. In the Create new deployment dialog, fill in the required fields:

   • Applications:

     • Applications: Add inventory-service application
     • Branch: Select feature/tt-000 branch

     

   • Pipeline configuration:

     • Pipeline name: fl
     • Description: Deploy the "inventory-service" application for the "Firstname Lastname" user
     • Deployment type: Select Container
     • Promote applications: Leave unchecked

     

   • Review:

     Verify the Deployment configuration and click Create deployment:

     

3. In the congratulations window, click Open deployment:

   

Create Environment

The next step is to create an Environment:

1. On the Deployment details page, click the Create Environment button:

   

2. Fill in the required fields:

   • Basic configuration:

     • Cluster: in-cluster
     • Environment name: dev
     • Deploy namespace: krci-fl-dev
     • Description: Personal environment for Firstname Lastname user

     

   • Pipeline configuration:

     • Trigger type: Manual
     • Deploy Pipeline template: deploy
     • Clean Pipeline template: clean

     

   • Quality Gates:

     Leave everything as is:

     

   • Review:

     Review the specified values and click the Create environment button:

     

3. In the congratulations window, click Go to environment.

The feature Environment is now ready for deployment.

Deploy Application

To deploy an application, follow the steps below:

1. Click Configure deploy, select the image tag to be deployed, and proceed with the Start deploy button:

2. Verify the deployment status in the Pipelines section:

3. Click the pipeline run name to view its details:

4. Open the application in Argo CD using the Argo CD button:

5. View enhanced insights and log analysis:

Deploy With Custom Parameters

The platform utilizes a Helm chart found in the deploy-templates folder of each Project repository. To deploy a feature branch with custom variables, select the Values override option on the Environment page. The Values override option allows you to override default parameters in the deploy-templates folder of the Helm chart.

note

Before enabling this option, you must provide custom parameters for the application. To do this, please add the required values to the values.yaml file in the GitOps repository, ensuring you follow the expected structure.

For the inventory-service application, no Helm chart variables are defined yet. So, we will modify the Helm chart to add a parameter. If your Helm chart already has variables to override, you can proceed to step 4.

1. In KubeRocketCI, navigate back to the application and open the branch source code:

2. Clone the application repository to the local machine. Check out the feature branch and paste the contents below to the deploy-templates/templates/deployment.yaml and deploy-templates/values.yaml files:

values.yaml

extraEnv: {}

deploy-templates/deployment.yaml

...
          ports:
            - name: http
              containerPort: {{ .Values.service.port }}
              protocol: TCP
          {{- if .Values.extraEnv }}
          env:
          {{- toYaml .Values.extraEnv | nindent 12 }}
          {{- end }}
          livenessProbe:
            {{- toYaml .Values.livenessProbe | nindent 12 }}
          readinessProbe:
            {{- toYaml .Values.readinessProbe | nindent 12 }}

...

The resulting difference should look this way:

3. Commit your changes, push your branch to the remote repository, and build the application (feature branch) once again.

4. Open the GitOps repository using the Go to the source code button:

5. Clone the GitOps repository to the local machine. Check out another branch and create a file by the <deployment-name>/<environment-name>/<application-name>-values.yaml pattern (in our case, fl/dev/inventory-service-values.yaml).

6. Open the <deployment-name>/<environment-name>/<application-name>-values.yaml file and paste the contents below:

values.yaml

extraEnv:
  - name: NAME
    value: "Hello from KubeRocketCI"

7. Commit your changes, push your branch to the remote repository and create a pull request:

8. Merge the pull request.

9. On the Environment page, click the Configure deploy button. When deploying an application, enable the Values override option in the Environment settings:

When the Values override option is enabled, the platform navigates to the GitOps repository to pull the parameters from the <application-name>-values.yaml file and then overrides them in an Argo CD application accordingly.

10. If the application is deployed in the "in-cluster", open the pod terminal using a dedicated button on the Environment details page:

11. Run the following command to verify that the variable has been applied to the pod:

env | grep NAME

12. (Optional) If you deploy the application in the remote cluster, you can open the deployed application in Argo CD and select the pod block:

13. (Optional) In the Terminal tab, run the following command to verify that the variable has been applied to the pod:

env | grep NAME

Cleanup

After merging the feature branch, please delete the branch and Environment.

Delete Feature Environment

1. In the KubeRocketCI portal, return to the Environment.

2. Select the application from the Applications tab and click the Delete button to remove the application from the Environment:

3. Navigate to the Deployments section. Click the actions button and select Delete:

Delete Feature Branch

The last step is to delete a feature branch for the application:

1. Navigate to the Projects section.

2. Open the Project that contains the feature branch.

3. Delete the branch from the Branches tab:

4. Delete the feature branch from GitHub:

Related Articles

• Use Cases
• Add Application
• Add Deployment
• Manage Deployments
• Manage GitOps