Kbase 15377: Handling multiple baseline releases in Roundtable
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
Handling multiple baseline releases in Roundtable
Handling Multiple Baseline Releases
===================================
Purpose:
========
Discuss practical requirements for handling multiple baseline
releases of an application being maintained by Roundtable TSMS.
The system should not require customer upgrade from one baseline
release to the next, but will detail the steps required to do so.
Roundtable will allow selective changes to any baseline products
for deployment to customers selectively.
The XYZ Corporation has an Accounts Receivable package that has
been under development for 3 months. After extensive Q&A they
are ready for the first release. They call it ARv1.0. This first
production baseline is contained in a workspace called Prod #1.
Four customers decide to purchase the AR package and receive
deployments of ARv1.0. The first deployment is done when the
workspace release number is 6. (These previous 5 releases were
used during internal testing or beta testing by selected customers).
Quick Reference:
Cust# Deployed From W/S Rel# System Ver
----- ------------- -------- ----------
1 Prod #1 6 ARv1.0
2 Prod #1 6 ARv1.0
3 Prod #1 6 ARv1.0
4 Prod #1 6 ARv1.0
Two groups of changes are made to Prod #1. These changes
represent workspace release number 7 and 8 with a system name of
ARv1.1. Customers receive these incremental changes from the
Prod #1 workspace.
Quick Reference:
Cust# Deployed From W/S Rel# System Ver
----- ------------- -------- ----------
1 Prod #1 8 ARv1.1
2 Prod #1 8 ARv1.1
3 Prod #1 8 ARv1.1
4 Prod #1 8 ARv1.1
XYZ corporation specifies a large group of changes that will be
delivered as a new system level called ARv2.0. ARv2.0 will
contain all the changes in ARv1.1.
Quick Reference:
Cust# Deployed From W/S Rel# System Ver
----- ------------- -------- ----------
1 Prod #1 8 ARv1.1
2 Prod #1 8 ARv1.1
3 Prod #1 8 ARv1.1
4 Prod #1 8 ARv1.1
Creating new baseline workspace from previous workspace:
1. Create a new workspace (Prod #2) which will be the new
baseline workspace for ARv2.0.
2. Import from previous baseline workspace (Prod #1) and create a
workspace release number 1.
3. This release establishes that release 1 in Prod #2 is equivalent to
release 8 in Prod #1 or ARv1.1 = ARv2.0 at this time.
Import the new ARv2.0 changes from the Beta workspace:
Quick Reference:
Cust# Deployed From W/S Rel# System Ver
----- ------------- -------- ----------
1 Prod #1 8 ARv1.1
2 Prod #1 8 ARv1.1
3 Prodc#1 8 ARv1.1
4 Prod #1 8 ARv1.1
Import Version 2 changes:
1. Sever the relationship with workspace Prod #1.
2. Import ARv2.0 enhancements from the Beta workspace.
XYZ Corporation offers a free upgrade option to all its customers.
Customer #3 and #4 want to receive the additional enhancements
included in ARv2.0 immediately. Customers #2 and #1 are
satisfied and do not want to upgrade at this time.
Quick Referenc:
Cust# Deployed From W/S Rel# System Ver
----- ------------- -------- ----------
1 Prod #1 8 ARv1.1
2 Prod #1 8 ARv1.1
3 Prod #2 2 ARv2.0
4 Prod #2 2 ARv2.0
Moving customers between baseline workspaces. If the current
baseline workspace has not been changed since new baseline was
created:
1. Customer #3 and #4 must be at ARv1.1(workspace release 8) in
workspace Prod #1. If they are not, upgrade the customer to
ARv1.1 before proceeding.
2. Create a deployment for customer #3 and #4 for release 1 in Prod
#2 workspace. Remember: Prod #2Æs release 1 is equivalent to
Prod #1Æs release 8.
3. Complete this deployment without doing a Make. This captures
the time when both workspaces are the identical.
4. Create a new release and customer deployments for release
number 2 . These deployments will only include the changes that
were made for ARv2.0.
Additional enhancements have been made to the baseline
workspace Prod #2. Prod #2 is currently at workspace release 4
with a system name of ARv2.1. Patches have been selectively
imported (using the assign process) into workspace Prod #1. Prod
#1 is currently at workspace release 9 with a system name of
ARv1.2. Customer #2 now decides they do want the benefits of
ARv2.1. Since Prod #1 is on a higher release than when Prod #2
was created, they need to be synchronized before a site can be
moved.
Quick Reference:
Cust# Deployed From W/S Rel# System Ver
----- ------------- -------- ----------
1 Prod #1 9 ARv1.2
2 Temp 1-2 2 ARv2.1
3 Prod #2 4 ARv2.1
4 Prod #2 2 ARv2.0
If current baseline workspace has been changed since new baseline
was created:
1. If the site is not at the current workspace release of Prod #1
(release 9) a deployment must be made to bring the customer up
to the current release.
2. Create a new temporary workspace Temp 1-2. To minimize
space and time building the new workspace, set the S code flag
set to NO and the Xref level to 1. The Update Schema process
can be minimized by using the Skip All option before running
the Update option.
3. Import objects from the previous baseline workspace(Prod #1)
into workspace Temp1-2.
4. Create workspace release 1 in Temp 1-2. (This captures the
current status of the customer).
5. Create a customer deployment in Temp 1-2 at a workspace
release number 1 and Complete the deployment without doing a
Make.
6. Import objects from the Prod #2 workspace.
7. Create a second workspace release in the Temp 1-2 workspace
and make a customer site and deployment to the customer.
8. Create a customer site and deployment on the Prod #2 workspace
and Complete it without doing a Make. This will make it
consistent with the temporary workspace. All future releases
would be handled through the Prod #2 workspace.
9. Delete the temporary workspace (Temp 1-2).
Scenario:
If XYZ corporation required that all customers upgrade to ARv2.1
or all four customers elected to upgrade to ARv2.1 then all the
changes could be imported from the Prod #2 workspace into the
Prod #1 workspace and deployed from there.
Quick Reference:
Cust# Deployed From W/S Rel# System Ver
----- ------------- -------- ----------
1 Prod #1 10 ARv2.1
2 Prod #1 10 ARv2.1
3 Prod #1 10 ARv2.1
4 Prod #1 10 ARv2.1
Upgrading all customers from a previous baseline to the current
baseline:
1. The workspace Prod #1 should receive all changed objects from
Prod #2.
2. Workspace release 10 would be created in Prod #1 and all 4
customers would receive a deployment of the changes.
3. Create sites for all customers being moved in the Prod #2
workspace and create a deployment for workspace release 2.
4. Complete this deployment without doing a Make. Release 10 in
the Prod #1 workspace is equivalent to release 2 in the Prod #2
workspace.
Custom Workspaces:
XYZ corporation had one customer (#9) that requires a custom
configuration of the AR module. They want to selectively have
access to the ARv2.1 changes. The Cust #9 workspace contains all
of the custom changes that have been made. By importing the
changes from the Prod #2 workspace they can selectively import all
desired changes.
Incorporate baseline changes into a custom workspace:
1. Select the source of the Cust #9 workspace to be the current
baseline workspace (Prod #2).
2. Import all desired changes from Prod #2 into Cust #9.
3. Create release and deploy all selected changes to the custom site.
Copyright 1994 by StarBase Corporation, All Rights Reserved
Progress Software Technical Support Note # 15377