Changes for page Peer reviews

Last modified by Danniar Firdausy on 2024/09/18 14:42

From 12.1 to 13.1 From 21.1 to 22.1

From version 13.1

edited by eMagiz
on 2022/05/17 09:10

Change comment: There is no comment for this version

To version 21.1

edited by Erik Bakker
on 2022/08/30 08:34

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (5 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 @@
--XWiki.marijn
++XWiki.ebakker

Default language

...	...	@@ -1,0 +1,1 @@
	1	+en

Content

@@ -1,20 +1,8 @@
--{{html wiki="true"}}
--<div class="ez-academy">
--	<div class="ez-academy_body">
--
--<div class="doc">
--
--
--
--= Running peer reviews inside eMagiz DevOps team =
--
++{{container}}{{container layoutStyle="columns"}}(((
  In this microlearning, we will take a look at peer reviews for eMagiz.
--Should you have any questions, please contact academy@emagiz.com.
++Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
--* Last update: April 22nd, 2021
--* Required reading time: 8 minutes
--
  == 1. Prerequisites ==
  * Basic knowledge of the eMagiz platform
@@ -21,9 +21,9 @@
  == 2. Key concepts ==
--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.
++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.
--<p align="center">[[image:intermediate-devops-perspectives-peerreview-1.png||]]</p>
++[[image:Main.Images.Microlearning.WebHome@intermediate-devops-perspectives-peerreview-1.png]]
  Key benefits of peer reviews
@@ -34,74 +34,76 @@
  * Architecture challenge and verification
  * Find alternative solutions
++== 3. Running peer reviews in eMagiz ==
++=== 3.1 Who and when ===
--== 3. Running peer reviews in eMagiz ==
++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.
--=== 3.1 Considerations for reviewee ===
++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.
++=== 3.2 Considerations for reviewee ===
++
  Here are some things to keep in mind when presenting the work to peer review.
  * Quickly explain the story / task / background
  * Quickly show the working result if applicable / practical
  * Talk through the solution while showing the models / code
--  * Just trying to explain your work to someone else will help spot mistakes
--  * 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.
++  ** Just trying to explain your work to someone else will help spot mistakes
++  ** 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.
  * Always do a peer review, no exceptions. Making assumptions about the usefulness beforehand defeats the whole purpose.
--=== 3.2 Considerations for reviewer ===
++=== 3.3 Considerations for reviewer ===
  Here are some things to keep in mind when peer reviewing the work .
  * Ask questions
--  * How does this work?
--  * Why did you decide to …?
--  * Did you think about …?
++  ** How does this work?
++  ** Why did you decide to …?
++  ** Did you think about …?
  * Spot (incorrect) assumptions
  * Check application of best practices – see next slide
--  * Modelling / coding patterns
--  * Naming conventions
--  * Errors / warnings
++  ** Modelling / coding patterns
++  ** Naming conventions
++  ** Errors / warnings
  * Notice non-standard / unusual / abnormal things
--  * Make sure this is documented, mainly for future changes. Annotations are very useful here.
++  ** Make sure this is documented, mainly for future changes. Annotations are very useful here.
  === 3.3 Peer review items per ILM Phase ===
  * Capture
--  * 100% filled
--  * Connection method clear
--  * Authentication method clear
--  * Definitions loaded
--  * Sizing impact understood and valid
++  ** 100% filled
++  ** Connection method clear
++  ** Authentication method clear
++  ** Definitions loaded
++  ** Sizing impact understood and valid
  * Design
--  * Check solution architecture validity
--  * Design 100% filled and clear
--  * CDM Root entity mapped
--  * Set as mapped – avoid line mapping
--  * Use annotation where possible
--  * Proper flow and system settings
++  ** Check solution architecture validity
++  ** Design 100% filled and clear
++  ** CDM Root entity mapped
++  ** Set as mapped – avoid line mapping
++  ** Use annotation where possible
++  ** Proper flow and system settings
  * Create
--  * Validate routing
--  * Generic error response flows
--  * Check naming conventions flows, properties and XSD
--  * Split messages in on-ramp – not later
++  ** Validate routing
++  ** Generic error response flows
++  ** Check naming conventions flows, properties and XSD
++  ** Split messages in on-ramp – not later
  * Deploy
--  * Check properties
--  * Avoid too many different flow versions – max. 2
--  * Remove test packages that are deployed
++  ** Check properties
++  ** Avoid too many different flow versions – max. 2
++  ** Remove test packages that are deployed
  * Manage
--  * All alerts mapped to Customer Support
--  * All messages can be explained
--  * Avoid code mappings
--  * Enable default alerts
++  ** All alerts mapped to Customer Support
++  ** All messages can be explained
++  ** Avoid code mappings
++  ** Enable default alerts
  * Architecture
--  * Deploy connector close to the source/target system
--  * Ensure ACCP and PROD are exact copies
--  * Cloud over on-premise
--  * No hard-coded variable – use properties
++  ** Deploy connector close to the source/target system
++  ** Ensure ACCP and PROD are exact copies
++  ** Cloud over on-premise
++  ** No hard-coded variable – use properties
--===== Practice =====
--
  == 4. Assignment ==
  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 @@
  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.
--
--
  == 6. Suggested Additional Readings ==
  You will find plenty background items available on the Internet.
@@ -118,11 +118,4 @@
  == 7. Silent demonstration video ==
--As this is a more theoretical microlearning we have no video for this.
--
--</div>
--
--</div>
--</div>
--
--{{/html}}
++As this is a more theoretical microlearning we have no video for this.)))((({{toc/}}))){{/container}}{{/container}}

Changes for page Peer reviews

Summary

Details

Navigation