1 FUG2016Copyright © Serena Software 2016

WE OWN IT!Dimensions CM:

Agile Software Engineering Practices

Don Irvine

VP ALM Products

2 FUG2016

Agenda

Why modernize your practices?

Managing code change

Feature based development

Reviewing changes

Embrace CI & DevOps

3 FUG2016

Why modernize your practices?

4 FUG2016

Why modernize?

• Makes your development team comfortable

• If a task or process is cumbersome developers will find a way around it

• New hires more familiar with modern practices

• Will improve your efficiency

• Iterate on development work faster

• Reduce the pain of merge activities

• Will improve your quality

• Catch defects earlier

• Catch deployment issues before production

• Aligned with direction of Serena products

5 FUG2016

Process review

• Opportunity to review your processes

• Existing implementation may be many years old

• Dimensions CM has changed over the years

• Industry best practices have evolved (e.g. agile/iterative development)

• Listen to the users

• What don’t they like about existing development practices

• What gets in their way?

• What do they like about current processes?

• Do some root cause analysis

• What is causing issues you see today?

• Failed compilation, failed deployment, failed testing

• Not meeting requirements/standards

• Serena Professional Services can help

6 FUG2016

Managing code change

7 FUG2016

Check-Out/Check-In - Projects

Check-Out Check-In

Code/build/test

Project

Work Area

8 FUG2016

Problems with Check-Out/Check-In

• When parallel check-out is not allowed

• Development becomes serial

• Other users cannot change the file until the lock is released

• When parallel check-out is allowed

• Can lead to multiple tip revisions

• Which version is the latest?

• When do you merge them?

• Revisions in the project may not have been built/tested

• An extra step for the developers

• They just want to edit the code, not check-out first

• Industry has evolved

• This model was the norm 10-15 years ago

9 FUG2016

Copy/Modify/Merge - Streams

Update

Code/build/test

Deliver

Conflicts? YesNo

Stream Work Area

10 FUG2016

Copy/Modify/Merge - Benefits

• Encourages frequent update

• Finds integration issues sooner

• Encourages local build and test before delivery

• Not able to make direct modifications to the stream

• Enables parallel development

• Improves the speed of development

• No need to wait for other users to check-in first

• Locking is still possible for files in a stream

• For files where parallel development is not possible

• No big merge exercise at end of development

• Smaller incremental merges as each developer delivers

11 FUG2016

Copy/Modify/Merge – Benefits…

• Delivery of multiple files in a single changeset

• Logical unit of change

• Instead of individual file/folder operations

• Gives visibility to the change as a whole

• Single change to be built/reviewed/merged

• Results in simple item pedigree

• Single line of descent in a stream

• Easier to identify where a change was introduced

12 FUG2016

When to use Check-Out/Check-In

• Some situations may mean you need to use check-out/check-in

• When files cannot be merged

• Parallel check-out disallowed, enforces development in serial

• When you need to see which files are being changed

• Checking-out gives some visibility to who is working on what

• But you always know which developers are working on which requests

• When user making the changes cannot perform the merge

• Check-Out/Check-In with parallel check-out

• Create multiple tip revisions

• Other users can perform merge later

• When using Dimensions z/OS

• Our recommendation is to use Streams

13 FUG2016

Feature based development

14 FUG2016

Isolating units of work

• Why separate out pieces of work?

• Agile approach (only include in the release what work is complete)

• Will not be affected by defects/changes introduced by other work

• More stable/release-ready software

• Works best if the features are truly separate

• Code does not overlap with that of other features

• Separate software components

• Something with a well defined interface

Mainline

Feature 1

Feature 2

15 FUG2016

How to isolate units of work?

• Using revised baselines

• Use requests to pick and choose which changes go into your baseline

• Build and test that baseline

• But what if changes overlap?

• Using design parts

• Each feature has its own part

• Baseline each part independently

• Merge baselines together to form a release

• Only works if features are separate components

• Using separate streams

• Features developed in separate streams

• Clear separation from other work

• Easy for developers to understand

16 FUG2016

Using separate streams

• Each development project has a mainline

• Maybe one of these for each parallel release of software

• Maybe your releases also feed up to a single mainline

• Separate stream for features or teams

• Branch off the release stream when development starts

Mainline

Release2

Release1

FeatureX

17 FUG2016

How and when to rebase?

• When to “rebase” or update your Streams from mainline?• When there is a change you are dependent upon

• You may not need to do this at all

• But the longer you leave this the harder your merge will be

Mainline

HotFix

NextRelease

FeatureX

Hot Fix has

completed so the

team decide to

merge it in.

18 FUG2016

How and when to merge?

• How and when to merge

• When testing is complete

• When another team needs your feature

• When Serena Pulse tells you the health and quality are good

• When a release is complete

Mainline

HotFix

NextRelease

FeatureX

Release has

shipped, so can

be merged to

mainline.

19 FUG2016

Some things to consider

• Each stream may need its own infrastructure

• Separate builds for each feature

• Separate deployment areas might be needed

• Testing tools/infrastructure

• Consider how this effects your requests

• Do you have changes that cross multiple features/teams?

• Create high level requests

• Break them down into the changes needed in each stream

• Applies to incoming defects as well as development change requests

• Each Stream may be a mini-development-project

• With stage gates and deliverables and a timescale for merge

• Some naming convention for your streams

• e.g. <RELEASE>_<FEATURE>

20 FUG2016

What is Peer Review?

21 FUG2016

What is Peer Review?

“Examination of a work product by the author and one or more colleagues”

• Design, Documentation, Source, Configuration Files, Scripts, Models etc

• Complete “change” is examined as a whole

• Comparing previous version of each file with the new version

• Also look at new files, removed files and refactoring

“Q: What's the cheapest way to get rid of bugs?”

“A: Don't put them in in the first place”

• Goal of Peer Review is to:• Find defects/issues in the deliverables

• Improve the quality of the deliverables

• Verify what was implemented meets expectations/requirements

22 FUG2016

The history of Peer Review

• The Fagan process for software inspection (1976)

• Michael Fagan documented the process of formal software inspection [1]

• Defines formal review in terms of roles, inputs, deliverables, meetings

• Peer Review in an agile environment (2001)

• Often referred to as “lightweight” peer review

• Continuous Review (every delivery is reviewed)

• Pair Programming and XP

• Serena Pulse delivers integrated Peer Review with Dimensions CM

(2014)

• Configurable, controlled & audited, collaborative Peer Review

• Bringing all the information together for the reviewers to do their job

[1] M.E., Fagan (1976). "Design and Code inspections to reduce errors in program development". IBM Systems Journal

23 FUG2016

Types of Peer Review

• Pre-delivery (“over the shoulder” review)• Before the developer checks-in

• Works best for small local teams

• Good opportunity to ask the author questions

• But no audit trail or accountability

• Not practical if multiple people need to do the review

• Continuous Review (on every delivery)• Automated review process, after the developer checks-in

• Captures audit trail of the review

• Gives reviewers more time to perform the review

• Can work well with teams of reviewers

• Formal Code Inspection (on entire features/components)• Scheduled review meeting with stakeholders

• Often involves other artefacts (requirements, test plans, training material)

• Works well for highly regulated industries

• Can be costly to perform

24 FUG2016

Why Perform Peer Review?

25 FUG2016

Cost of finding and fixing issues

• Cheaper to find and fix defects during development

26 FUG2016

Improving Software Quality

"If you know someone is going to look at your code afterwards then you are far more likely to write it better in the first place.“

• Industry average is 5 bugs for every 100 lines of modified code

• Peer Review can catch 65% of all defects [2]

• "given enough eyeballs, all bugs are shallow“ – Linus Torvalds

• Validates the logic/algorithm of the code

• Catches edge cases

[2] Capers Jones (June 2008). “Measuring Defect Potentials and Defect Removal Efficiency”. Crosstalk Magazine

27 FUG2016

Improving Software Security & Maintainability

• Improving Software Security

• Check for common security issues

• Ensure no backdoors or debug code is left in

• Check that standard encryption and authentication are used

• Improving Software Maintainability

• Compliance to company coding standards

• Identify overly complex logic

• Ensure use of common software patterns

• Reviewer needs to understand the authors code

• Improving Software Compliance

• 21 CFR Part 11, SOX, ISO26262 etc

• Part of your audit trail

• Does the delivery include 3rd party components?

• Is software appropriately licensed?

28 FUG2016

Improving Developers Skills

• Developers learn from one-another during Peer Review

• Peer Review improves your “bus factor”

• More developers familiar with the changes being delivered

• Junior Developer reviewing Senior Developers code

• Learns tips and tricks from the author

• Senior Developer reviewing Junior Developers code

• Can get a feeling for how the junior developer is progressing

• Builds a sense of team spirit

• “we are in it together”

29 FUG2016

How to Perform Peer Review?

30 FUG2016

Peer Review practices

• Review and Inspect all delivered files side by side with previous versions

• If possible perform a pre-delivery review

• Have the author walk through the code change

• Encourage reviewers to ask questions

• How did you test it?

• Did you consider any alternative approaches?

• Did you consider edge cases (errors, empty values/lists, large amounts of data etc)?

• Ask about performance and scalability?

• Ask about security implications of the change if any?

• Author will often spot their own mistakes

• Simply during explaining the logic to the reviewer(s)

• Reviewer should be accountable for the change

• If problems are found after review, ask why it was missed

31 FUG2016

Peer Review Practices…

• Promote constructive criticism

• If a reviewer spots a problem have them suggest a solution

• Don’t make reviewing a “blame game”

• Encourage “good” behaviour, not punish “bad” behaviour

• Avoid nit-picking, focus on the high value comments/feedback

• Good Review takes time

• 150 lines of modified code an hour (~2 lines of modified code a minute)

• Don't stop reviewing just because release is imminent

• Drop a feature rather than risk a defect

• Monitor and tune your review process

• Look at metrics/reports

• Are changes being stuck in the review state for too long?

• Are reviews often failing

• Is it one person who is always failing or always approving?

32 FUG2016

Peer Review Checklist

• Checklist of what needs to be done during review

• Could be reminders to the reviewer as to what to check

• Security, Scalability, Performance

• Complexity, Maintainability

• Compliance to standards/guidelines

• Could be very specific to your application/industry

• Different items might be checked-off by different people

• You may need to keep audit trail

• Who check-off what and when

33 FUG2016

It is not just the code

• All artefacts relating to the change should be reviewed

• Requirements, Design, Models/Diagrams, Scripts, Configuration files

• In addition to the source files themselves

• Information from other tools helps reviewer make decision

• Compiler warnings

• Unit test results

• Static Analysis findings

• Style checker results

• Security analysis tool output

• Tools can help automate large reviews

34 FUG2016

The review team

• Many ways to choose reviewers and sign off the review

• Your choice will depend on

• Size of your team

• Regulatory compliance needs

• Complexity of software etc

• Should reviewers be selected by the author?

• In small agile teams this is probably true

• Can reviewer be selected automatically based on knowledge?

• Change to missile detonation software goes to the expert in that area

• One reviewer or more than one?

• Formal highly regulated reviews may have a “lead” reviewer and a team

• Do all reviewers have to agree?

• Does someone have a “veto” over the status of the review?

35 FUG2016

Use Serena Pulse

• Integrated Peer Review process with Dimensions CM

• Automated post-delivery review

• Side by side comparison of artefacts modified

• Including information from other development tools• Build tools, Static Analysis tools, Style checking tools etc

• Configurable

• Supports lightweight reviews to large formal team based reviews

• Integrated with your CM Request lifecycle & roles

• Collaborative

• Encourages conversation between reviewers and authors

• Modern look and feel – a tool developers will want to use

• Controlled

• Configurable review checklist with full audit trail

• Metrics & Reports to see trends in your review process

36 FUG2016

Peer Review Summary

Peer Review brings many benefits

improved quality, maintainability, security

Consider using Serena Pulse

Configurable, Collaborative, Controlled

Review your current Peer Review process

Does it meet your regulatory needs?

37 FUG2016

CI & DevOps

38 FUG2016

Continuous Integration

• Build and test every change as it is delivered

• Encourage frequent delivery of work in progress

• Finds issues/problems early

• Issues integrating code delivered with other changes

• Gives confidence you’re building on a solid foundation

• Increases visibility of the health of development

• Use Serena Pulse to drive your CI build

• Pulse can kick off build tool on each delivery

• Shows information from build and unit test results

39 FUG2016

Why do we need DevOps?

• Failed deployments are costly to fix

• Deploy worked in dev but failed in production

• The wrong versions got deployed

• Development don’t know what is running production

• Business typically wants to deliver releases more frequently

• Without sacrificing quality or release content

• Development teams, QA and IT operations typically working in silos

• One team hands-off to the other

• The teams use different processes/environments

• There is lack of communication and collaboration between the teams

40 FUG2016

The DevOps solution

• Automate your path to production

• Consistent/repeatable process for deployment

• Faster deployment execution

• Make environments in Dev/Test similar to production

• Same versions of systems, software, components

• Automate provisioning of environments

• Make deployment process in Dev/Test similar to production

• Automate your deployment processes

• Ideally using Serena Deployment Automation

• Raise visibility of release contents/planning/scheduling

• Ideally using Serena Release Control

41 FUG201641

Thank You