Peer reviews - eMagiz

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.

13

14

[[image:Main.Images.Microlearning.WebHome@intermediate-devops-perspectives-peerreview-1.png]]

15

16

Key benefits of peer reviews

17

18

* Improved quality of integrations

19

* Higher consistency

20

* Knowledge sharing

21

* Keeping standards for optimal maintenance

22

* Architecture challenge and verification

23

* Find alternative solutions

24

25

== 3. Running peer reviews in eMagiz ==

26

27

=== 3.1 Considerations for reviewee ===

28

29

Here are some things to keep in mind when presenting the work to peer review.

30

31

* Quickly explain the story / task / background

32

* Quickly show the working result if applicable / practical

33

* Talk through the solution while showing the models / code

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.

36

* Always do a peer review, no exceptions. Making assumptions about the usefulness beforehand defeats the whole purpose.

37

38

=== 3.2 Considerations for reviewer ===

39

40

Here are some things to keep in mind when peer reviewing the work .

41

42

* Ask questions

43

** How does this work?

44

** Why did you decide to …?

45

** Did you think about …?

46

* Spot (incorrect) assumptions

47

* Check application of best practices – see next slide

48

** Modelling / coding patterns

49

** Naming conventions

50

** Errors / warnings

51

* Notice non-standard / unusual / abnormal things

52

** Make sure this is documented, mainly for future changes. Annotations are very useful here.

53

54

=== 3.3 Peer review items per ILM Phase ===

* Capture

** 100% filled

** Connection method clear

59

** Authentication method clear

60

** Definitions loaded

61

** Sizing impact understood and valid

62

* Design

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

69

* Create

70

** Validate routing

71

** Generic error response flows

72

** Check naming conventions flows, properties and XSD

73

** Split messages in on-ramp – not later

74

* Deploy

75

** Check properties

76

** Avoid too many different flow versions – max. 2

77

** Remove test packages that are deployed

78

* Manage

79

** All alerts mapped to Customer Support

80

** All messages can be explained

81

** Avoid code mappings

82

** Enable default alerts

83

* Architecture

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

== 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.

92

93

== 5. Key takeaways ==

94

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

97

== 6. Suggested Additional Readings ==

98

99

You will find plenty background items available on the Internet.