Introducing
Your new presentation assistant.
Refine, enhance, and tailor your content, source relevant images, and edit visuals quicker than ever before.
Trending searches
Change Management and the Multi-Tiered Development Process
Change Management
Small Org Process
General Work-Flow
Promotion
Production
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?
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.
Release With Confidence
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
- 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
- Anyone can change anything.
- Intentional focus on avoiding knowledge silos.
- Intentional Cross-Training.
- Increase the truck number.
Stage Testing
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
- Promotion to stage is owned by Change Management
- 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
#
Packaged, Scripted Release
One-step release
- RPM / Debian package
- Follow installation instructions
- Update work area (svn switch)
- Run database scripts
- Install Software
- Configure Apache
- Restart Apache / Other Services
- 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?)
- First practice release for CM
- Test the release process
- No risk to production
- If something fails, CM works it out with developers
How many people can get hit
by a truck before your organization
suffers significant harm?
Beta Testing
Testing Process
Beta
- Cruise Control automated build/deployment?
- PHP Unit Test (may be kicked off by CruiseControl)?
- Testing Team with use-cases?
- Combination of all?
- Team Discussion...
- 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.
- 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
Development
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
What is our process?
Manifesto for Realistic Software Development
The Agile Manifesto
aka... The Waterfall 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:
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:
- Agile / Spiral vs. Waterfall?
- 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
- 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 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).
That is, while there is value in the items on
the right, we value the items on the left more.
- Scrum vs. Kanban?
Development Begins
Alpha
- 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
- 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
Project Planning
What level of documentation is appropriate?
Who writes docs?
Business Analysis?
Project Managers?
System Architects?
Developers?
Wire Frames
Mock-ups
Business Requirements Docs (BRD)
Technical Design Documents (TDD)
Test Cases
Use-Case Scenarios
- 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
Development Streams
Virtual Host Management
Work Area 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
/home/jwatson/Source/
project.trunk
project.branchname
project.2012.08.16.release
project -> ./project.branchname
DNS Considerations
Major Project Development
SSL Considerations
*.project.fh.org -> alpha
beta-project.fh.org -> beta
stage-project.fh.org -> stage
project-fh.org -> production
Dedicated IP Addresses for
- alpha-project.fh.org
- beta-project.fh.org
- stage-project.fh.org
- project.fh.org
Future
Past
Bob
Merge Could Be:
- A single file
- A set of specific files
- All work from stream 1
Merge
?
Stream 1
Stream 2
Larry
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