Date post: | 28-Jul-2015 |
Category: |
Technology |
Upload: | serena-software |
View: | 66 times |
Download: | 1 times |
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
5
Technical Blog Content for Dimensions CM
http://www.serenacentral.com
7
Discuss your Questions/Problems with the Serena Community
http://www.serenacentral.com
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
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
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
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
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
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