Changes for page Peer reviews

Summary

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

Details

Page properties

Title

...	...	@@ -1,1 +1,0 @@
1		-Peer reviews

Parent

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

Author

...	...	@@ -1,1 +1,1 @@
1		-XWiki.ebakker
	1	+XWiki.marijn

Default language

...	...	@@ -1,1 +1,0 @@
1		-en

Content

...	...	@@ -1,8 +1,20 @@
1		-{{container}}{{container layoutStyle="columns"}}(((
	1	+{{html wiki="true"}}
	2	+<div class="ez-academy">
	3	+ <div class="ez-academy_body">
	4	+
	5	+<div class="doc">
	6	+
	7	+
	8	+
	9	+= Running peer reviews inside eMagiz DevOps team =
	10	+
2	2	In this microlearning, we will take a look at peer reviews for eMagiz.
3	3
4		-Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
	13	+Should you have any questions, please contact academy@emagiz.com.
5	5
	15	+* Last update: April 22nd, 2021
	16	+* Required reading time: 8 minutes
	17	+
6	6	== 1. Prerequisites ==
7	7
8	8	* Basic knowledge of the eMagiz platform
...	...	@@ -9,9 +9,9 @@
9	9
10	10	== 2. Key concepts ==
11	11
12		-Peer reviews are defined as follows: A disciplined engineering practice for detecting and correcting defects in software artifacts and preventing their leakage into production. Its a well known and working concept with IT organization, and it can definetely applied in DevOps teams that have eMagiz as one of the technology pillars.
	24	+Peer reviews are defined as follows: A disciplined engineering practice for detecting and correcting defects in software artifacts and preventing their leakage into production. Its a well known and working concept with IT organization, and it can definetely applied in DevOps teams that have eMagiz as one of the technology pillars. In tbe context of eMagiz, peer reviews are done usually after the Create phase.
13	13
14		-[[image:Main.Images.Microlearning.WebHome@intermediate-devops-perspectives-peerreview-1.png]]
	26	+<p align="center">[[image:intermediate-devops-perspectives-peerreview-1.png||]]</p>
15	15
16	16	Key benefits of peer reviews
17	17
...	...	@@ -22,76 +22,74 @@
22	22	* Architecture challenge and verification
23	23	* Find alternative solutions
24	24
25		-== 3. Running peer reviews in eMagiz ==
26	26
27		-=== 3.1 Who and when ===
28	28
29		-Doing peer reviews increases the quality of the delivered work by the team. This means it is the whole team's responsibility to ensure peer reviews are performed. Following that logic, asking different individuals within your team for other peer reviews makes sense.
	39	+== 3. Running peer reviews in eMagiz ==
30	30
31		-As described below, peer reviews should be conducted for every critical decision when building an integration solution via the eMagiz platform. See section 3.3 for a detailed list.
	41	+=== 3.1 Considerations for reviewee ===
32	32
33		-=== 3.2 Considerations for reviewee ===
34		-
35	35	Here are some things to keep in mind when presenting the work to peer review.
36	36
37	37	* Quickly explain the story / task / background
38	38	* Quickly show the working result if applicable / practical
39	39	* Talk through the solution while showing the models / code
40		- ** Just trying to explain your work to someone else will help spot mistakes
41		- ** 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.
	48	+ * Just trying to explain your work to someone else will help spot mistakes
	49	+ * 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.
42	42	* Always do a peer review, no exceptions. Making assumptions about the usefulness beforehand defeats the whole purpose.
43	43
44		-=== 3.3 Considerations for reviewer ===
	52	+=== 3.2 Considerations for reviewer ===
45	45
46	46	Here are some things to keep in mind when peer reviewing the work .
47	47
48	48	* Ask questions
49		- ** How does this work?
50		- ** Why did you decide to …?
51		- ** Did you think about …?
	57	+ * How does this work?
	58	+ * Why did you decide to …?
	59	+ * Did you think about …?
52	52	* Spot (incorrect) assumptions
53	53	* Check application of best practices – see next slide
54		- ** Modelling / coding patterns
55		- ** Naming conventions
56		- ** Errors / warnings
	62	+ * Modelling / coding patterns
	63	+ * Naming conventions
	64	+ * Errors / warnings
57	57	* Notice non-standard / unusual / abnormal things
58		- ** Make sure this is documented, mainly for future changes. Annotations are very useful here.
	66	+ * Make sure this is documented, mainly for future changes. Annotations are very useful here.
59	59
60	60	=== 3.3 Peer review items per ILM Phase ===
61	61
62	62	* Capture
63		- ** 100% filled
64		- ** Connection method clear
65		- ** Authentication method clear
66		- ** Definitions loaded
67		- ** Sizing impact understood and valid
	71	+ * 100% filled
	72	+ * Connection method clear
	73	+ * Authentication method clear
	74	+ * Definitions loaded
	75	+ * Sizing impact understood and valid
68	68	* Design
69		- ** Check solution architecture validity
70		- ** Design 100% filled and clear
71		- ** CDM Root entity mapped
72		- ** Set as mapped – avoid line mapping
73		- ** Use annotation where possible
74		- ** Proper flow and system settings
	77	+ * Check solution architecture validity
	78	+ * Design 100% filled and clear
	79	+ * CDM Root entity mapped
	80	+ * Set as mapped – avoid line mapping
	81	+ * Use annotation where possible
	82	+ * Proper flow and system settings
75	75	* Create
76		- ** Validate routing
77		- ** Generic error response flows
78		- ** Check naming conventions flows, properties and XSD
79		- ** Split messages in on-ramp – not later
	84	+ * Validate routing
	85	+ * Generic error response flows
	86	+ * Check naming conventions flows, properties and XSD
	87	+ * Split messages in on-ramp – not later
80	80	* Deploy
81		- ** Check properties
82		- ** Avoid too many different flow versions – max. 2
83		- ** Remove test packages that are deployed
	89	+ * Check properties
	90	+ * Avoid too many different flow versions – max. 2
	91	+ * Remove test packages that are deployed
84	84	* Manage
85		- ** All alerts mapped to Customer Support
86		- ** All messages can be explained
87		- ** Avoid code mappings
88		- ** Enable default alerts
	93	+ * All alerts mapped to Customer Support
	94	+ * All messages can be explained
	95	+ * Avoid code mappings
	96	+ * Enable default alerts
89	89	* Architecture
90		- ** Deploy connector close to the source/target system
91		- ** Ensure ACCP and PROD are exact copies
92		- ** Cloud over on-premise
93		- ** No hard-coded variable – use properties
	98	+ * Deploy connector close to the source/target system
	99	+ * Ensure ACCP and PROD are exact copies
	100	+ * Cloud over on-premise
	101	+ * No hard-coded variable – use properties
94	94
	103	+===== Practice =====
	104	+
95	95	== 4. Assignment ==
96	96
97	97	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.
...	...	@@ -100,6 +100,8 @@
100	100
101	101	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.
102	102
	113	+
	114	+
103	103	== 6. Suggested Additional Readings ==
104	104
105	105	You will find plenty background items available on the Internet.
...	...	@@ -106,4 +106,11 @@
106	106
107	107	== 7. Silent demonstration video ==
108	108
109		-As this is a more theoretical microlearning we have no video for this.)))((({{toc/}}))){{/container}}{{/container}}
	121	+As this is a more theoretical microlearning we have no video for this.
	122	+
	123	+</div>
	124	+
	125	+</div>
	126	+</div>
	127	+
	128	+{{/html}}