Skip to Content

Changes for page Peer reviews

Last modified by Danniar Firdausy on 2024/09/18 14:42
From version 16.2
edited by Erik Bakker
on 2022/06/10 10:39
Change comment: Update document after refactoring.
To version 22.6
edited by Danniar Firdausy
on 2024/09/18 14:40
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -intermediate-devops-perspectives-peerreview
1 +Peer reviews
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.ebakker
1 +XWiki.dfirdausy
Default language
... ... @@ -1,0 +1,1 @@
1 +en
Content
... ... @@ -1,13 +1,9 @@
1 1  {{container}}{{container layoutStyle="columns"}}(((
2 -= Running peer reviews inside eMagiz DevOps team =
3 3  
4 -In this microlearning, we will take a look at peer reviews for eMagiz.
3 +Welcome to this microlearning session on peer reviews with eMagiz. In this microlearning, we will explore how peer reviews can enhance the quality of your integration solutions on the eMagiz platform. We will cover essential prerequisites, key concepts, and practical tips for running effective peer reviews. Whether you are new to peer reviews or looking to refine your process, this session will provide valuable insights to help you and your team achieve higher quality and consistency.
5 5  
6 6  Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
7 7  
8 -* Last update: April 22nd, 2021
9 -* Required reading time: 8 minutes
10 -
11 11  == 1. Prerequisites ==
12 12  
13 13  * Basic knowledge of the eMagiz platform
... ... @@ -14,11 +14,15 @@
14 14  
15 15  == 2. Key concepts ==
16 16  
17 -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 +By Peer reviews, we mean: A disciplined engineering practice for detecting and correcting defects in software artifacts and preventing their leakage into production.
18 18  
15 +== 3. Running peer reviews in eMagiz ==
16 +
17 +Peer reviews is 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.
18 +
19 19  [[image:Main.Images.Microlearning.WebHome@intermediate-devops-perspectives-peerreview-1.png]]
20 20  
21 -Key benefits of peer reviews
21 +Key benefits of peer reviews:
22 22  
23 23  * Improved quality of integrations
24 24  * Higher consistency
... ... @@ -27,11 +27,13 @@
27 27  * Architecture challenge and verification
28 28  * Find alternative solutions
29 29  
30 +=== 3.1 Who and when ===
30 30  
32 +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. Running peer reviews in eMagiz ==
34 +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  
34 -=== 3.1 Considerations for reviewee ===
36 +=== 3.2 Considerations for reviewee ===
35 35  
36 36  Here are some things to keep in mind when presenting the work to peer review.
37 37  
... ... @@ -38,79 +38,71 @@
38 38  * Quickly explain the story / task / background
39 39  * Quickly show the working result if applicable / practical
40 40  * Talk through the solution while showing the models / code
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.
43 + ** Just trying to explain your work to someone else will help spot mistakes
44 + ** 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.
43 43  * Always do a peer review, no exceptions. Making assumptions about the usefulness beforehand defeats the whole purpose.
44 44  
45 -=== 3.2 Considerations for reviewer ===
47 +=== 3.3 Considerations for reviewer ===
46 46  
47 47  Here are some things to keep in mind when peer reviewing the work .
48 48  
49 49  * Ask questions
50 - * How does this work?
51 - * Why did you decide to …?
52 - * Did you think about …?
52 + ** How does this work?
53 + ** Why did you decide to …?
54 + ** Did you think about …?
53 53  * Spot (incorrect) assumptions
54 54  * Check application of best practices – see next slide
55 - * Modelling / coding patterns
56 - * Naming conventions
57 - * Errors / warnings
57 + ** Modelling / coding patterns
58 + ** Naming conventions
59 + ** Errors / warnings
58 58  * Notice non-standard / unusual / abnormal things
59 - * Make sure this is documented, mainly for future changes. Annotations are very useful here.
61 + ** Make sure this is documented, mainly for future changes. Annotations are very useful here.
60 60  
61 61  === 3.3 Peer review items per ILM Phase ===
62 62  
63 63  * Capture
64 - * 100% filled
65 - * Connection method clear
66 - * Authentication method clear
67 - * Definitions loaded
68 - * Sizing impact understood and valid
66 + ** 100% filled
67 + ** Connection method clear
68 + ** Authentication method clear
69 + ** Definitions loaded
70 + ** Sizing impact understood and valid
69 69  * Design
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
72 + ** Check solution architecture validity
73 + ** Design 100% filled and clear
74 + ** CDM Root entity mapped
75 + ** Set as mapped – avoid line mapping
76 + ** Use annotation where possible
77 + ** Proper flow and system settings
76 76  * Create
77 - * Validate routing
78 - * Generic error response flows
79 - * Check naming conventions flows, properties and XSD
80 - * Split messages in on-ramp – not later
79 + ** Validate routing
80 + ** Generic error response flows
81 + ** Check naming conventions flows, properties and XSD
82 + ** Split messages in on-ramp – not later
81 81  * Deploy
82 - * Check properties
83 - * Avoid too many different flow versions – max. 2
84 - * Remove test packages that are deployed
84 + ** Check properties
85 + ** Avoid too many different flow versions – max. 2
86 + ** Remove test packages that are deployed
85 85  * Manage
86 - * All alerts mapped to Customer Support
87 - * All messages can be explained
88 - * Avoid code mappings
89 - * Enable default alerts
88 + ** All alerts mapped to Customer Support
89 + ** All messages can be explained
90 + ** Avoid code mappings
91 + ** Enable default alerts
90 90  * Architecture
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
93 + ** Deploy connector close to the source/target system
94 + ** Ensure ACCP and PROD are exact copies
95 + ** Cloud over on-premise
96 + ** No hard-coded variable – use properties
95 95  
98 +== 4. Key takeaways ==
96 96  
97 -
98 -== 4. Assignment ==
99 -
100 -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 -
102 -== 5. Key takeaways ==
103 -
104 104  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.
105 105  
102 +== 5. Suggested Additional Readings ==
106 106  
104 +You will find plenty background items available on the Internet. If you are interested in this topic within the eMagiz platform, please see the following link:
107 107  
108 -== 6. Suggested Additional Readings ==
109 -
110 -You will find plenty background items available on the Internet.
111 -
112 -== 7. Silent demonstration video ==
113 -
114 -As this is a more theoretical microlearning we have no video for this.
115 -
106 +* [[Crash Courses (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.WebHome||target="blank"]]
107 +** [[Crash Course Platform (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.WebHome||target="blank"]]
108 +*** [[The five phases of eMagiz (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-intro-the-five-phases-of-emagiz||target="blank"]]
109 +* [[Peer Review (Search Results)>>url:https://docs.emagiz.com/bin/view/Main/Search?sort=score&sortOrder=desc&highlight=true&facet=true&r=1&f_space_facet=0%2FMain.&l_space_facet=10&f_type=DOCUMENT&f_locale=en&f_locale=&f_locale=en&text=%22peer+review%22||target="blank"]]
116 116  )))((({{toc/}}))){{/container}}{{/container}}