Feature/continous integration continous delivery

[Shiun]

Initial draft of the CI/CD guide. Any feedback greatly appreciated.

The guide starts with why CI/CD.

Then it goes into stages of CI and CD for PRs.

And a release to Prod process that follows gitflow using tags as triggers.

[tgaff]

Good first draft. I made some mostly grammatical suggestions at this stage. I will try to do some more content review in the next pass.

• Would there be merit in broadening the discussion to include multiple available strategies? For example, this guide uses a tag-based prod deploy, but some variants of CD go straight to production on PR merge with no intermediate manual step. (testing/UAT etc sometimes happens on a PR server too)

[tgaff]

Suggested change

	Pull requests to merge code changes triggers the automation pipeline. The pipeline runs validation checks and ensures the changes are ready for peer review. The following stages go into detail how the code changes are validated. This pipeline needs to reside in a dedicated, preferrably ephemeral, environment.
	Pull requests to merge code changes trigger the automation pipeline. The pipeline runs validation checks and ensures the changes are ready for peer review. The following stages go into detail about how the code changes are validated. This pipeline needs to reside in a dedicated, and preferably ephemeral environment.

[tgaff]

I don't think 1-3 are "building". 4 definitely is.

Maybe this could be "Building and analysis" or separate sections. 1&2 could realistically be part of Testing below.

[Shiun]

Let me place 1-3 in a "Style and Static Analysis" section.

I would like to keep the "Testing" section to unit tests and functional tests (with deployment steps to the PR environment), unless you feel strongly about including 1&2 in that section.

[tgaff]

Suggested change

	1. Style/lint checks. Ensure consistency in coding styles and convention makes code easier to read and understand.
	2. Static analysis tools. Scans code for quality and potential security risks.
	3. Dependency auditing. Checks third party package for vulnerabilities and updates.
	4. Compilation (for compiled code). Catches syntax/compliation errors.
	1. Style/lint checks. Ensure consistency in coding styles and conventions, making code easier to read and understand.
	2. Static analysis tools. Scan code for quality and potential security risks.
	3. Dependency auditing. Checks third-party packages for vulnerabilities and updates.
	4. Compilation (for compiled code). Catches syntax/compilation errors.

[tgaff]

Suggested change

	1. Run unit tests. Code changes include new unit tests and modifying existing tests to ensure functionality is working as expected.
	1. Run unit tests. New code changes should include new unit tests and modification of existing tests to ensure functionality is working as expected.

[tgaff]

Suggested change

	2. Enforce test Coverage. Ensures code base meets testing coverage threshold.
	2. Enforce test coverage. Ensures code base meets testing coverage threshold.

[tgaff]

The previous ones in this section read as imperatives (commands). This one doesn't.

Suggested change

	4. Feature Acceptance on staging environment.
	4. Perform feature acceptance on the staging environment.

[tgaff]

Suggested change

Production deployment strategy should include handling rollback and recovery in case of any issues that might happen during deployment. Using release tagging with a version control like Git can help reverting the application to a previously known working state. Combined with regular backups of application data and configuration, will enable fast rollback in case of failure. The follow are steps recommended when deploying to production.

A good production deployment strategy should include handling rollback and recovery in case of any issues that might happen during deployment. Using release tagging with a version control system like Git can help with reverting the application to a previously known working state. Combined with regular backups of application data and configuration, will enable fast rollback in case of failure. The following are steps recommended when deploying to production.

or the chatgpt take:

Suggested change

Production deployment strategy should include handling rollback and recovery in case of any issues that might happen during deployment. Using release tagging with a version control like Git can help reverting the application to a previously known working state. Combined with regular backups of application data and configuration, will enable fast rollback in case of failure. The follow are steps recommended when deploying to production.

A robust production deployment strategy must encompass rollback and recovery procedures for potential deployment issues. Leveraging release tagging within a version control system such as Git facilitates reverting the application to a proven, stable state. Paired with routine backups of application data and configuration, this ensures swift rollback capabilities in the event of failure. The following steps are recommended for production deployment:```

[Shiun]

I like ChatGPT's version with maybe a few of the word replacements removed. Ex: "Paired" vs "Combined".

[tgaff]

Suggested change

	3. Automation triggers on the merging of the release tag to the source control. The automation should run through the build stage with the same checks a those for the continous integration build steps.
	3. Automation triggers on the merging of the release tag to source control. The automation should run through the build stage with the same checks as those for the continuous integration build steps.

[tgaff]

Suggested change

	4. The testing stage would run the full unit test suites, and User Acceptance Testing suites in the functional end to end testing if the application has special UAT created accounts on the production application. The goal is to have a set of UAT tests that validates the deployment but not impact production data.
	4. In the testing stage, full unit test suites, User Acceptance Testing (UAT) suites, and end-to-end functional testing are conducted. If the application utilizes special UAT accounts on the production environment, these are also included. The objective is to perform UAT tests that validate the deployment without affecting production data.

[tgaff]

There are inconsistencies in the terminology used throughout the guide. At times, "source control" is referenced without an article, while in other instances, it's preceded by "the."

Suggested change

	2. Manual approval for merging of the release tag to the source control. This acts as the final trigger for deployment to production.
	2. Manual approval for merging of the release tag to source control. This acts as the final trigger for deployment to production.

There's also some inconsistency in sentence structure for these steps...
For instance, in Step 1, Create a release tag in source control, the language resembles an instructional command. Conversely, in Step 2, Manual approval for merging of the release tag to source control, the phrasing lacks coherence as it appears more like a topic than a complete sentence. Achieving consistency in both terminology and sentence structure across all steps would enhance clarity and readability.

I think this applies to the other sections of this doc as well.

[Shiun]

Let me do another path through this to try to fix up the sentence structure. This is definitely a product of my "bullet point" draft -> turning it into a "guide" approach to writing this up.

[tgaff]

It might also be worth reading through the existing https://guides.labzero.com/continuous_delivery/testing_strategy.html guide and trying to add some links to that or there's some very relevant sections in development workflow guide (testing) and going green

Trying to match tone slightly with them could be good too. I could see this being in a future PR too.