Improving the Deployment Lifecycle (CI/CD)

[emvaldes]

We have performed a rudimentary investigation in how the deployment process is executed and as a result to this review we have identified a series of operations and workflows that can be improved upon. I will document the steps we have identified and construct a set of GitHub Issues that will be tracked within this Epic.

The existing process is manual and cumbersome as it requires a set of convoluted steps:

Note: There is an automated process that is scheduled to generate a development/yyyy-mm-dd branch (basically an ephemeral release branch) on Tuesdays and Thursdays at 3am UTC. Note: It can be destroyed and manually recreated.

These steps are executed/performed locally at someone's local system.

• Checkout/pull (update) a local repository while targeting a specific (latest) release branch.
• It's required by the engineer performing these local build/test steps to acquire an Okta authentication token that is locally stored in a file within the local repo (never pushed upstream).
• A series of environment configurations need to be in-place in order for the application to work its "magic".
• Perform several unit-testing operations (enabling and disabling VPN access) and valid IP Whitelisting must be setup because the system needs to access the Azure Staging environment to interact with the existing PostgreSQL Database.
  Note: As part of this process manual process, the Front-End Smoke Tests gets triggered using a GitHub Workflow.

These steps are then performed using GitHub Workflow/Actions:

• Both on-call engineers are required to identify if the Front-End and Back-End components in the application are fully functional. These are some basic final checkmarks to signal that a successful release candidate is available.
• If a green light is given then the on-call engineer responsible for deployments merges this deployment/yyyy-mm-dd branch into the production branch. There is a manual check-point that needs to be approved in order to proceed.
• Once this merge is completed, then the following stage pushes the artifacts into the production environment.

Critical Concerns:
In conclusion, the current process appears to be tightly coupled and lacks clearly defined building and testing stages as part of a fully automated GitHub Workflow/Actions Deployment Pipeline. A notable concern is that tests are being performed locally by engineers without a centralized, traceable system to verify and document the functionality and compliance of the Back-End.

As a result, the application is being published/deployed without a formal record of tests performed to validate compliance with requirements. This presents an opportunity for improvement to enhance transparency, accountability, and reliability in the deployment process.

Conclusion: In conclusion, the current workflow does not align with best practices, but it represents the starting point we have in place. To improve, we must transition toward a fully automated process capable of generating viable release candidates, ready for deployment either manually or automatically on a scheduled basis.

Acceptance Criteria

Generated by Zenhub AI

• Scenario: Implementing an improved CI/CD pipeline
  • Given the existing manual deployment process
  • When a new GitHub Workflow is implemented to automate the process
  • Then the workflow should include automated unit testing, environment configuration, and deployment to production
• Scenario: Ensuring transparency, accountability, and reliability
  • Given the new CI/CD pipeline
  • When a release candidate is generated
  • Then there should be a clear record of tests performed to validate compliance with requirements
• Scenario: Automated testing for Back-End components
  • Given the new CI/CD pipeline
  • When Back-End components are being tested
  • Then automated tests should be run to verify functionality and compliance with requirements
• Scenario: Ensuring proper documentation of deployment process
  • Given the new CI/CD pipeline
  • When a release candidate is generated
  • Then there should be clear documentation of the deployment process, including all steps taken and any manual interventions