Changes for page Peer reviews
Last modified by Danniar Firdausy on 2024/09/18 14:42
From version 22.7
edited by Danniar Firdausy
on 2024/09/18 14:40
on 2024/09/18 14:40
Change comment:
There is no comment for this version
Summary
-
Page properties (5 modified, 0 added, 0 removed)
Details
- Page properties
-
- Title
-
... ... @@ -1,1 +1,0 @@ 1 -Peer reviews - Parent
-
... ... @@ -1,1 +1,0 @@ 1 -WebHome - Author
-
... ... @@ -1,1 +1,1 @@ 1 -XWiki. dfirdausy1 +XWiki.marijn - Default language
-
... ... @@ -1,1 +1,0 @@ 1 -en - Content
-
... ... @@ -1,9 +1,20 @@ 1 -{{container}}{{container layoutStyle="columns"}}((( 1 +{{html wiki="true"}} 2 +<div class="ez-academy"> 3 + <div class="ez-academy_body"> 2 2 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, andpractical tips for running effectivepeer reviews. Whether you are new to peer reviews or looking to refine your process, this session will provide valuable insightsto help you andyour team achieve higher quality and consistency.5 +<div class="doc"> 4 4 5 -Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]]. 6 6 8 + 9 += Running peer reviews inside eMagiz DevOps team = 10 + 11 +In this microlearning, we will take a look at peer reviews for eMagiz. 12 + 13 +Should you have any questions, please contact academy@emagiz.com. 14 + 15 +* Last update: April 22nd, 2021 16 +* Required reading time: 8 minutes 17 + 7 7 == 1. Prerequisites == 8 8 9 9 * Basic knowledge of the eMagiz platform ... ... @@ -10,17 +10,12 @@ 10 10 11 11 == 2. Key concepts == 12 12 13 -This microlearning centers on peer-reviews. 14 -* By Peer reviews, we mean: A disciplined engineering practice for detecting and correcting defects in software artifacts and preventing their leakage into production. 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 tbe context of eMagiz, peer reviews are done usually after the Create phase. 15 15 16 - ==3. Runnings ineMagiz ==26 +<p align="center">[[image:intermediate-devops-perspectives-peerreview-1.png||]]</p> 17 17 18 - Peerreviews is a well known and working concept withITorganization, and it can definetelyapplied in DevOpsteams that have eMagiz as oneof the technology pillars.28 +Key benefits of peer reviews 19 19 20 -[[image:Main.Images.Microlearning.WebHome@intermediate-devops-perspectives-peerreview-1.png]] 21 - 22 -Key benefits of peer reviews: 23 - 24 24 * Improved quality of integrations 25 25 * Higher consistency 26 26 * Knowledge sharing ... ... @@ -28,13 +28,11 @@ 28 28 * Architecture challenge and verification 29 29 * Find alternative solutions 30 30 31 -=== 3.1 Who and when === 32 32 33 -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. 34 34 35 - Asdescribedbelow,peer reviewsshould be conducted for every critical decisionwhen building an integration solution via the eMagizplatform. See section 3.3 for a detailed list.39 +== 3. Running peer reviews in eMagiz == 36 36 37 -=== 3. 2Considerations for reviewee ===41 +=== 3.1 Considerations for reviewee === 38 38 39 39 Here are some things to keep in mind when presenting the work to peer review. 40 40 ... ... @@ -41,71 +41,84 @@ 41 41 * Quickly explain the story / task / background 42 42 * Quickly show the working result if applicable / practical 43 43 * Talk through the solution while showing the models / code 44 - * *Just trying to explain your work to someone else will help spot mistakes45 - * *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.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. 46 46 * Always do a peer review, no exceptions. Making assumptions about the usefulness beforehand defeats the whole purpose. 47 47 48 -=== 3. 3Considerations for reviewer ===52 +=== 3.2 Considerations for reviewer === 49 49 50 50 Here are some things to keep in mind when peer reviewing the work . 51 51 52 52 * Ask questions 53 - * *How does this work?54 - * *Why did you decide to …?55 - * *Did you think about …?57 + * How does this work? 58 + * Why did you decide to …? 59 + * Did you think about …? 56 56 * Spot (incorrect) assumptions 57 57 * Check application of best practices – see next slide 58 - * *Modelling / coding patterns59 - * *Naming conventions60 - * *Errors / warnings62 + * Modelling / coding patterns 63 + * Naming conventions 64 + * Errors / warnings 61 61 * Notice non-standard / unusual / abnormal things 62 - * *Make sure this is documented, mainly for future changes. Annotations are very useful here.66 + * Make sure this is documented, mainly for future changes. Annotations are very useful here. 63 63 64 64 === 3.3 Peer review items per ILM Phase === 65 65 66 66 * Capture 67 - * *100% filled68 - * *Connection method clear69 - * *Authentication method clear70 - * *Definitions loaded71 - * *Sizing impact understood and valid71 + * 100% filled 72 + * Connection method clear 73 + * Authentication method clear 74 + * Definitions loaded 75 + * Sizing impact understood and valid 72 72 * Design 73 - * *Check solution architecture validity74 - * *Design 100% filled and clear75 - * *CDM Root entity mapped76 - * *Set as mapped – avoid line mapping77 - * *Use annotation where possible78 - * *Proper flow and system settings77 + * 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 79 79 * Create 80 - * *Validate routing81 - * *Generic error response flows82 - * *Check naming conventions flows, properties and XSD83 - * *Split messages in on-ramp – not later84 + * Validate routing 85 + * Generic error response flows 86 + * Check naming conventions flows, properties and XSD 87 + * Split messages in on-ramp – not later 84 84 * Deploy 85 - * *Check properties86 - * *Avoid too many different flow versions – max. 287 - * *Remove test packages that are deployed89 + * Check properties 90 + * Avoid too many different flow versions – max. 2 91 + * Remove test packages that are deployed 88 88 * Manage 89 - * *All alerts mapped to Customer Support90 - * *All messages can be explained91 - * *Avoid code mappings92 - * *Enable default alerts93 + * All alerts mapped to Customer Support 94 + * All messages can be explained 95 + * Avoid code mappings 96 + * Enable default alerts 93 93 * Architecture 94 - * *Deploy connector close to the source/target system95 - * *Ensure ACCP and PROD are exact copies96 - * *Cloud over on-premise97 - * *No hard-coded variable – use properties98 + * 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 98 98 99 -== 4. Key takeaways==103 +===== Practice ===== 100 100 105 +== 4. Assignment == 106 + 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. 108 + 109 +== 5. Key takeaways == 110 + 101 101 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. 102 102 103 -== 5. Suggested Additional Readings == 104 104 105 -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: 106 106 107 -* [[Crash Courses (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.WebHome||target="blank"]] 108 -** [[Crash Course Platform (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.WebHome||target="blank"]] 109 -*** [[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"]] 110 -* [[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"]] 111 -)))((({{toc/}}))){{/container}}{{/container}} 115 +== 6. Suggested Additional Readings == 116 + 117 +You will find plenty background items available on the Internet. 118 + 119 +== 7. Silent demonstration video == 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}}