Changes for page Peer reviews
Last modified by Danniar Firdausy on 2024/09/18 14:42
From version 13.1
edited by eMagiz
on 2022/05/17 09:10
on 2022/05/17 09:10
Change comment:
There is no comment for this version
To version 20.1
edited by Erik Bakker
on 2022/08/30 08:28
on 2022/08/30 08:28
Change comment:
There is no comment for this version
Summary
-
Page properties (4 modified, 0 added, 0 removed)
Details
- Page properties
-
- Title
-
... ... @@ -1,0 +1,1 @@ 1 +Peer reviews - Parent
-
... ... @@ -1,0 +1,1 @@ 1 +WebHome - Author
-
... ... @@ -1,1 +1,1 @@ 1 -XWiki. marijn1 +XWiki.ebakker - Content
-
... ... @@ -1,20 +1,8 @@ 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 - 1 +{{container}}{{container layoutStyle="columns"}}((( 11 11 In this microlearning, we will take a look at peer reviews for eMagiz. 12 12 13 -Should you have any questions, please contact academy@emagiz.com. 4 +Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]]. 14 14 15 -* Last update: April 22nd, 2021 16 -* Required reading time: 8 minutes 17 - 18 18 == 1. Prerequisites == 19 19 20 20 * Basic knowledge of the eMagiz platform ... ... @@ -21,9 +21,9 @@ 21 21 22 22 == 2. Key concepts == 23 23 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 t be 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. In the context of eMagiz, peer reviews are done usually after the Create phase. 25 25 26 - <p align="center">[[image:intermediate-devops-perspectives-peerreview-1.png||]]</p>14 +[[image:Main.Images.Microlearning.WebHome@intermediate-devops-perspectives-peerreview-1.png]] 27 27 28 28 Key benefits of peer reviews 29 29 ... ... @@ -34,8 +34,6 @@ 34 34 * Architecture challenge and verification 35 35 * Find alternative solutions 36 36 37 - 38 - 39 39 == 3. Running peer reviews in eMagiz == 40 40 41 41 === 3.1 Considerations for reviewee === ... ... @@ -45,8 +45,8 @@ 45 45 * Quickly explain the story / task / background 46 46 * Quickly show the working result if applicable / practical 47 47 * Talk through the solution while showing the models / code 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. 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. 50 50 * Always do a peer review, no exceptions. Making assumptions about the usefulness beforehand defeats the whole purpose. 51 51 52 52 === 3.2 Considerations for reviewer === ... ... @@ -54,54 +54,52 @@ 54 54 Here are some things to keep in mind when peer reviewing the work . 55 55 56 56 * Ask questions 57 - * How does this work? 58 - * Why did you decide to …? 59 - * Did you think about …? 43 + ** How does this work? 44 + ** Why did you decide to …? 45 + ** Did you think about …? 60 60 * Spot (incorrect) assumptions 61 61 * Check application of best practices – see next slide 62 - * Modelling / coding patterns 63 - * Naming conventions 64 - * Errors / warnings 48 + ** Modelling / coding patterns 49 + ** Naming conventions 50 + ** Errors / warnings 65 65 * Notice non-standard / unusual / abnormal things 66 - * Make sure this is documented, mainly for future changes. Annotations are very useful here. 52 + ** Make sure this is documented, mainly for future changes. Annotations are very useful here. 67 67 68 68 === 3.3 Peer review items per ILM Phase === 69 69 70 70 * Capture 71 - * 100% filled 72 - * Connection method clear 73 - * Authentication method clear 74 - * Definitions loaded 75 - * Sizing impact understood and valid 57 + ** 100% filled 58 + ** Connection method clear 59 + ** Authentication method clear 60 + ** Definitions loaded 61 + ** Sizing impact understood and valid 76 76 * Design 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 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 83 83 * Create 84 - * Validate routing 85 - * Generic error response flows 86 - * Check naming conventions flows, properties and XSD 87 - * Split messages in on-ramp – not later 70 + ** Validate routing 71 + ** Generic error response flows 72 + ** Check naming conventions flows, properties and XSD 73 + ** Split messages in on-ramp – not later 88 88 * Deploy 89 - * Check properties 90 - * Avoid too many different flow versions – max. 2 91 - * Remove test packages that are deployed 75 + ** Check properties 76 + ** Avoid too many different flow versions – max. 2 77 + ** Remove test packages that are deployed 92 92 * Manage 93 - * All alerts mapped to Customer Support 94 - * All messages can be explained 95 - * Avoid code mappings 96 - * Enable default alerts 79 + ** All alerts mapped to Customer Support 80 + ** All messages can be explained 81 + ** Avoid code mappings 82 + ** Enable default alerts 97 97 * Architecture 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 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 102 102 103 -===== Practice ===== 104 - 105 105 == 4. Assignment == 106 106 107 107 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. ... ... @@ -110,8 +110,6 @@ 110 110 111 111 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. 112 112 113 - 114 - 115 115 == 6. Suggested Additional Readings == 116 116 117 117 You will find plenty background items available on the Internet. ... ... @@ -118,11 +118,4 @@ 118 118 119 119 == 7. Silent demonstration video == 120 120 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}} 103 +As this is a more theoretical microlearning we have no video for this.)))((({{toc/}}))){{/container}}{{/container}}