Changes for page Peer reviews
Last modified by Danniar Firdausy on 2024/09/18 14:42
From version 17.1
edited by eMagiz
on 2022/06/10 10:42
on 2022/06/10 10:42
Change comment:
There is no comment for this version
To version 22.6
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 (4 modified, 0 added, 0 removed)
Details
- Page properties
-
- Title
-
... ... @@ -1,1 +1,1 @@ 1 - Running peer reviewsinside eMagiz DevOps team1 +Peer reviews - Author
-
... ... @@ -1,1 +1,1 @@ 1 -XWiki. eMagiz1 +XWiki.dfirdausy - Default language
-
... ... @@ -1,0 +1,1 @@ 1 +en - Content
-
... ... @@ -1,11 +1,9 @@ 1 1 {{container}}{{container layoutStyle="columns"}}((( 2 -In this microlearning, we will take a look at peer reviews for eMagiz. 3 3 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. 4 + 4 4 Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]]. 5 5 6 -* Last update: April 22nd, 2021 7 -* Required reading time: 8 minutes 8 - 9 9 == 1. Prerequisites == 10 10 11 11 * Basic knowledge of the eMagiz platform ... ... @@ -12,11 +12,15 @@ 12 12 13 13 == 2. Key concepts == 14 14 15 -Peer reviews aredefinedas 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. 16 16 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 + 17 17 [[image:Main.Images.Microlearning.WebHome@intermediate-devops-perspectives-peerreview-1.png]] 18 18 19 -Key benefits of peer reviews 21 +Key benefits of peer reviews: 20 20 21 21 * Improved quality of integrations 22 22 * Higher consistency ... ... @@ -25,11 +25,13 @@ 25 25 * Architecture challenge and verification 26 26 * Find alternative solutions 27 27 30 +=== 3.1 Who and when === 28 28 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. 29 29 30 - ==3. Runningpeer 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. 31 31 32 -=== 3. 1Considerations for reviewee ===36 +=== 3.2 Considerations for reviewee === 33 33 34 34 Here are some things to keep in mind when presenting the work to peer review. 35 35 ... ... @@ -36,79 +36,71 @@ 36 36 * Quickly explain the story / task / background 37 37 * Quickly show the working result if applicable / practical 38 38 * Talk through the solution while showing the models / code 39 - * Just trying to explain your work to someone else will help spot mistakes 40 - * 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. 41 41 * Always do a peer review, no exceptions. Making assumptions about the usefulness beforehand defeats the whole purpose. 42 42 43 -=== 3. 2Considerations for reviewer ===47 +=== 3.3 Considerations for reviewer === 44 44 45 45 Here are some things to keep in mind when peer reviewing the work . 46 46 47 47 * Ask questions 48 - * How does this work? 49 - * Why did you decide to …? 50 - * Did you think about …? 52 + ** How does this work? 53 + ** Why did you decide to …? 54 + ** Did you think about …? 51 51 * Spot (incorrect) assumptions 52 52 * Check application of best practices – see next slide 53 - * Modelling / coding patterns 54 - * Naming conventions 55 - * Errors / warnings 57 + ** Modelling / coding patterns 58 + ** Naming conventions 59 + ** Errors / warnings 56 56 * Notice non-standard / unusual / abnormal things 57 - * 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. 58 58 59 59 === 3.3 Peer review items per ILM Phase === 60 60 61 61 * Capture 62 - * 100% filled 63 - * Connection method clear 64 - * Authentication method clear 65 - * Definitions loaded 66 - * 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 67 67 * Design 68 - * Check solution architecture validity 69 - * Design 100% filled and clear 70 - * CDM Root entity mapped 71 - * Set as mapped – avoid line mapping 72 - * Use annotation where possible 73 - * 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 74 74 * Create 75 - * Validate routing 76 - * Generic error response flows 77 - * Check naming conventions flows, properties and XSD 78 - * 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 79 79 * Deploy 80 - * Check properties 81 - * Avoid too many different flow versions – max. 2 82 - * 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 83 83 * Manage 84 - * All alerts mapped to Customer Support 85 - * All messages can be explained 86 - * Avoid code mappings 87 - * Enable default alerts 88 + ** All alerts mapped to Customer Support 89 + ** All messages can be explained 90 + ** Avoid code mappings 91 + ** Enable default alerts 88 88 * Architecture 89 - * Deploy connector close to the source/target system 90 - * Ensure ACCP and PROD are exact copies 91 - * Cloud over on-premise 92 - * 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 93 93 98 +== 4. Key takeaways == 94 94 95 - 96 -== 4. Assignment == 97 - 98 -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. 99 - 100 -== 5. Key takeaways == 101 - 102 102 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. 103 103 102 +== 5. Suggested Additional Readings == 104 104 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: 105 105 106 -== 6. Suggested Additional Readings == 107 - 108 -You will find plenty background items available on the Internet. 109 - 110 -== 7. Silent demonstration video == 111 - 112 -As this is a more theoretical microlearning we have no video for this. 113 - 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"]] 114 114 )))((({{toc/}}))){{/container}}{{/container}}