adambankin/gist:590891c093c310ec5694596bbe900c1d

## gistfile1.txt
• What team are you in?
Campaigns

• Is your current release process CI/CD?
We have three deployables: Nemo (Perl), Adama (Perl) and Compass (front end). None are CI/CD

• (If so)What parts are CI/CD and what parts need to change?
-

• (If not)How does your team currently release code into production?
I only know about Compass's process. We have biweekly release cycles.

On the last day of the sprint (a Thursday), we create a release candidate - which is a copy of the master branch with all of the "accepted" pull requests from the previous sprint merged in.

By "accepted" I mean each pull request is:
  - code reviewed by a peer on the product team that created the PR;
  - tested by a QA engineer for functionality and;
  - code reviewed once again by one of three Senior Engineers who operate as gatekeepers on the codebase.

As part of the creation of the release candidate, one of the gatekeepers will edit the VERSION file in the root of the repo (just a text file) by incrementing the minor version number and add "-rc1" to the end. So if the VERSION file contained  "3.120.0", it would then become "3.21.0-rc1". Changing the VERSION file runs some magic that creates a build and deploys that build to our QA environment.

The release candidate then undergoes manual and automated testing. Bugs are always found and then (almost always) corrected. Each time that corrected code is added, we increment the value after the "rc-" in the VERSION file. So for the first fix "3.21.0-rc1" is changed to "3.21.0-rc2", etc…

On the following Wednesday, we get the OK from each product team's QA representative to say that all of their team's work has been reviewed and found to be bugfree and then our Project Managers will sign off. A lead PM will liaise with an SRE and book in a time for a deploy to production

This will prompt one of the gatekeepers will remove the "rc-*" from the VERSION file. Again, magic will create a build.

An SRE will deploy the build to production

• Do you have your release process documentation in place?
Yep! https://github.com/MediaMath/compass/blob/develop/docs/workflows/workflow-for-repo-admins.md

• What metrics do you use to ensure that the code is ready for production? To ensure that it is working as expected after release?
QA folks will test the code when it's in prod (as best as possible). We have automated tests too that utilise Selenium to run a browser through various interactions

• What (form/type) measure do you suggest works better for your pipeline? Makes it more efficient (Ex: Time, amount of JIRA tickets, etc.)
More unit tests (they're all turned off now), better logging and monitoring

• How do you guarantee Quality Assurance (QA) for the code before it hits production?
Lots and lots of clicking by our offshore folks

• Are you using Heath to log?
No

• What else do you think I should know?
We have a replacement front end code base in development and CI/CD is being built in as part of the underlying framework
	• What team are you in?
	Campaigns

	• Is your current release process CI/CD?
	We have three deployables: Nemo (Perl), Adama (Perl) and Compass (front end). None are CI/CD

	• (If so)What parts are CI/CD and what parts need to change?
	-

	• (If not)How does your team currently release code into production?
	I only know about Compass's process. We have biweekly release cycles.

	On the last day of the sprint (a Thursday), we create a release candidate - which is a copy of the master branch with all of the "accepted" pull requests from the previous sprint merged in.

	By "accepted" I mean each pull request is:
	- code reviewed by a peer on the product team that created the PR;
	- tested by a QA engineer for functionality and;
	- code reviewed once again by one of three Senior Engineers who operate as gatekeepers on the codebase.

	As part of the creation of the release candidate, one of the gatekeepers will edit the VERSION file in the root of the repo (just a text file) by incrementing the minor version number and add "-rc1" to the end. So if the VERSION file contained "3.120.0", it would then become "3.21.0-rc1". Changing the VERSION file runs some magic that creates a build and deploys that build to our QA environment.

	The release candidate then undergoes manual and automated testing. Bugs are always found and then (almost always) corrected. Each time that corrected code is added, we increment the value after the "rc-" in the VERSION file. So for the first fix "3.21.0-rc1" is changed to "3.21.0-rc2", etc…

	On the following Wednesday, we get the OK from each product team's QA representative to say that all of their team's work has been reviewed and found to be bugfree and then our Project Managers will sign off. A lead PM will liaise with an SRE and book in a time for a deploy to production

	This will prompt one of the gatekeepers will remove the "rc-*" from the VERSION file. Again, magic will create a build.

	An SRE will deploy the build to production

	• Do you have your release process documentation in place?
	Yep! https://github.com/MediaMath/compass/blob/develop/docs/workflows/workflow-for-repo-admins.md

	• What metrics do you use to ensure that the code is ready for production? To ensure that it is working as expected after release?
	QA folks will test the code when it's in prod (as best as possible). We have automated tests too that utilise Selenium to run a browser through various interactions

	• What (form/type) measure do you suggest works better for your pipeline? Makes it more efficient (Ex: Time, amount of JIRA tickets, etc.)
	More unit tests (they're all turned off now), better logging and monitoring

	• How do you guarantee Quality Assurance (QA) for the code before it hits production?
	Lots and lots of clicking by our offshore folks

	• Are you using Heath to log?
	No

	• What else do you think I should know?
	We have a replacement front end code base in development and CI/CD is being built in as part of the underlying framework