How to Deploy an Existing GitLab Release Without Building Again

Discover how to efficiently deploy an older release in GitLab without the hassle of rebuilding your project. Explore strategies using job reruns and artifact management.
---
This video is based on the question https://stackoverflow.com/q/69055139/ asked by the user 'Datz' ( https://stackoverflow.com/u/9224219/ ) and on the answer https://stackoverflow.com/a/69055369/ provided by the user 'Adam Marshall' ( https://stackoverflow.com/u/2307873/ ) at 'Stack Overflow' website. Thanks to these great users and Stackexchange community for their contributions.

Visit these links for original content and any more details, such as alternate solutions, latest updates/developments on topic, comments, revision history etc. For example, the original title of the Question was: How to Deploy an already existing Gitlab release without building the project again?

Also, Content (except music) licensed under CC BY-SA https://meta.stackexchange.com/help/licensing
The original Question post is licensed under the 'CC BY-SA 4.0' ( https://creativecommons.org/licenses/by-sa/4.0/ ) license, and the original Answer post is licensed under the 'CC BY-SA 4.0' ( https://creativecommons.org/licenses/by-sa/4.0/ ) license.

If anything seems off to you, please feel free to write me at vlogize [AT] gmail [DOT] com.
---
How to Deploy an Existing GitLab Release Without Building Again

When managing a GitLab pipeline, you might find yourself in a situation where you need to roll back an environment to an older release. This can seem a bit tricky, especially if you're accustomed to a continuous deployment setup where every change is built and deployed anew. In this guide, we’ll explore how to efficiently deploy an already existing GitLab release without the need to build your project again.

The Challenge

Imagine you have a well-structured GitLab pipeline consisting of multiple stages - testing, building, releasing, and deploying across various environments. At times, however, a rollback to a previous release may be necessary — perhaps due to a bug introduced in the latest version.

In systems like Jenkins, the process of rolling back could be straightforward, typically involving an additional job to deploy the existing release. But in GitLab, options may seem limited; you might think about:

Creating a new project specifically for deployment, which can be excessive.

Modifying each job to incorporate rules for skipping unnecessary stages, which can involve a significant effort and make maintenance more complex.

Fortunately, a more efficient solution exists.

Solution: Leveraging GitLab CI/CD Job Reruns

Rerun Jobs Effectively

Once a job in GitLab CI/CD passes, it can be rerun multiple times. This feature allows you to redeploy from existing artifacts without going through the entire build and testing cycle again. Here’s how you can streamline your deployment process:

Identify Your Deploy Job:
Ensure you have a deploy job set up that is capable of deploying the artifacts generated in your pipeline. This job might be responsible for transferring tar files or executable files to your servers.

Utilize Artifacts:
The deployment typically relies on artifacts created in a preceding job, often referred to as a "Package" job (e.g., npm run build, followed by creating a tar file).

Check Artifact Availability: Ensure that the artifacts from your "Package" job are still available. Artifacts can expire based on your configuration in the job definition. If your artifacts are still valid, you can simply rerun the deploy job.

Manage Expire Times:

Set appropriate expiration times for your artifacts:

Keep your "Package" job artifacts (like tar files) for a longer duration (e.g., 2 weeks) to facilitate easier redeploys.

Set shorter expiration times (like 30 minutes) for build jobs (like npm ci or composer install) since these are often not needed later on.

Handling Dependencies

In some cases, the "Package" job might depend on artifacts generated in earlier jobs. If those dependencies have expired, you’ll need to rerun them too. However, if you've configured job expirations smartly, the need to rerun jobs can be minimized.

Example Pipeline Definition

To illustrate how these principles can be applied, here’s a simplified YAML configuration resembling a typical GitLab pipeline, particularly for a PHP backend combined with a JavaScript Vue frontend:

[[See Video to Reveal this Text or Code Snippet]]

Key Takeaways

Reuse Existing Artifacts: Rerun your deploy job to utilize artifacts that have not expired.

Manage Expiration Smartly: Tailor expiration times based on your project requirements.

Adjust for Dependencies: Be mindful of any dependency jobs that may need rerunning if their artifacts have expired.

By utilizing these strategies, you can streamline the process of rolling back to previous releases in GitLab without needing to rebuild your project from scratch, making your CI/CD pipeline more efficient and manageable.

Видео How to Deploy an Existing GitLab Release Without Building Again канала vlogize