Skip to Content
Version 18.1 by Erik Bakker on 2022/08/30 08:27
Hide last authors
Erik Bakker 15.1 1 {{container}}{{container layoutStyle="columns"}}(((
eMagiz 1.1 2 In this microlearning, we will take a look at peer reviews for eMagiz.
3
Erik Bakker 15.1 4 Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
eMagiz 1.1 5
6 == 1. Prerequisites ==
7
8 * Basic knowledge of the eMagiz platform
9
10 == 2. Key concepts ==
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. In tbe context of eMagiz, peer reviews are done usually after the Create phase.
13
Erik Bakker 15.1 14 [[image:Main.Images.Microlearning.WebHome@intermediate-devops-perspectives-peerreview-1.png]]
eMagiz 1.1 15
16 Key benefits of peer reviews
17
18 * Improved quality of integrations
19 * Higher consistency
20 * Knowledge sharing
21 * Keeping standards for optimal maintenance
22 * Architecture challenge and verification
23 * Find alternative solutions
24
25 == 3. Running peer reviews in eMagiz ==
26
27 === 3.1 Considerations for reviewee ===
28
29 Here are some things to keep in mind when presenting the work to peer review.
30
31 * Quickly explain the story / task / background
32 * Quickly show the working result if applicable / practical
33 * Talk through the solution while showing the models / code
Erik Bakker 18.1 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.
eMagiz 1.1 36 * Always do a peer review, no exceptions. Making assumptions about the usefulness beforehand defeats the whole purpose.
37
38 === 3.2 Considerations for reviewer ===
39
40 Here are some things to keep in mind when peer reviewing the work .
41
42 * Ask questions
Erik Bakker 18.1 43 ** How does this work?
44 ** Why did you decide to …?
45 ** Did you think about …?
eMagiz 1.1 46 * Spot (incorrect) assumptions
47 * Check application of best practices – see next slide
Erik Bakker 18.1 48 ** Modelling / coding patterns
49 ** Naming conventions
50 ** Errors / warnings
eMagiz 1.1 51 * Notice non-standard / unusual / abnormal things
Erik Bakker 18.1 52 ** Make sure this is documented, mainly for future changes. Annotations are very useful here.
eMagiz 1.1 53
54 === 3.3 Peer review items per ILM Phase ===
55
56 * Capture
Erik Bakker 18.1 57 ** 100% filled
58 ** Connection method clear
59 ** Authentication method clear
60 ** Definitions loaded
61 ** Sizing impact understood and valid
eMagiz 1.1 62 * Design
Erik Bakker 18.1 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
eMagiz 1.1 69 * Create
Erik Bakker 18.1 70 ** Validate routing
71 ** Generic error response flows
72 ** Check naming conventions flows, properties and XSD
73 ** Split messages in on-ramp – not later
eMagiz 1.1 74 * Deploy
Erik Bakker 18.1 75 ** Check properties
76 ** Avoid too many different flow versions – max. 2
77 ** Remove test packages that are deployed
eMagiz 1.1 78 * Manage
Erik Bakker 18.1 79 ** All alerts mapped to Customer Support
80 ** All messages can be explained
81 ** Avoid code mappings
82 ** Enable default alerts
eMagiz 1.1 83 * Architecture
Erik Bakker 18.1 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
eMagiz 1.1 88
89 == 4. Assignment ==
90
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.
92
93 == 5. Key takeaways ==
94
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
97 == 6. Suggested Additional Readings ==
98
99 You will find plenty background items available on the Internet.
100
101 == 7. Silent demonstration video ==
102
Erik Bakker 18.1 103 As this is a more theoretical microlearning we have no video for this.)))((({{toc/}}))){{/container}}{{/container}}