|
|
| (3 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| − | ===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.
| |
| − | * Tracking release changes
| |
| − | ** 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.
| |
