Decoupling Flyway Migrations from Application Deployment in Azure DevOps Pipelines

[SureshChikkam-MT]

Current Issue
The CI/CD process tightly couples Flyway database migrations with application startup. This approach can lead to:

• Increased application startup time.
• Deployment failures due to migration errors.
• Difficulty in debugging migration issues independently of the application.

Proposed Solution

Decouple Flyway migrations from application startup by adding a separate step in the CI/CD pipeline to run migrations before deploying the application.

Steps to Implement

1. Add a Flyway Migration Step in the Pipeline
   Introduce a dedicated task in the Azure DevOps pipeline to run Flyway migrations using the Docker image.

- task: Bash@3
  displayName: "Run Flyway migrations"
  inputs:
    targetType: "inline"
    script: |
      docker run --rm \
        -e FLYWAY_URL=jdbc:<db-url> \
        -e FLYWAY_USER=<db-user> \
        -e FLYWAY_PASSWORD=<db-password> \
        <acr-name>.azurecr.io/<image-name>:<tag> \
        flyway migrate

2. Tag Images for Migration Purposes

Use specific tags to differentiate between the migration image and the application image.

CMD ["java", "-Dspring.profiles.active=migration", "-jar", "app.jar"]

3. Adjust Application Health Check Logic
   During migrations, configure a lightweight health check response to prevent deployment retries or failures.

@RestController
public class HealthCheckController {
    @GetMapping("/health")
    public ResponseEntity<String> health() {
        if (migrationInProgress) {
            return ResponseEntity.ok("Migration in progress");
        }
        return ResponseEntity.ok("Healthy");
    }
}

4. Run Migrations in Azure Container Instance (Optional)

If the CI/CD pipeline cannot accommodate the migration step, run migrations in an Azure Container Instance.

az container create \
    --resource-group <resource-group> \
    --name db-migration \
    --image <acr-name>.azurecr.io/<image-name>:<tag> \
    --registry-login-server <acr-name>.azurecr.io \
    --registry-username <acr-username> \
    --registry-password <acr-password> \
    --command-line "java -Dspring.profiles.active=migration -jar app.jar"

Corrected Example for CI/CD Pipeline
Pipeline Structure:

steps:
  - name: Build
    script: |
      mvn clean install

  - name: Run Flyway Migrations
    script: |
      docker run --rm \
        -e FLYWAY_URL=jdbc:postgresql://<db-host>:<port>/<db-name> \
        -e FLYWAY_USER=<db-user> \
        -e FLYWAY_PASSWORD=<db-password> \
        <acr-name>.azurecr.io/<image-name>:<tag> \
        flyway migrate

  - name: Deploy Application
    uses: azure/webapps-deploy@v2
    with:
      app-name: sp-az-webapp
      publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}

Justification for Changes
1. Improved Deployment Stability
By separating migrations, failures during this step do not impact application startup.

2. Ease of Debugging
Independent migration logs simplify troubleshooting.

3. Better Resource Utilization
The application image does not require migration dependencies during runtime.

Conclusion

Decoupling Flyway migrations from application startup improves deployment reliability, simplifies debugging, and optimizes resource usage. The proposed changes ensure a robust CI/CD pipeline and facilitate efficient application delivery.

[PesalaPavan]

@SureshChikkam-MT
It would be great if you could add a link to the documentation you are following for these steps? This would help us redirect the issue to the appropriate team. Thanks!!