Difference between revisions of "Viewer Integration and Release Processes"

From Second Life Wiki
Jump to: navigation, search
(Project)
m
 
(29 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 +
This page describes how Viewer development projects are organized, including the Mercurial (hg) repositories, builds, and the integration and release processes through which changes move to get from the developer (either inside or outside Linden Lab) to the Second Life Viewer.
 +
<br clear="all"/>
 
{{Project Snowstorm Nav}}
 
{{Project Snowstorm Nav}}
 
 
This page describes how Viewer development projects are organized, including the Mercurial (hg) repositories, builds, and the integration and release processes through which changes move to get from the developer (either inside or outside Linden Lab) to the Second Life Viewer.
 
 
There are three core hg repositories (each repository is in effect a branch; the processes described here do not rely on using the hg branching features within a repository):
 
* [[#Development|Development]] is the integration trunk
 
* [[#Beta|Beta]] is used to test and stabilize releases and build beta releases
 
* [[#Release|Release]] is used to build official stable releases
 
all three of these repositories are used by both Linden Lab development teams and open source developers; they are accessible at hg.secondlife.com, but only the specific Linden team responsible for each one has commit access to it.  Detailed descriptions of each, and the processes for moving changes between them, are below.
 
 
__TOC__
 
__TOC__
 
<br clear="all"/>
 
<br clear="all"/>
  
===Development===
+
== The Process ==
 
+
[[Image:Development.png|right|caption="Project and Development repositories/branches"]]
+
 
+
'''Location:''' [http://hg.secondlife.com/viewer-development http://hg.secondlife.com/viewer-development]
+
 
+
:'''This is the conceptual ‘trunk’ from which all development, both inside and outside Linden Lab, should be derived.'''
+
 
+
It is built continuously, with the resulting viewers being publicly available (from [[Downloading test builds]] and soon also from the [http://secondlife.com/support/downloads main downloads page]).
+
 
+
Any active viewer development, whether for feature development or bug fixes, pulls from this repository to a [[#Project|Project]] repository, and tracks all changes made in Development as work is done in that Project repository. Code is pulled back to this repository for integration (see [[#Development Integration Criteria|Development Integration Criteria]] below).
+
 
+
Ideally, any build from this repository is a candidate for the next Beta viewer release.
+
 
+
===Project===
+
 
+
'''Location:''' ''determined by the development team, but somewhere at hg.secondlife.com is encouraged''
+
 
+
Any development, whether a single engineer fixing a minor bug or a large team building a major feature, is done in a Project repository that pulls from Development.  Large projects will likely have individual repositories pulling from and pushing to their team Project repository; how this is managed and tracks changes made to Development is under the control of the developer(s) on the project.
+
 
+
There may be any number of other repositories created by project teams or developers either inside or outside Linden Lab; these are ''Project'' repositories.  The default channel identifier built from these repositories is "Second Life Developer" (projects that plan to make test viewers publicly available, which is encouraged, should change this to a project-specific value in those viewers).
+
  
Project repositories may be built as needed by the developers; viewers produced from Project repositories may be made available for public testing at times chosen by the development team.
+
All projects begin by forking the [[#Repo-viewer-release|<tt>viewer-release</tt>]] repository, which contains the sources used to build the current default Release viewer (with the third level version number incremented by one so that any new development versions are higher numbers).
  
When development is complete '''and the [[#Development Integration Criteria|Development Integration Criteria]] have been satisfied''' changes from a Project repository are moved back to the Development repository.  For Linden developers, this can be a push (contact the Snowstorm Team to be configured for write access), or for open source contributors a pull by the Snowstorm Team.
+
Viewer development proceeds with each project working from the same base and progressing through up to four phases:
 +
# [[#Project_Integration|Project Integration]]
 +
# [[#Beta_Test|Beta Test]] (optional)
 +
# [[#Release_Candidate|Release Candidate]]
 +
# [[#Release|Release]]
  
'''Note:''' Developers should consider the viewer-development branch to be a "clean" trunk. It's not "pristine" -- we don't gate checkins through a QA process. But developers should feel very confident BEFORE checking in to viewer-development, because other projects, both internal and external, are pulling from this repository on a daily basis. They should feel confident in doing so, as it may require work to merge the changes. Consequently, '''developers must be willing to support their checkins.'''
+
There may be any number of projects that simultaneously have either a Project, Beta, or Release Candidate viewer available (normally, any given project will have only one viewer available in one of those forms).
  
''If you are not prepared to respond to bug reports on a high-priority basis all the way through the release process, '''you should not check in'''.''
+
The Viewer Version Manager is a central service that manages notifying viewers in each channel when a newer version is available.  In Project and Beta channels, normally only one version will be available at any given time; when a new version is released by the project team, all earlier versions are invalidated so that upgrading to the newest version is mandatory.
  
==Development Integration Criteria==
+
When the project team is ready to evaluate a Release Candidate version, a cohort is defined in the Release channel.  The Viewer Version Manager randomly selects a limited number of users and offers optional upgrades to the Release Candidate version to users in the cohort. The project team and product management evaluate the experience of users in the cohort by monitoring bugs reported against that version, its crash and frame rates, and any other appropriate metrics.
  
In order to be eligible to be pulled into the Development repository, the changes in a Project repository must satisfy all of the following criteria:
+
When a Release Candidate is found to be of sufficiently high quality, it is promoted to Release status and becomes the default Release viewer.  The source from its project repository is then pulled to the <tt>viewer-release</tt> repository, the version number in that repository is incremented, and all other Release Candidate projects must merge those changes into their own projects and produce new Candidate versions to continue testing and be considered for promotion to Release.
  
# '''Functionality must have been reviewed and accepted by the Product Owner'''
+
[[Image:Viewer-Repo-Flow-8.png|Project Integration, Beta, and Release]]
#: Review is based on the requirements/user stories defined at the beginning of a sprint, and then at the end of a sprint during Acceptance Testing. For Linden development teams, these checks are the normal sprint reviews, not an additional step.  For open source developers, the Snowstorm Team will coordinate these reviews with the appropriate Linden reviewers.
+
# '''Design and code must have been reviewed by competent reviewers.'''
+
#: In this context, “competent” means appropriate subject matter experts for the code that is modified.  Linden development teams determine for themselves who the competent reviewers are; for open source contributions, the Snowstorm Team will determine the appropriate reviews.
+
#:* If there are changes to code or protocols shared between the viewer and the simulator, those changes must include unit tests that at minimum validate that the behavior before and after the change is compatible. If that is not possible due to the nature of the change, then the change must include documentation on how the interfaces are changed, and the relevant simulator developers must review and approve them (for open source contributions, the Snowstorm Team will coordinate and facilitate these reviews).
+
# '''There must be a test plan'''
+
#: The test plan must describe in detail how the modified behavior can be validated and tested. We provide a handy [[Test_Script_Template | test plan template]] to help make this trouble free.
+
# '''The Project repository must have merged in the latest changes from Development.'''
+
#: The results must be validated by building viewers for all platforms and doing at least minimal viewer testing. ''Breaking the Development build is considered bad practice and may incur [http://www.ehow.com/about_5108486_karmic-debt.html karmic debt].''
+
# '''There must be [http://secondlifegrid.net.s3.amazonaws.com/docs/SLVcontribution_agmt.pdf Contribution Agreement]s on file from all contributors to the change if the Project repository contains changes made by non-Lindens.'''
+
  
When these criteria have been met, the development team may integrate into the Development repository; see [[How To Submit A Viewer Change]].
+
The sections below detail the specifics of each phase.
  
==Beta and Release==
+
===Project Integration===
  
To create the Beta and Release Viewers, the changes on the Development repository are moved through the [[#Beta Repository|Beta]] and [[#Release|Release]] repositories following the [[#Beta and Release Process|Beta and Release Process]].  
+
# When a project is begun, the project leader or integration engineer:
 +
#*Creates a project integration repository by forking the [[#Repo-viewer-release|<tt>viewer-release</tt>]] repository.
 +
#:This is a shared repository, normally under the bitbucket.org/lindenlab account, and may be either public or private according to the needs of the project.
 +
# Individual developers on the project fork working repositories from the project integration repository, and build [[#Channel-Test|Test]] viewers for their contributions to the project prior to integration.
 +
#:Individual developer builds are <span id="Channel-Test"><tt>Second Life Test</tt></span> viewers, distinguished by the Test icon and by the dark red color of the top menu background:
 +
#::[[Image:Viewer-Icon-Developer.png]] [[Image:Viewer-Menu-Test-2.png]]
 +
# When individual work is ready, it is merged into the project integration repository (whether this merge is a push by individual developers or managed as a pull request to the project integration engineer is up to the project team).
 +
# The project integration engineer maintains a canonical [[#Channel-Project|Project]] viewer build on TeamCity that builds the integration repository for QA, and may be made available to users as appropriate.
 +
#:Project viewer builds use a distinct channel "<span id="Channel-Project"><tt>Second Life Project ''project-name''</tt></span>".  Using a Project channel causes those builds to use the Project Viewer icon and have a light blue top menu background:
 +
#::[[Image:Viewer-Icon-Project.png]] [[Image:Viewer-Menu-Project-2.png]]
  
These are continuous processes - soon (preferably within a week) after one set of changes has been moved from Beta to Release, the next Beta cycle is begun by moving the current Development changes to Beta to begin the next cycle.  The number of weekly Beta cycles, and thus the frequency of windows for moving from Development to Beta, is determined by the Beta test results.
+
The project may decide to produce a beta release in order to do higher-risk testing and/or to get wider user testing, or it may elect to skip the [[#Beta_Test|Beta Test]] phase and proceed to directly to producing a [[#Release_Candidate|Release Candidate]].
  
The targets are that we will have weekly Beta releases, with stable main viewer releases monthly (a set of Beta changes that does not produce a stable build after 3 cycles will trigger a review of whether or not the sources of the instability should be removed).
+
===Beta Test===
  
[[Image:DevelopmentToRelease.png|right|caption="Development through Beta to Release"]]
+
Whether or not a project releases a Beta viewer is up to the project.  If the project elects to release a beta, it is built for and released on the <span id="Channel-Beta"><tt>Second Life Beta ''project''</tt></span> channel.  Using a Beta channel causes the viewer to have the beta viewer icon, and a purple menu background:
 +
:[[Image:Viewer-Icon-Beta.png]] [[Image:Viewer-Menu-Beta-1.png]]
  
===Beta Repository===
+
===Release Candidate===
  
'''Location:''' [http://hg.secondlife.com/viewer-beta http://hg.secondlife.com/viewer-beta]
+
When the Viewer Release Product Owner and project lead determine that the project has met its functional goals and it is believed to be ready for general release, the Release Candidate phase begins. Release Candidate builds use the <tt>Second Life Release</tt> channel, so they use the default icon and menu color:
 +
:[[Image:Viewer-Icon-Release.png]] [[Image:Viewer-Menu-Release-1.png]]
  
: The Integration and QA team tags Development and pulls from that tag into the Beta repository (since the Beta repository will contain only change sets that are already in Development, this pull does not require any merges).
+
Release Candidates are offered as optional updates to a randomly selected small subset of users running a Release viewer.  The project team and QA monitor the bugs reported against the Release Candidate, any crash reports it uploads, and the performance statistics for it to determine whether or not it is ready to be promoted to the default Release viewer.
  
: Final QA and stabilization are done using builds from the Beta repository; builds from this repository are released weekly on the “Second Life Beta Viewer” channel.
+
There may be more than one Release Candidate at the same time.
  
: Any bug fixes on this repository are immediately pulled to the Development repository by the Snowstorm Team.
+
===Release===
  
===Release Repository===
+
When it is determined that a particular Release Candidate is ready, it is promoted to the default Release viewer.
  
'''Location:''' [http://hg.secondlife.com/viewer-release http://hg.secondlife.com/viewer-release]
+
Sources for that project are then pulled (not merged, since they are a direct descendant) to <tt>viewer-release</tt>, a <tt>''major''.''minor''.''patch''-release</tt> tag is added, the patch (third level) version number in <tt>viewer-release</tt> is incremented, and then all other projects merge out those changes.
  
: When the Snowstorm Team decides that the Beta branch is ready for release (which we expect to be after 2-4 weeks of testing and stabilization), the Integration team pulls changes from Beta into the Release repository (this is the only path into the Release repository, so this does not require any merges), where it is tagged and built to produce the viewer released on the “Second Life Release” channel.
+
== Mercurial Repositories ==
  
==Beta and Release Process==
+
;<span id="Repo-viewer-release"><tt>viewer-release</tt></span>
 +
:<tt>http://bitbucket.org/lindenlab/viewer-release</tt>
 +
:The viewer-release repo records the code used to produce all released viewers through the latest Release version currently in production. 
 +
:''Write access to the this repository is closely controlled.''
 +
:'''This is the stable repository that serves as the base for all development.'''
  
The process by which the Development code is  promoted to an official numbered Viewer release is:
+
{{Note|The <tt>viewer-beta</tt> and <tt>viewer-development</tt> repositories used in earlier versions of this process are no longer used; <tt>viewer-release</tt> is the single canonical repository.}}
  
# The Integration and QA team adds a beta tag to Development.
+
;<tt>project viewers</tt>
# The Release Manager
+
:The links to the project viewers repositories can be found on the [[Linden_Lab_Official:Viewer_Source_Repositories]]
## Pulls changes from the beta tag on Development to the Beta repository (this should not require any merge).
+
## Builds branch on Beta
+
## Creates a release document that includes test plan information and the list of all the changes included in the build (list of JIRAs, etc). Proper attention to detail during development should make this simple.
+
## Offer build to QA for testing and evaluation
+
# In QA, the integration test team:
+
## Executes the set of test plans for all of the changes included
+
## Performs a general smoke test on overall functionality
+
## Identifies overall quality and level of risk for release
+
# The Snowstorm Team evaluates quality, risk and feature set and decides whether or not to release the build as Beta. Options are:
+
#* ''Fail'': this beta candidate is rejected and the process starts over at some different tag on Development (step 1).
+
#* ''Fix First'': specific bugs / issues are identified that must be fixed before ship. These bugs are fixed in the Beta repository.
+
#** Fixes made to the Beta repository are merged to Development by the Snowstorm Team as soon as they are found to be complete.
+
#* ''Ship'': the Beta is ready as-is.
+
# Once a build is approved for ship, the Release team does its magic to get the build into the field as a Beta build on the “Second Life Beta Viewer” channel.
+
# Once a Beta is in the field, we watch for new bugs, crash rate, performance, and other data. If the Beta needs further iteration, we might iterate multiple times on the Beta branch (return to step 4).
+
# Once the Snowstorm Team decides the Beta is of sufficient quality to ship as an official viewer, the Release team:
+
## Tags the Beta branch
+
## Pulls from the tag on Beta to Release
+
## Tags and builds from the Release repository.
+
## Releases on the “Second Life Viewer” channel.
+

Latest revision as of 05:55, 16 April 2014

This page describes how Viewer development projects are organized, including the Mercurial (hg) repositories, builds, and the integration and release processes through which changes move to get from the developer (either inside or outside Linden Lab) to the Second Life Viewer.


The Process

All projects begin by forking the viewer-release repository, which contains the sources used to build the current default Release viewer (with the third level version number incremented by one so that any new development versions are higher numbers).

Viewer development proceeds with each project working from the same base and progressing through up to four phases:

  1. Project Integration
  2. Beta Test (optional)
  3. Release Candidate
  4. Release

There may be any number of projects that simultaneously have either a Project, Beta, or Release Candidate viewer available (normally, any given project will have only one viewer available in one of those forms).

The Viewer Version Manager is a central service that manages notifying viewers in each channel when a newer version is available. In Project and Beta channels, normally only one version will be available at any given time; when a new version is released by the project team, all earlier versions are invalidated so that upgrading to the newest version is mandatory.

When the project team is ready to evaluate a Release Candidate version, a cohort is defined in the Release channel. The Viewer Version Manager randomly selects a limited number of users and offers optional upgrades to the Release Candidate version to users in the cohort. The project team and product management evaluate the experience of users in the cohort by monitoring bugs reported against that version, its crash and frame rates, and any other appropriate metrics.

When a Release Candidate is found to be of sufficiently high quality, it is promoted to Release status and becomes the default Release viewer. The source from its project repository is then pulled to the viewer-release repository, the version number in that repository is incremented, and all other Release Candidate projects must merge those changes into their own projects and produce new Candidate versions to continue testing and be considered for promotion to Release.

Project Integration, Beta, and Release

The sections below detail the specifics of each phase.

Project Integration

  1. When a project is begun, the project leader or integration engineer:
    • Creates a project integration repository by forking the viewer-release repository.
    This is a shared repository, normally under the bitbucket.org/lindenlab account, and may be either public or private according to the needs of the project.
  2. Individual developers on the project fork working repositories from the project integration repository, and build Test viewers for their contributions to the project prior to integration.
    Individual developer builds are Second Life Test viewers, distinguished by the Test icon and by the dark red color of the top menu background:
    Viewer-Icon-Developer.png Viewer-Menu-Test-2.png
  3. When individual work is ready, it is merged into the project integration repository (whether this merge is a push by individual developers or managed as a pull request to the project integration engineer is up to the project team).
  4. The project integration engineer maintains a canonical Project viewer build on TeamCity that builds the integration repository for QA, and may be made available to users as appropriate.
    Project viewer builds use a distinct channel "Second Life Project project-name". Using a Project channel causes those builds to use the Project Viewer icon and have a light blue top menu background:
    Viewer-Icon-Project.png Viewer-Menu-Project-2.png

The project may decide to produce a beta release in order to do higher-risk testing and/or to get wider user testing, or it may elect to skip the Beta Test phase and proceed to directly to producing a Release Candidate.

Beta Test

Whether or not a project releases a Beta viewer is up to the project. If the project elects to release a beta, it is built for and released on the Second Life Beta project channel. Using a Beta channel causes the viewer to have the beta viewer icon, and a purple menu background:

Viewer-Icon-Beta.png Viewer-Menu-Beta-1.png

Release Candidate

When the Viewer Release Product Owner and project lead determine that the project has met its functional goals and it is believed to be ready for general release, the Release Candidate phase begins. Release Candidate builds use the Second Life Release channel, so they use the default icon and menu color:

Viewer-Icon-Release.png Viewer-Menu-Release-1.png

Release Candidates are offered as optional updates to a randomly selected small subset of users running a Release viewer. The project team and QA monitor the bugs reported against the Release Candidate, any crash reports it uploads, and the performance statistics for it to determine whether or not it is ready to be promoted to the default Release viewer.

There may be more than one Release Candidate at the same time.

Release

When it is determined that a particular Release Candidate is ready, it is promoted to the default Release viewer.

Sources for that project are then pulled (not merged, since they are a direct descendant) to viewer-release, a major.minor.patch-release tag is added, the patch (third level) version number in viewer-release is incremented, and then all other projects merge out those changes.

Mercurial Repositories

viewer-release
http://bitbucket.org/lindenlab/viewer-release
The viewer-release repo records the code used to produce all released viewers through the latest Release version currently in production.
Write access to the this repository is closely controlled.
This is the stable repository that serves as the base for all development.
NOTE: The viewer-beta and viewer-development repositories used in earlier versions of this process are no longer used; viewer-release is the single canonical repository.
project viewers
The links to the project viewers repositories can be found on the Linden_Lab_Official:Viewer_Source_Repositories