CI/CD Versioning Script

CI/CD Integration with Versioning API

Overview

This documentation provides guidelines for integrating the Versioning Tools API into your Continuous Integration and Continuous Deployment (CI/CD) pipeline. The objective is to automate version management for your application, ensuring consistent and traceable versioning across all releases.

Prerequisites

Before integrating the Versioning API with your CI/CD pipeline, ensure the following:

  1. Access to Versioning Tools API: You should have a valid API key from the Versioning Tools platform.

  2. CI/CD Platform: A working CI/CD setup (e.g., Jenkins, GitLab CI, GitHub Actions, Azure Pipelines).

  3. Git Repository: A Git repository with a defined branching strategy (e.g., main, develop, feature/*, release/*).

API Endpoints

The following Versioning API endpoints are relevant for CI/CD integration:

  1. Create or Retrieve Next Version

    • POST /v1/SemVer/{serviceId}

    • Parameters: serviceId (string), identifier (optional for branch-based differentiation)

  2. Get Current Version

    • GET /v1/SemVer/{serviceId}

  3. Version History

    • GET /v1/SemVer/{serviceId}/history

CI/CD Integration Approaches

1. Automating Version Bumping

This approach automatically increments the semantic version (major, minor, or patch) during the CI/CD pipeline based on the type of change detected (e.g., feature, bug fix, breaking change).

Workflow

  1. Analyze Commits (Optional):

    • Use a script to parse commit messages and determine the type of version bump required (major, minor, or patch).

  2. Call Versioning API:

    • Based on the analysis, trigger the Versioning API to generate the next version.

    - name: Bump Version
  run: |
    curl -X POST https://api.versioning.tools/v1/SemVer/myService \
         -H "Content-Type: application/json" \
         -d '{
               "apiKey": "${{ secrets.VERSIONING_API_KEY }}",
               "identifier": "${{ github.ref }}"
             }'

  3. Apply Version:

    • Use the generated version to tag the release and update any relevant files (e.g., package.json, setup.py).

  4. Build and Deploy:

    • Build and deploy the application using the new version.

Example: GitHub Actions

name: CI/CD Pipeline

on:
  push:
    branches:
      - main
      - develop
      - 'release/*'

jobs:
  versioning:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout Code
      uses: actions/checkout@v2

    - name: Set Up Node.js
      uses: actions/setup-node@v2
      with:
        node-version: '16.x'

    - name: Bump Version
      run: |
        curl -X POST https://api.versioning.tools/v1/SemVer/myService \
             -H "Content-Type: application/json" \
             -d '{
                   "apiKey": "${{ secrets.VERSIONING_API_KEY }}",
                   "identifier": "${{ github.ref }}"
                 }'

    - name: Build and Deploy
      run: |
        # Your build and deployment steps here

2. Versioning Based on Release Branches

This approach ties versioning directly to specific Git branches (e.g., main, release/*).

Workflow

  1. Trigger on Specific Branches:

    • Configure the CI/CD pipeline to trigger on push events to the release/* or main branches.

  2. Determine Version Type:

    • Assign different version types based on the branch. For example, release/* triggers a minor version bump, while main triggers a patch bump.

  3. Call Versioning API:

    • Automate the version bump based on the branch.

    - name: Bump Version for Release
  if: startsWith(github.ref, 'refs/heads/release/')
  run: |
    curl -X POST https://api.versioning.tools/v1/SemVer/myService \
         -H "Content-Type: application/json" \
         -d '{
               "apiKey": "${{ secrets.VERSIONING_API_KEY }}",
               "identifier": "release"
             }'

  4. Build, Tag, and Deploy:

    • The pipeline builds the application, tags the release with the new version, and deploys.

Example: GitLab CI/CD

stages:
  - build
  - version
  - deploy

versioning:
  stage: version
  only:
    - main
    - release/*
  script:
    - curl -X POST https://api.versioning.tools/v1/SemVer/myService \
         -H "Content-Type: application/json" \
         -d '{
               "apiKey": "${VERSIONING_API_KEY}",
               "identifier": "$CI_COMMIT_REF_NAME"
             }'

build:
  stage: build
  script:
    - # Build commands

deploy:
  stage: deploy
  script:
    - # Deploy commands

3. Version Rollback on Deployment Failure

In the event of a failed deployment, the CI/CD pipeline can trigger a rollback to the last stable version using the Versioning API.

Workflow

  1. Monitor Deployment:

    • After deployment, monitor the deployment status.

  2. Trigger Rollback on Failure:

    • If deployment fails, retrieve the last stable version using the history endpoint of the Versioning API.

    - name: Rollback Version
  run: |
    curl -X GET https://api.versioning.tools/v1/SemVer/myService/history \
         -H "Content-Type: application/json" \
         -d '{
               "apiKey": "${{ secrets.VERSIONING_API_KEY }}"
             }'

  3. Re-Deploy:

    • Deploy the last stable version to revert to a known good state.

Example: Azure Pipelines

trigger:
- main

stages:
- stage: Deploy
  jobs:
  - job: DeployJob
    steps:
    - script: |
        # Deployment steps

    - script: |
        # Check deployment status
        if [ $DEPLOYMENT_FAILED ]; then
          curl -X GET https://api.versioning.tools/v1/SemVer/myService/history \
               -H "Content-Type: application/json" \
               -d '{
                     "apiKey": "$(VERSIONING_API_KEY)"
                   }'
          # Re-deploy last stable version
        fi

PreviousCustomer-Specific Branches

Last updated