GitLab CI/CD for React App: Release Creation using Maven Release Plugin

This chapter focuses on completing the continuous integration (CI) component for a ReactJS project within a GitLab CI/CD pipeline by introducing an automated release and tagging mechanism. Building upon previous setups involving linting, building, unit testing, and snapshot publishing, this lesson implements the Maven Release Plugin to handle versioning, tag creation, and artifact deployment.

1. Why Do We Need Automated Release Management?

In modern software delivery, manual version bumping, Git tagging, and artifact publishing are error-prone, slow, and difficult to audit.

• The Status Quo Problem: Developers manually modify pom.xml, run local Git commands to create tags (git tag v1.0.0), push them, and manually deploy binaries, leading to human error, mismatched versions, and missing audit trails.
• The CI/CD Solution: Automating the entire lifecycle via pipeline stages ensures that every official production release is tied directly to an immutable Git tag, version numbers are incremented automatically, and clean deployment artifacts land safely in artifact repositories (such as Artifactory or Nexus).

2. Core Mental Model: The Release Lifecycle & Maven Plugin

The Maven Release Plugin standardizes how Java-based or Maven-driven repositories handle version lifecycles. While traditional Maven release workflows combine both preparation and performance into a single local execution, this architecture adapts the plugin for a distributed, automated CI/CD pipeline.

Real-Life Analogy: The Automated Book Publisher

Think of the Maven Release Plugin as a strict publishing house editor:

1. The Preparation Phase: The editor inspects the manuscript, checks that all chapters (tests) are skipped or passed, stamps the cover with an official version number (v0.0.3), locks it in the vault (creates a Git tag), and updates the next working draft to version 0.0.4-SNAPSHOT.
2. The Publication Phase: Once the locked vault copy (v0.0.3) is brought out, the printing press runs a clean print job and distributes finalized copies directly to bookstore shelves (Artifact Repository).

3. Pipeline Evolution: Two-Phase vs. Custom Hybrid Approach

In previous projects (such as Spring Boot applications), the speaker utilized both phases of the Maven Release Plugin sequentially in a single job:

• mvn release:prepare: Creates the Git tag and updates the development version.
• mvn release:perform: Checks out the tag and deploys the artifacts.

For this ReactJS project, a custom hybrid approach is implemented to separate concerns:

1. Tag Creation Job (release-tag-create): Executes mvn release:prepare exclusively on the default branch (main or master) to generate the Git tag and bump the development version.
2. Tag Publication Job (tag-publish): Triggers only when a Git tag is pushed, checking out that specific tag and running mvn clean deploy to publish artifacts.

4. Step-by-Step Pipeline Configuration

A. The Release Tag Creation Job (release-tag-create)

This job is responsible for initiating the release. It runs strictly on the default branch and uses the Maven Release Plugin preparation phase.

release-tag-create:
  stage: release
  script:
    - git config --global user.email "ci-bot@example.com"
    - git config --global user.name "CI Bot"
    - git checkout main
    - git pull origin main
    - mvn release:prepare -DskipTests -Dusername=$GITLAB_USER -Dpassword=$GITLAB_TOKEN
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'

B. Protecting Branch Executions and Avoiding Infinite Loops

Because the Maven Release Plugin commits changes back to the repository (bumping the version to the next development snapshot), all standard branch pipeline jobs must be explicitly configured not to run on commits generated by the release plugin to prevent infinite pipeline loops.

• Branch Guardrails: Jobs running on feature branches are set with when: never or restricted via rules.
• Default Branch Rule: The release-tag-create job is strictly restricted to $CI_DEFAULT_BRANCH (e.g., main), ensuring feature branches (feat-ui) cannot trigger production release tags.

tag-publish:
  stage: release
  script:
    - mvn clean deploy -DskipTests
  rules:
    - if: '$CI_COMMIT_TAG'

5. End-to-End Pipeline Workflow Walkthrough

The following sequence illustrates how code flows from a feature branch to production release and artifact publication:

6. Verification and Inspection in GitLab & Artifactory

Once the pipeline execution completes, you can verify the results across multiple systems:

1. GitLab Tags View: Navigate to Repository > Tags to confirm that the release tag (e.g., v0.0.3) has been automatically created.
2. GitLab Pipelines View: Observe two distinct pipeline types:
   • The Branch Pipeline running on main that executed release-tag-create.
   • The Tag Pipeline triggered by the newly pushed tag, running tag-publish.
3. Artifact Repository (Artifactory / Nexus): Navigate to your release repository path (e.g., my-org-release-local -> ui-block) to confirm the deployment of version 0.0.3. Opening pom.xml within the tagged commit confirms the version is correctly stamped without the -SNAPSHOT suffix.

7. Comparison of Release Strategies

8. Summary and Key Takeaways

• Automated Tagging: The Maven Release Plugin (mvn release:prepare) automates version management, eliminates human error, and creates immutable Git tags.
• Branch Restrictions: Release creation jobs must be strictly guarded using rules ($CI_COMMIT_BRANCH ==$CI_DEFAULT_BRANCH) to ensure tags are generated only from the main production branch.
• Dedicated Tag Pipelines: Utilizing if: '$CI_COMMIT_TAG' allows dedicated deployment jobs to react exclusively when a release tag is pushed.
• Infinite Loop Prevention: Ensure standard feature branch jobs ignore commits generated by CI bots or release plugins to prevent endless pipeline loops.
• Artifact Traceability: Separating release preparation from artifact deployment ensures clean binaries (v0.0.3) are reliably published to remote artifact repositories.
• Next Steps: With linting, building, testing, snapshot publishing, and release creation complete, the next phase involves deploying these validated artifacts to actual target environments.