Changes for page Peer reviews
Last modified by Danniar Firdausy on 2024/09/18 14:42
From version 18.1
edited by Erik Bakker
on 2022/08/30 08:27
on 2022/08/30 08:27
Change comment:
There is no comment for this version
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 mistakes35 - * *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 patterns49 - * *Naming conventions50 - * *Errors / warnings55 + * 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% filled58 - * *Connection method clear59 - * *Authentication method clear60 - * *Definitions loaded61 - * *Sizing impact understood and valid64 + * 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 validity64 - * *Design 100% filled and clear65 - * *CDM Root entity mapped66 - * *Set as mapped – avoid line mapping67 - * *Use annotation where possible68 - * *Proper flow and system settings70 + * 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 routing71 - * *Generic error response flows72 - * *Check naming conventions flows, properties and XSD73 - * *Split messages in on-ramp – not later77 + * 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 properties76 - * *Avoid too many different flow versions – max. 277 - * *Remove test packages that are deployed82 + * 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 Support80 - * *All messages can be explained81 - * *Avoid code mappings82 - * *Enable default alerts86 + * 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 system85 - * *Ensure ACCP and PROD are exact copies86 - * *Cloud over on-premise87 - * *No hard-coded variable – use properties91 + * 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}}