Dl/Product Release Checklist - Revision history

Stonezhong: /* CICD Pipeline */

2024-02-07T17:55:26Z

CICD Pipeline

← Older revision		Revision as of 17:55, 7 February 2024
Line 113:		Line 113:
	* Your product's development environment should support CICD		* Your product's development environment should support CICD
	* Any product using Python should have at least 80% of code coverage (line based, branch based)		* Any product using Python should have at least 80% of code coverage (line based, branch based)
			</div>
			</div>
			<p></p>

			= Data Safety =
			<div class="toccolours mw-collapsible mw-collapsed expandable">
			<div class="mw-collapsible-preview"></div>
			<div class="mw-collapsible-content">
			* To prevent from physical data loss or logical data loss, you need to backup data periodically
			* Certain percent of data lost is tolerable since backup does not happen continously.
	</div>		</div>
	</div>		</div>
	<p></p>		<p></p>

2024-02-06T23:18:38Z

User facing document

@@ Line 93: / Line 93: @@
 * Any product should have a user facing document.
 * User facing document should be in sync with product evolvement
 </div>
 </div>

2024-02-06T23:16:28Z

User facing document

← Older revision		Revision as of 23:16, 6 February 2024
Line 93:		Line 93:
	* Any product should have a user facing document.		* Any product should have a user facing document.
	* User facing document should be in sync with product evolvement		* User facing document should be in sync with product evolvement
			</div>
			</div>
			<p></p>

			= CICD Pipeline =
			<div class="toccolours mw-collapsible mw-collapsed expandable">
			<div class="mw-collapsible-preview"></div>
			<div class="mw-collapsible-content">
			* Your product's development environment should support CICD
			* Any product using Python should have at least 80% of code coverage (line based, branch based)
	</div>		</div>
	</div>		</div>
	<p></p>		<p></p>

2024-02-06T23:16:03Z

Beta Environment

← Older revision		Revision as of 23:16, 6 February 2024
Line 83:		Line 83:
	* For any product, you should have a beta environment		* For any product, you should have a beta environment
	* You should always deploy your change to beta environment first, verify nothing is broken before deploy to production.		* You should always deploy your change to beta environment first, verify nothing is broken before deploy to production.
			</div>
			</div>
			<p></p>

			= User facing document =
			<div class="toccolours mw-collapsible mw-collapsed expandable">
			<div class="mw-collapsible-preview"></div>
			<div class="mw-collapsible-content">
			* Any product should have a user facing document.
			* User facing document should be in sync with product evolvement
	</div>		</div>
	</div>		</div>
	<p></p>		<p></p>

2024-02-06T23:15:32Z

← Older revision		Revision as of 23:15, 6 February 2024
Line 73:		Line 73:
	* You should deploy your service over the day-to-day capacity. For example, you should be prepared your service to handle 200% of traffic comparing your normal traffic.		* You should deploy your service over the day-to-day capacity. For example, you should be prepared your service to handle 200% of traffic comparing your normal traffic.
	* You should have "capacity review" constantly, a common practice is to review capacity every year, and book the capacity for the entire year (with predicted growth)		* You should have "capacity review" constantly, a common practice is to review capacity every year, and book the capacity for the entire year (with predicted growth)
			</div>
			</div>
			<p></p>

			= Beta Environment =
			<div class="toccolours mw-collapsible mw-collapsed expandable">
			<div class="mw-collapsible-preview"></div>
			<div class="mw-collapsible-content">
			* For any product, you should have a beta environment
			* You should always deploy your change to beta environment first, verify nothing is broken before deploy to production.
	</div>		</div>
	</div>		</div>
	<p></p>		<p></p>

2024-02-06T23:15:01Z

Service Availability

← Older revision		Revision as of 23:15, 6 February 2024
Line 63:		Line 63:
	* Highly Available		* Highly Available
	** Your service should be highly available. A common pattern is haing redundancy, so if your active server is down, your standby server can take over the control. And we expect the switch to be automatic.		** Your service should be highly available. A common pattern is haing redundancy, so if your active server is down, your standby server can take over the control. And we expect the switch to be automatic.
			</div>
			</div>
			<p></p>

			= Capacity =
			<div class="toccolours mw-collapsible mw-collapsed expandable">
			<div class="mw-collapsible-preview"></div>
			<div class="mw-collapsible-content">
			* You should deploy your service over the day-to-day capacity. For example, you should be prepared your service to handle 200% of traffic comparing your normal traffic.
			* You should have "capacity review" constantly, a common practice is to review capacity every year, and book the capacity for the entire year (with predicted growth)
	</div>		</div>
	</div>		</div>
	<p></p>		<p></p>

2024-02-06T23:14:28Z

← Older revision		Revision as of 23:14, 6 February 2024
Line 53:		Line 53:
	** Your Web UI should use SSO to authenticate user. An anti pattern is to have your product maintain it's own username/password, (e.g. current Airflow for Tier-1 and Tier-2)		** Your Web UI should use SSO to authenticate user. An anti pattern is to have your product maintain it's own username/password, (e.g. current Airflow for Tier-1 and Tier-2)
	*** Having 4~5 products with each maintain their own username and password is a nightmare!		*** Having 4~5 products with each maintain their own username and password is a nightmare!
			</div>
			</div>
			<p></p>

			= Service Availability =
			<div class="toccolours mw-collapsible mw-collapsed expandable">
			<div class="mw-collapsible-preview"></div>
			<div class="mw-collapsible-content">
			* Highly Available
			** Your service should be highly available. A common pattern is haing redundancy, so if your active server is down, your standby server can take over the control. And we expect the switch to be automatic.
	</div>		</div>
	</div>		</div>
	<p></p>		<p></p>

2024-02-06T23:13:45Z

Security

← Older revision		Revision as of 23:13, 6 February 2024
Line 53:		Line 53:
	** Your Web UI should use SSO to authenticate user. An anti pattern is to have your product maintain it's own username/password, (e.g. current Airflow for Tier-1 and Tier-2)		** Your Web UI should use SSO to authenticate user. An anti pattern is to have your product maintain it's own username/password, (e.g. current Airflow for Tier-1 and Tier-2)
	*** Having 4~5 products with each maintain their own username and password is a nightmare!		*** Having 4~5 products with each maintain their own username and password is a nightmare!


	</div>		</div>
	</div>		</div>
	<p></p>		<p></p>

2024-02-06T23:13:24Z

Alarms

@@ Line 26: / Line 26: @@
 * You should define alarms based on your telemetrics
 * The alarm should be able to notify your devop, for example, via pagerduty
 </div>
 </div>
 <p></p>

2024-02-06T23:11:24Z

← Older revision		Revision as of 23:11, 6 February 2024
Line 16:		Line 16:
	* Your application should emit telemetrics (time series) to a metrics system (e.g. AWS Cloud Watch)		* Your application should emit telemetrics (time series) to a metrics system (e.g. AWS Cloud Watch)
	* You should have a centrailzed UI to watch telemetrics from different service/component of your product		* You should have a centrailzed UI to watch telemetrics from different service/component of your product
			</div>
			</div>
			<p></p>

			= Alarms =
			<div class="toccolours mw-collapsible mw-collapsed expandable">
			<div class="mw-collapsible-preview"></div>
			<div class="mw-collapsible-content">
			* You should define alarms based on your telemetrics
			* The alarm should be able to notify your devop, for example, via pagerduty
	</div>		</div>
	</div>		</div>
	<p></p>		<p></p>