Automatic Deployment to Production Environment

In this lesson, we’ll automate the deployment of our application to the production environment by merging a feature branch into main. Previously, we ran the pipeline in the feature branch and verified deployment to the review stage using Auto DevOps. Now, accepting the merge request will trigger a new pipeline on main.

1. Merge Feature Branch into Main

First, confirm that all review jobs have passed:

The image shows a GitLab pipeline interface with stages for build, test, review, performance, and cleanup, indicating the status of various jobs. Each stage has a green checkmark, suggesting successful completion.

Open the merge request, uncheck Delete source branch, and click Merge to push your changes to main:

The image shows a GitLab merge request page for updating "app.js" for testing autodevops, with a pipeline that passed with warnings. The request is ready to merge, and approval is optional.

2. Monitor the Pipeline on Main

Navigate to CI/CD > Pipelines to see the new run:

The image shows a GitLab pipeline dashboard with various pipeline statuses such as running, warning, canceled, and failed, along with details about each pipeline.

The main pipeline executes the following stages:

Stage	Purpose
build	Compile code and build artifacts
test	Run unit and integration tests
production	Deploy to the production namespace
performance	Execute browser performance tests

Note

To speed up demos, cancel the test jobs manually once they start.

3. Validate Production Deployment

Ensure that the production namespace is empty before deployment:

kubectl get all -n production

When the production stage completes, you’ll see logs indicating Helm deployment and artifact uploads:

$ auto-deploy delete canary
WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /builds/.../KUBECONFIG
WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /builds/.../KUBECONFIG

$ auto-deploy persist_environment_url
Uploading artifacts for successful job
environment_url.txt: found 1 matching artifact files and directories
WARNING: tiller.log: no matching files. Ensure that the artifact path is relative to the working directory (/builds/...)
Uploading artifacts as "archive" to coordinator... 201 Created
Job succeeded

Warning

The warnings above show that your KUBECONFIG file has overly permissive access. Restrict file permissions to prevent security issues.

Next, verify that 10 replicas are running (the count is driven by a CI/CD variable):

kubectl get all -n production

NAME                                           READY   STATUS    RESTARTS   AGE
pod/production-df6dd64cf-2p8b6                 1/1     Running   0          2m22s
… (8 more pods) …

NAME                              TYPE        CLUSTER-IP   PORT(S)    AGE
service/production-auto-deploy    ClusterIP   10.104.1.52  3000/TCP   2m22s

NAME                         READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/production   10/10   10           10          2m22s

NAME                                      DESIRED   CURRENT   READY   AGE
replicaset.apps/production-df6dd64cf       10        10        10      2m22s

4. Test Load Balancing

Confirm traffic distribution across all replicas by curling the /os endpoint repeatedly:

while true; do
  curl -sk https://demos-group-solar-system-autodevops.139.84.208.48.nip.io/os \
    | grep --color -E 'production|canary'
done

You’ll see different pod names in the responses, verifying round-robin load balancing.

5. Performance Testing

After production, the pipeline automatically runs browser performance benchmarks and archives the results:

The image shows a GitLab pipeline interface with stages for build, test, production, and performance, displaying the status of various jobs. The sidebar includes options like Pipelines, Jobs, and Pipeline editor.

6. Reviewing Auto DevOps Settings

In your project, go to Settings > CI/CD, then expand Auto DevOps to review deployment strategies. We used Continuous Deployment to production in this lesson:

The image shows a GitLab CI/CD settings page with options for configuring Auto DevOps pipelines and deployment strategies. The sidebar includes various menu options like Deploy, Operate, and Monitor.

7. Exploring Dashboards and Reports

Auto DevOps generates code quality, SAST, and secret detection artifacts. On the free tier, download these from Job Artifacts. With Premium/Ultimate plans, you can view reports directly:

Security Dashboard: Aggregated vulnerability findings
Operations Dashboard: Live environment and deployment status

Vulnerability Report

From the top menu, choose Security & Compliance > Vulnerability report:

The image shows a GitLab project dashboard with a list of projects and a sidebar menu. A dropdown menu is open, highlighting the "Vulnerability report" option.

Environments Dashboard

Add multiple projects to an Environments Dashboard (Premium/Ultimate only):

The image shows a GitLab interface where a user is adding projects to an "Environments Dashboard," with several projects related to "Solar System" listed.

Attempting to include private projects on the free tier results in an error:

The image shows a GitLab interface displaying a merge request for updating "app.js" to test autodevops. It includes pipeline details, merge information, and user interactions.

We recommend exploring these dashboards with a trial Ultimate account and configuring manual approvals for production deployments.

Links and References

Watch Video

Watch video content