Changes for page Peer reviews

Summary

• Page properties (3 modified, 0 added, 0 removed)

Details

Page properties

Title

...	...	@@ -1,1 +1,0 @@
1		-Running peer reviews inside eMagiz DevOps team

Parent

...	...	@@ -1,1 +1,0 @@
1		-WebHome

Content

...	...	@@ -1,8 +1,13 @@
1	1	{{container}}{{container layoutStyle="columns"}}(((
	2	+= Running peer reviews inside eMagiz DevOps team =
	3	+
2	2	In this microlearning, we will take a look at peer reviews for eMagiz.
3	3
4	4	Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
5	5
	8	+* Last update: April 22nd, 2021
	9	+* Required reading time: 8 minutes
	10	+
6	6	== 1. Prerequisites ==
7	7
8	8	* Basic knowledge of the eMagiz platform
...	...	@@ -22,6 +22,8 @@
22	22	* Architecture challenge and verification
23	23	* Find alternative solutions
24	24
	30	+
	31	+
25	25	== 3. Running peer reviews in eMagiz ==
26	26
27	27	=== 3.1 Considerations for reviewee ===
...	...	@@ -31,8 +31,8 @@
31	31	* Quickly explain the story / task / background
32	32	* Quickly show the working result if applicable / practical
33	33	* Talk through the solution while showing the models / code
34		- ** Just trying to explain your work to someone else will help spot mistakes
35		- ** Don’t show every single detail but try to highlight the important parts and/or details you’re less sure about. This takes time and experience to get “right” and is different depending on the story, the reviewee, the reviewer, the project, etc.
	41	+ * Just trying to explain your work to someone else will help spot mistakes
	42	+ * Don’t show every single detail but try to highlight the important parts and/or details you’re less sure about. This takes time and experience to get “right” and is different depending on the story, the reviewee, the reviewer, the project, etc.
36	36	* Always do a peer review, no exceptions. Making assumptions about the usefulness beforehand defeats the whole purpose.
37	37
38	38	=== 3.2 Considerations for reviewer ===
...	...	@@ -40,52 +40,54 @@
40	40	Here are some things to keep in mind when peer reviewing the work .
41	41
42	42	* Ask questions
43		- ** How does this work?
44		- ** Why did you decide to …?
45		- ** Did you think about …?
	50	+ * How does this work?
	51	+ * Why did you decide to …?
	52	+ * Did you think about …?
46	46	* Spot (incorrect) assumptions
47	47	* Check application of best practices – see next slide
48		- ** Modelling / coding patterns
49		- ** Naming conventions
50		- ** Errors / warnings
	55	+ * Modelling / coding patterns
	56	+ * Naming conventions
	57	+ * Errors / warnings
51	51	* Notice non-standard / unusual / abnormal things
52		- ** Make sure this is documented, mainly for future changes. Annotations are very useful here.
	59	+ * Make sure this is documented, mainly for future changes. Annotations are very useful here.
53	53
54	54	=== 3.3 Peer review items per ILM Phase ===
55	55
56	56	* Capture
57		- ** 100% filled
58		- ** Connection method clear
59		- ** Authentication method clear
60		- ** Definitions loaded
61		- ** Sizing impact understood and valid
	64	+ * 100% filled
	65	+ * Connection method clear
	66	+ * Authentication method clear
	67	+ * Definitions loaded
	68	+ * Sizing impact understood and valid
62	62	* Design
63		- ** Check solution architecture validity
64		- ** Design 100% filled and clear
65		- ** CDM Root entity mapped
66		- ** Set as mapped – avoid line mapping
67		- ** Use annotation where possible
68		- ** Proper flow and system settings
	70	+ * Check solution architecture validity
	71	+ * Design 100% filled and clear
	72	+ * CDM Root entity mapped
	73	+ * Set as mapped – avoid line mapping
	74	+ * Use annotation where possible
	75	+ * Proper flow and system settings
69	69	* Create
70		- ** Validate routing
71		- ** Generic error response flows
72		- ** Check naming conventions flows, properties and XSD
73		- ** Split messages in on-ramp – not later
	77	+ * Validate routing
	78	+ * Generic error response flows
	79	+ * Check naming conventions flows, properties and XSD
	80	+ * Split messages in on-ramp – not later
74	74	* Deploy
75		- ** Check properties
76		- ** Avoid too many different flow versions – max. 2
77		- ** Remove test packages that are deployed
	82	+ * Check properties
	83	+ * Avoid too many different flow versions – max. 2
	84	+ * Remove test packages that are deployed
78	78	* Manage
79		- ** All alerts mapped to Customer Support
80		- ** All messages can be explained
81		- ** Avoid code mappings
82		- ** Enable default alerts
	86	+ * All alerts mapped to Customer Support
	87	+ * All messages can be explained
	88	+ * Avoid code mappings
	89	+ * Enable default alerts
83	83	* Architecture
84		- ** Deploy connector close to the source/target system
85		- ** Ensure ACCP and PROD are exact copies
86		- ** Cloud over on-premise
87		- ** No hard-coded variable – use properties
	91	+ * Deploy connector close to the source/target system
	92	+ * Ensure ACCP and PROD are exact copies
	93	+ * Cloud over on-premise
	94	+ * No hard-coded variable – use properties
88	88
	96	+
	97	+
89	89	== 4. Assignment ==
90	90
91	91	See how peer reviews are currently implemented within the projects on which you work to see if you can learn something from the information you have gathered via this microlearning.
...	...	@@ -94,6 +94,8 @@
94	94
95	95	Peer reviews are instrumental in any DevOps team. Use the provided list as your team's peer review starting point and tune as you go along.
96	96
	106	+
	107	+
97	97	== 6. Suggested Additional Readings ==
98	98
99	99	You will find plenty background items available on the Internet.
...	...	@@ -100,4 +100,6 @@
100	100
101	101	== 7. Silent demonstration video ==
102	102
103		-As this is a more theoretical microlearning we have no video for this.)))((({{toc/}}))){{/container}}{{/container}}
	114	+As this is a more theoretical microlearning we have no video for this.
	115	+
	116	+)))((({{toc/}}))){{/container}}{{/container}}