Tracy,
Lots of luck! We use SourceSafe religiously for the developers. Care to
guess what happens way too often? Change control is more of a philosophy than a
software package. Proving the worth of the mindset change is easy. Getting it
practiced is hard! :(
Dick Goulet
____________________Reply Separator____________________
Author: "Tracy Rahmlow" <[EMAIL PROTECTED]>
Date: 11/13/2002 10:09 AM
I am looking for more details on the integration of a version control product
(sourcesafe) and a change control product such as BMC's change manager. Are
there any good sources of info relating to an optimal configuration. For
example, do you have separate project folders within sourcesafe for dev,
acceptance and prod source versions? If so, how do you deploy the change to a
target database using a product like BMC's change manager? In addition, how
are projects defined with a version control system. By entity type or project
release? For example, which layout within a version control system:
/dev/policy entry/xxxx.exe
/xxxx.sql
or
/dev/exe/xxxx.exe
/sql/xxxx/sql
or some other option? We are really struggling between a released-based
structure vs an entity type. Anybody aware of any good papers describing
version control and deployment for oracle objects as well as other type such as
java, vb, shell scripts??
M PST
Please respond to [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
cc:
The releases should be tried in the Development environment first. Then a
UAT (User Acceptance Test) environment, then production. The UAT
environment is usually a duplicate of the production environment. This is
the environment that you implement the changes , then test to see if the
changes worked and if there are any side effects.
The end user , project manager, information owner, or test manager signs
off that the changes were implemented correctly. Then approval is given and
the change is implemented in the production environment. This is usually
accompanied by some sort of change control management. Also, use some sort
of source code control to keep the DML and DDL scripts in. Oracle's SCM
Repository (once part of Oracle Designer), TrueChange by TrueSoft, PVCS,
etc. are candidates for this.
By implementing the scripts in the UAT environment, any dependencies become
evident. Also, the developers should submit the changes in fully runnable
SQL scripts, with
appropriate comments. If the scripts are dependent upon some other script
or database object, this should be listed in the SQL file comment header,
along with the authors name and a description of the file.
Hopefully this will get you going.
RWB
"Jamadagni, Rajendra" <[EMAIL PROTECTED]>@fatcity.com on
11/13/2002 09:29:47 AM
Please respond to [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Friends ...
I have a (sort of) problem ... what are the best practices to manage code
releases to production environment ...
currently we get a bunch of scripts from development team, and we release
code to production on the schedule (currently twice a month). But this is
not complete. The scripts we get consists of various DML and DDL
statements.
We do not have a mechanism to roll-back these changes in place and I am
seeking your opinion on ways to achieve these. Also we would like to
implement script dependencies (which we manage manually right now) and
rollback mechanism.
Are there any good practices papers? I know these would be site specific,
but I am looking for common methods.
Hope I make myself clear ... (and if it matters it is Oracle 9.2 and
Forms/Reports) application.
Raj
______________________________________________________
Rajendra Jamadagni����� ������� MIS, ESPN Inc.
Rajendra dot Jamadagni at ESPN dot com
Any opinion expressed here is personal and doesn't reflect that of ESPN
Inc.
QOTD: Any clod can have facts, but having an opinion is an art!
(See attached file: ESPN_Disclaimer.txt)
(See attached file: ESPN_Disclaimer.txt)
ESPN_Disclaimer.txt
Description: Binary data
