Loading ...
Sorry, an error occurred while loading the content.

Re: What are you doing for environments & source trees?

Expand Messages
  • woynam
    Yes. These are typically referred to as Stabilization Sprints. During these iterations we perform our final rollout, performance, and formal QA testing.
    Message 1 of 7 , Mar 30, 2009
    • 0 Attachment
      Yes. These are typically referred to as "Stabilization Sprints."

      During these iterations we perform our final rollout, performance, and formal QA testing. While we test continuously during the development iterations, there are some tests that are difficult if not impossible to do in our development environments.

      For example, our development environments are not clustered, so we can't do failover testing. The hardware is no where near the same class and quantity as our production servers, so we can't do performance and load testing.

      Lastly, since there can be many projects in a single release, as well as miscellaneous bug fixes and enhancements, the stabilization Sprint starts with the merge of all project code bases that will be part of the release.

      Mark

      --- In scrumdevelopment@yahoogroups.com, Pablo Emanuel <pablo.emanuel@...> wrote:
      >
      > A side question here:
      >
      > <<- Releasing team usually had an iteration to get the release in order
      > include perf-proving tests, merging etc.>>
      >
      > In RUP, this is called a transition iteration. I wonder how common it is in
      > (non-RUP) agile teams. Do you guys usually have sprints like that prior to a
      > release?
      >
      > Regards,
      > Pablo Emanuel
      >
      > 2009/3/27 Scot Mcphee <scot.mcphee@...>
      >
      > >
      > > On 27/03/2009, at 00:06 , Greg Harisiades wrote:
      > >
      > > > I work for a large organization with the following characteristics:
      > > >
      > > > • At least 6 releases "in flight" at any one time.
      > > > • Each release contains several projects
      > > > • We are organized into teams based on application are
      > > > • Each project, from beginning to end, lasts 5+ months
      > > > • We are waterfalling it
      > > > My new job is to develop a plan to bring the organization from
      > > > waterfall to agile (I'm a certified ScrumMaster).
      > > >
      > > > I have read all the papers and Ken Scwaber's book, but the one area
      > > > where I haven't found anything is how companies organize their
      > > > development and testing environments. My main concern is how we can
      > > > accommodate the several releases and several projects within each
      > > > release.
      > > >
      > > > • Does each project team have its own branch?
      > >
      > >
      > > In the past when I was in an organisation using XP to deliver 4
      > > development streams independently we adopted the following
      > > characteristics.
      > >
      > > - Teams were NOT organised in application area. We have 4 independent
      > > release streams and 4 teams - one for each. Each team worked anywhere
      > > in the code base that was necessary to achieve their stories.
      > >
      > > - Branching and merging were done, with Subversion, as follows:
      > > - Production release was done onto the TRUNK ("golden trunk"
      > > strategy).
      > > - Each team had a branch for their particular projects
      > > - Trunk was merged to the individual branches as soon as it changed,
      > > i.e. on release
      > > - When a team had completed their stories and was ready to release,
      > > team merged to trunk, and then trunk to each other branch in
      > > consultation with the other teams (sometimes, a team would merge
      > > changes from trunk into their own branch ('pull'), sometimes the
      > > releasing team would merge their changes to the branches ('push'),
      > > although 'pull' was preferred. this was resolved using discussion
      > > among the teams depending what the changes were and how they might
      > > impact.)
      > > - I wanted to move to an additional branch-per-story off each team's
      > > project branch because this would aid selective merging (every now and
      > > again the business would want team 1's project released with one or
      > > two stories from team 2's project). however, although it received some
      > > support it wasn't widely adopted.
      > >
      > > - Absolutely every team had their own CI environments (often two or
      > > more), testing rig, etc - supplied from both ad-hoc boxes (e.g. spare
      > > dev boxes) and virtualisation. A final-phase performance-proving
      > > environment identical to production setup was supplied using the
      > > disaster recovery site.
      > >
      > > - Releasing team usually had an iteration to get the release in order
      > > include perf-proving tests, merging etc.
      > >
      > >
      > > regs
      > > scot.
      > >
      > >
      > > --
      > > scot.mcphee@...
      > > http://crazymcphee.net/
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > > ------------------------------------
      > >
      > > To Post a message, send it to: scrumdevelopment@...
      > > To Unsubscribe, send a blank message to:
      > > scrumdevelopment-unsubscribe@...! Groups Links
      > >
      > >
      > >
      > >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.