Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

OSEE/Deployment

< OSEE
Revision as of 17:47, 12 February 2013 by Donald.g.dunne.boeing.com (Talk | contribs) (Deploying A Change)

Deploying A Change

Depending on the type of action, care must be taken to deploy to an production site.

  • Additions modifications of Artifact, Attribute and Relation types
    • If changes to the type model are additions or minor modifications, they can be made directly in the production unified type artifact without down-time
    • If the changes include deletions or renames of types, you will need to coordinate converting the database before making the changes to he types.
  • Code changes
    • If multiple releases of OSEE are deployed, code changes must be made in a compatible way such that the current release can continue to work while the alpha and beta releases are able to be tested and released to a smaller user audience. One way is to use the OSEE_INFO table to create a flag that allows old code to run until toggled. This allows the development and testing of the new code, but alpha and beta and full releases won't run the new code until the flag is toggled.

Followup changes during and after a release

  • If changes are necessary during a release, such as table conversion or converting database attributes, you will need to create a ATS action labeled "During <release id> work". Then add a task in the task tab that explains what work needs to be done and references the Action that it's being done for. Provide enough detail that any OSEE developer can perform the task.
  • If changes are necessary after a release, such as cleaning up deactivated or compatibility code, create a ATS action labeled "Post <release id> work". Then add a task in the task tab that explains what work needs to be done and references the Action that it's being done for. Provide enough detail that any OSEE developer can perform the task.

Releases

The OSEE Development process is designed to enable a change to be adequately reviewed and tested such that it could be quickly incorporated into the a next release. The releases attempt to facilitate this.

  • OSEE Release
    • Production Release
    • Most Stable Release
  • OSEE Release Candidate Beta
    • Next release to be released to Production
    • Used by smaller subset of user base
  • OSEE Release Candidate Alpha
    • Nightly snapshot of what has been released into the current RC branch
    • Can be promoted to Beta when changes are ready
  • OSEE Development Beta
    • Trusted changes from the development line
    • Normally only used by OSEE developers or users who need to test a single change
    • Unstable and can be updated / restarted anytime
  • OSEE Development Alpha
    • Nightly snapshot off development line
    • Only used by OSEE developers
    • Most unstable and can be updated / restarted anytime

Back to the top