Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Change Management and the Multi-Tiered Development Process

CM Multi-Tier dev
by

Jon Watson

on 21 October 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Change Management and the Multi-Tiered Development Process

Development
Production
Small Org Process
Change Management
Alpha
Designed for Multiple users
Avoids project collisions
Developer workspace separation
Enforces release policies
Configuration is integrated with Source Control
Provides framework for developers to understand the release as a whole, not just small parts of the application
Beta
First stable work space for testers
Provides developers with a "practice run" of the release process so they can compile release notes for the CM
Release is done to a tag
Multiple releases from alpha to beta before promoting up to the next step
Promotion to beta is owned by a single developer's liaison to the Change Manager
Stage
Final chance to test before going to production
Full automated regression tests are run
Stake-holders "sign-off" on features and functionality that is going to production
Any single release to stage invalidates all previous testing during that release cycle (for a given release)
Promotion to stage is owned by Change Management
Production
Protected Environment.
Limited Access.
No one can touch, except Change Management.
Automated Full Regression Tests that were run in stage are also run in production.
Stake holders test and formally accept the production release.
Project Planning
Requested -> back-log
Managers, Stake Holders:
clearly define business requirements
prioritize
not quantify
Developers
~=Consultants
Discuss Possibilities & Costs
!= Decision Makers
Time Planning >= Time Developing
Avoid Waterfall approach, but plan appropriately
Goal = Clealy documented business requirements
Wireframs
Mock-ups
Technical Design Document
Architecture Diagrams
Test Cases
Beta Testing
Release candidate promoted to beta.
Stake holders test and provide feedback (ideally through some sort of ticket system) to developers
Can this release be promoted to production?
Show stoppers?
Bug fixes?
Developers:
Continue development of the next scrum cycle.
Also fix bugs in the beta release tag.
Merge beta bug fixes back to trunk.
Stage Testing
Final chance to test before going to production
Full automated regression tests are run
Stake-holders "sign-off" on features and functionality that is going to production
Any single release to stage invalidates all previous testing during that release cycle
Promotion to stage is owned by Change Management
Production
Protected Environment.
Limited Access.
No one can touch, except Change Management.
Automated Full Regression Tests that were run in stage are also run in production.
Stake holders test and formally accept the production release.
Promotion
General Work-Flow
Development Begins
If project is too big for cycle = not well enough understood. Needs to be broken down further.
Project Managers are notified of what is going into this release, and what is not going into this release.
Requirements stable during sprint.
Development Release Manager is designated to develop the release process.
Goal = stable release candidate
Develop Release Process
Installation Instructions (.txt) or scripted release included in source control
Database changes scripted and included also
Roll-back plan thought-out and accounted for
Packaged, Scripted Release
First practice release for CM
Test the release process
No risk to production
If something fails, CM works it out with developers
One-step release
Follow installation instructions
Update work area (svn switch)
Run database scripts
Install Software
Configure Apache
Restart Apache / Other Services
Release With Confidence
Release process has been tested
Stake holders have reviewed and signed-off
Full regression testing has passed
Expectations are set
Expectatios have a basis to be met
Ideal Release
CM is performing the release
CM is familiar with the release and has already performed the release before in stage
CM knows common problems that happened in previous failed releases
Collective Code Ownership
Anyone can change anything.
Intentional focus on avoiding knowledge silos.
Intentional Cross-Training.
Increase the truck number.
#
How many people can get hit
by a truck before your organization
suffers significant harm?
RPM / Debian package
Pros
Promotes CM Understanding
Less Developer Learning Curve
Less work for Developer
Cons
More work for CM
Less certain outcome
Little focus on roll-back
Pros
More Certain Outcome
Forces developer to think of roll-back
Less work for CM
Cons
More work for Developer
Does not promote CM Understanding
More Developer learning curve (how to write a .deb package?)
Development Streams
Trunk
Branch
Major Project Development
Global Product Vision
Stream
Tag
Feature Development
Production Release
Bug Fixes
Tag
Production Release
Bug Fixes
Future
Past
Merge
Merge
Merge
Merge
Stable Code Base
Work Area Management
/home/jwatson/Source/

project.trunk
project.branchname
project.2012.08.16.release
project -> ./project.branchname
Virtual Host Management
/project/conf/apache/alpha
jwatson.project.fh.org.conf
dmartin.project.fh.org.conf
sheringer.project.fh.org.conf
project_variables.conf
apache.conf (includes all)
/project/conf/apache/beta
beta-project.fh.org.conf

/project/conf/apache/stage
stage-project.fh.org.conf

/project/conf/apache/prod
project-fh.org.conf
Who writes docs?
Business Analysis?
Project Managers?
System Architects?
Developers?
What level of documentation is appropriate?
Wire Frames
Mock-ups
Business Requirements Docs (BRD)
Technical Design Documents (TDD)
Test Cases
Use-Case Scenarios
Who is Change Management?
Are we hiring someone?
Will this be Tony?
Is this a new group?
What is the scope of responsibility?
How can we avoid the truck number problem in this area too?
Testing Process
Cruise Control automated build/deployment?
PHP Unit Test (may be kicked off by CruiseControl)?
Testing Team with use-cases?
Combination of all?
Team Discussion...
Trunk
Stream 1
Tag
Production Release
Bug Fixes
Merge
Stream 2
*.project.fh.org -> alpha
DNS Considerations
beta-project.fh.org -> beta
stage-project.fh.org -> stage
project-fh.org -> production
SSL Considerations
Dedicated IP Addresses for
alpha-project.fh.org
beta-project.fh.org
stage-project.fh.org
project.fh.org
What is our process?
Agile / Spiral vs. Waterfall?
Bob
Larry
Merge Could Be:
A single file
A set of specific files
All work from stream 1
?
The Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions
over processes and tools
Working software
over comprehensive documentation
Customer collaboration
over contract negotiation
Responding to change
over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Manifesto for Realistic Software Development
After participating in and observing many software development projects in recent years, we have reached the sad conclusion that there will never be better ways of developing software on this planet. While the principles of the Manifesto for Agile Software Development may look appealing for inexperienced developers, serious professionals know that the real world is not similar to the "Little House on the Prairie"

Our experience has taught us to value:
Processes and tools
over individuals and interactions
Comprehensive documentation
over quality software
Contract negotiation
over customer collaboration
Following THE initial plan
over responding to change
That is, while you could be very lucky to work in a project with the items on the right (intelligent developers and customers working together, what are these agilists smoking?!?), you will never be fired for applying items on the left (or if you are, this is very unlucky or because you didn't choose IBM).
aka... The Waterfall Manifesto
Scrum vs. Kanban?
Tag
Production Release
Bug Fixes
Merge
Merge Process
Assumes awareness of projects between developers
Resolve source conflicts
Communication with other developers
Did my code break something?
Did their code break my code?
Conflicts are resolved in a work area before being committed
Unit Test
Automated Regression Test
Full transcript