1Copyright © Serena Software 2015

Dimensions CMVirtual User Group

Hosted by Ashley Owen

Director of Product Marketing

May 27th, 2015

2

Introductions

Don IrvineSr. Director of DevelopmentSerena Software

Peter RaymondPrincipal Product ArchitectSerena Software

3

Welcome to the quarterly Dimensions CM VUG

News and Announcements

Engaging the CM SIG

Modernize your CM process & practices

Answers for Your Questions

4

Introducing Serena Central

http://www.serenacentral.com

5

Technical Blog Content for Dimensions CM

http://www.serenacentral.com

6

Register and Vote on Product Ideas

http://www.serenacentral.com

7

Discuss your Questions/Problems with the Serena Community

http://www.serenacentral.com

8

Join the Dimensions CM VUG Group Online

9

Engaging the CM SIG

• Announcing the “CM User Experience Special Interest Group”

• Evaluating the future direction for the Desktop and Web Clients.

• Sign-up at http://www.serenacentral.com/cmuxsig

10Copyright © Serena Software 2015

Dimensions CM Spring VUGModernizing your CM practices

Peter Raymond

May 27, 2015

11

Agenda

Why modernize your practices?

Managing code change

Feature based development

Embrace CI & DevOps

12

Why modernize your practices?

13

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

14

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

15

Managing code change

16

Check-Out/Check-In - Projects

Check-Out Check-In

Code/build/test

Project

Work Area

17

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

18

Copy/Modify/Merge - Streams

Update

Code/build/test

Deliver

Conflicts?YesNo

Stream Work Area

19

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

20

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

21

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

22

Feature based development

23

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

24

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

25

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

26

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.

27

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.

28

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>

29

Guidance on Item Lifecycle

• What not to use Item Lifecycle states for• Review workflow

• This should be on the change request not files• Path to production

• Stages were designed for this

• When to use Item Lifecycle• For managing the life of the file

• Retiring the file by moving it to a final lifecycle state• Indication of Draft/In-Use

• Using “overwrite at initial revision”• Disallowing close of request until item is no longer draft

30

CI & DevOps

31

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

32

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

33

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

34

Summary

Improve your efficiency & quality

Consider using Streams

Develop features separately

Review complete changes

Embrace CI & DevOps

35

Thank you

www.serena.com

36

Answers for your questions

37

Thank you

www.serena.com