Skip to Content

Changes for page Peer reviews

Last modified by Danniar Firdausy on 2024/09/18 14:42
From version 17.1
edited by eMagiz
on 2022/06/10 10:42
Change comment: There is no comment for this version
To version 21.1
edited by Erik Bakker
on 2022/08/30 08:34
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Running peer reviews inside eMagiz DevOps team
1 +Peer reviews
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.eMagiz
1 +XWiki.ebakker
Default language
... ... @@ -1,0 +1,1 @@
1 +en
Content
... ... @@ -3,9 +3,6 @@
3 3  
4 4  Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
5 5  
6 -* Last update: April 22nd, 2021
7 -* Required reading time: 8 minutes
8 -
9 9  == 1. Prerequisites ==
10 10  
11 11  * Basic knowledge of the eMagiz platform
... ... @@ -12,7 +12,7 @@
12 12  
13 13  == 2. Key concepts ==
14 14  
15 -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.
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.
16 16  
17 17  [[image:Main.Images.Microlearning.WebHome@intermediate-devops-perspectives-peerreview-1.png]]
18 18  
... ... @@ -25,74 +25,76 @@
25 25  * Architecture challenge and verification
26 26  * Find alternative solutions
27 27  
25 +== 3. Running peer reviews in eMagiz ==
28 28  
27 +=== 3.1 Who and when ===
29 29  
30 -== 3. Running peer reviews in eMagiz ==
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.
31 31  
32 -=== 3.1 Considerations for reviewee ===
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.
33 33  
33 +=== 3.2 Considerations for reviewee ===
34 +
34 34  Here are some things to keep in mind when presenting the work to peer review.
35 35  
36 36  * Quickly explain the story / task / background
37 37  * Quickly show the working result if applicable / practical
38 38  * Talk through the solution while showing the models / code
39 - * Just trying to explain your work to someone else will help spot mistakes
40 - * 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.
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.
41 41  * Always do a peer review, no exceptions. Making assumptions about the usefulness beforehand defeats the whole purpose.
42 42  
43 -=== 3.2 Considerations for reviewer ===
44 +=== 3.3 Considerations for reviewer ===
44 44  
45 45  Here are some things to keep in mind when peer reviewing the work .
46 46  
47 47  * Ask questions
48 - * How does this work?
49 - * Why did you decide to …?
50 - * Did you think about …?
49 + ** How does this work?
50 + ** Why did you decide to …?
51 + ** Did you think about …?
51 51  * Spot (incorrect) assumptions
52 52  * Check application of best practices – see next slide
53 - * Modelling / coding patterns
54 - * Naming conventions
55 - * Errors / warnings
54 + ** Modelling / coding patterns
55 + ** Naming conventions
56 + ** Errors / warnings
56 56  * Notice non-standard / unusual / abnormal things
57 - * Make sure this is documented, mainly for future changes. Annotations are very useful here.
58 + ** Make sure this is documented, mainly for future changes. Annotations are very useful here.
58 58  
59 59  === 3.3 Peer review items per ILM Phase ===
60 60  
61 61  * Capture
62 - * 100% filled
63 - * Connection method clear
64 - * Authentication method clear
65 - * Definitions loaded
66 - * Sizing impact understood and valid
63 + ** 100% filled
64 + ** Connection method clear
65 + ** Authentication method clear
66 + ** Definitions loaded
67 + ** Sizing impact understood and valid
67 67  * Design
68 - * Check solution architecture validity
69 - * Design 100% filled and clear
70 - * CDM Root entity mapped
71 - * Set as mapped – avoid line mapping
72 - * Use annotation where possible
73 - * Proper flow and system settings
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
74 74  * Create
75 - * Validate routing
76 - * Generic error response flows
77 - * Check naming conventions flows, properties and XSD
78 - * Split messages in on-ramp – not later
76 + ** Validate routing
77 + ** Generic error response flows
78 + ** Check naming conventions flows, properties and XSD
79 + ** Split messages in on-ramp – not later
79 79  * Deploy
80 - * Check properties
81 - * Avoid too many different flow versions – max. 2
82 - * Remove test packages that are deployed
81 + ** Check properties
82 + ** Avoid too many different flow versions – max. 2
83 + ** Remove test packages that are deployed
83 83  * Manage
84 - * All alerts mapped to Customer Support
85 - * All messages can be explained
86 - * Avoid code mappings
87 - * Enable default alerts
85 + ** All alerts mapped to Customer Support
86 + ** All messages can be explained
87 + ** Avoid code mappings
88 + ** Enable default alerts
88 88  * Architecture
89 - * Deploy connector close to the source/target system
90 - * Ensure ACCP and PROD are exact copies
91 - * Cloud over on-premise
92 - * No hard-coded variable – use properties
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
93 93  
94 -
95 -
96 96  == 4. Assignment ==
97 97  
98 98  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.
... ... @@ -101,8 +101,6 @@
101 101  
102 102  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.
103 103  
104 -
105 -
106 106  == 6. Suggested Additional Readings ==
107 107  
108 108  You will find plenty background items available on the Internet.
... ... @@ -109,6 +109,4 @@
109 109  
110 110  == 7. Silent demonstration video ==
111 111  
112 -As this is a more theoretical microlearning we have no video for this.
113 -
114 -)))((({{toc/}}))){{/container}}{{/container}}
109 +As this is a more theoretical microlearning we have no video for this.)))((({{toc/}}))){{/container}}{{/container}}