Implement docker image versioning #320

placek · 2024-02-27T12:31:54Z

As a QA tester,

I want to know the version of the Docker images based on the last commit that modifies a module,

So that I can have a clear trace of which versions of the modules are deployed on which environments.

Acceptance Criteria

Docker Image Versioning: Docker images are versioned based on the last Git commit ID that modifies the relevant module. This should be automated in the CI/CD pipeline.
Automated Notification: Upon successful deployment, stakeholders are automatically notified with the details of the deployment, including the environment, version, and a summary of changes.

This commit adds three new scripts to the scripts/govtool/utils directory for tracking the version of the application components based on the current code state. These scripts are designed to generate version strings that can be used to tag Docker images, ensuring that changes in the codebase are accurately reflected in the versioning of built images. * backend-base-version: Generates a version string for the base backend image by hashing the vva-be.cabal file. This ensures that any modifications to the backend's dependencies trigger the creation of a new base image. * backend-version: Produces a version string for the backend component by fetching the SHA1 hash of the most recent commit affecting the backend directory. This facilitates identifying the exact state of the backend code included in the Docker image. * frontend-version: Similar to the backend script, this generates a version string for the frontend component by hashing the latest commit in the frontend directory, allowing for precise versioning of the frontend Docker image. These enhancements contribute to a more robust and traceable build process, aligning the deployment artifacts closely with their corresponding codebase states. These scripts are meant to be incorporated into the future version tracking system based on the current deployment model.

…deployments In this update, we've revised our deployment process to utilize distinct version tags for the frontend and backend components of our application. This change is designed to enhance our deployment traceability by clearly indicating which parts of the application have been updated in each release. * Makefile Adjustments: Updated the Makefile to use separate variables (backend_image_tag and frontend_image_tag) for tagging Docker images of the frontend and backend. This allows for independent versioning based on the actual changes made to each component, rather than a single tag that might not accurately reflect updates to both. * Docker Compose Files: Modified docker-compose configuration files for various environments (beta, dev, staging, test) to reference the new tag variables. This ensures that the correct version of each component is deployed, aligning the deployed application with the current state of the codebase. By implementing these changes, we aim to make our deployment process more transparent and to facilitate easier tracking and rollback of changes to individual components when necessary.

This commit introduces centralized control over the versions of the Cardano Node and Cardano DB Sync used in our deployment process. By defining cardano_node_image_tag and cardano_db_sync_image_tag variables in the Makefile, we now have a single point of reference for managing these versions across different deployment environments. This approach simplifies updates and ensures consistency across our infrastructure. * Makefile Enhancements: Added variables for Cardano Node and DB Sync image tags, enabling easy updates to their versions as part of the deployment process. * Docker Compose File Updates: Modified the docker-compose files for beta, dev, staging, and test environments to use these new variables. This change ensures that the specified versions of the Cardano Node and DB Sync are pulled and used in each environment, aligning with our version control strategy. By managing these versions centrally, we enhance our deployment strategy's flexibility and maintainability, ensuring that our infrastructure components are kept up-to-date in a controlled and predictable manner.

…info This commit improves the Slack notification mechanism for deployments by including comprehensive version details of the deployed components. The updated notification format provides clarity and insight into the specific versions of the Cardano Node, Cardano DB Sync, GovTool backend, and GovTool frontend that are being deployed to an environment. The notification now includes: * Environment name where the deployment is performed, highlighted with formatting for better visibility. * The branch from which the deployment is made, along with the commit hash, offering a direct link to the specific code state being deployed. * Explicit mentions of the versions for Cardano Node, Cardano DB Sync, GovTool backend, and GovTool frontend, ensuring that the deployment's scope is transparent and traceable. This structured approach to deployment notifications aims to enhance team awareness and facilitate quicker responses to any issues that may arise from specific version deployments.

… backend This commit optimizes the Docker image build and push process for the frontend and backend components of the application. It introduces a conditional check to ensure that Docker images are only built and pushed to the Amazon Elastic Container Registry (ECR) if there have been changes in their respective source directories. This is achieved by adding a helper function, check_image_on_ecr, which checks for the existence of the Docker image on ECR with the specified tag. If the image already exists, the build and push processes are skipped, thereby saving time and resources. Key Changes: * Conditional Build and Push: The build and push commands for both the frontend and backend Docker images now include a preceding check to determine if the image with the current tag already exists on ECR. * Helper Function: Introduced a new helper function, check_image_on_ecr, which utilizes the docker manifest inspect command to check for the image's presence on ECR. This function is used to conditionally execute the build and push commands based on the image's existence. * Efficiency Improvements: This approach minimizes unnecessary builds and uploads, especially useful in continuous integration and deployment (CI/CD) pipelines where build minutes and network bandwidth are valuable resources. This optimization ensures that our deployment process is both efficient and cost-effective, only utilizing resources when necessary to update the Docker images on ECR.

…info This commit improves the Slack notification mechanism for deployments by including comprehensive version details of the deployed components. The updated notification format provides clarity and insight into the specific versions of the Cardano Node, Cardano DB Sync, GovTool backend, and GovTool frontend that are being deployed to an environment. The notification now includes: * Environment name where the deployment is performed, highlighted with formatting for better visibility. * The branch from which the deployment is made, along with the commit hash, offering a direct link to the specific code state being deployed. * Explicit mentions of the versions for Cardano Node, Cardano DB Sync, GovTool backend, and GovTool frontend, ensuring that the deployment's scope is transparent and traceable. * Information about where the deploy has been triggered from: either a local machine or a pipeline. This structured approach to deployment notifications aims to enhance team awareness and facilitate quicker responses to any issues that may arise from specific version deployments.