RE: List Archive and Release Management

Question

Hi back.
>> what procedures do people use to manage the development, testing
and release of software?
It's useful to have a separate repository for Development, QA, Production,
etc. It's true that you have to 'import' between them, each time you
propagate changes. It might seem like a pain to constantly export/import,
but actually it's better that way.
Firstly, you should only export to QA when you're absolutely sure it's ready
for quality assurance, and this doesn't happen every day (or shouldn't)
Second, the advantage of this is that you get a 'clean' import and compile
each time, with no other baggage. This is especially critical when you
migrate from QA to a production environment.
There's no need to have a testing_verXX repository, just make a different
workspace for each version of test.
Just check out all the components, import, and integrate. The 'old'
workspace will have a snapshot of the old release.
* Don't Update that old workspace or you'll lose it!
* Put an administrator password on the repos, to protect against
inadvertent usage.
* It's expensive to have many repositories running on your environment
manager, so I recommend only one repos for each of development, QA and
Deployment.
* You might want to consider only bringing up the production repos as
required, they hog RAM like crazy.
It's critical to have a complete image of each version of every application
you have in production. That way, you can recreate any problem.
It's even useful to migrate your development repos every now and then. As
you know, these repos beasties can grow quite large, and it's god to start
from scratch on a regular basis.
For example, every month or so, our core architecure team releases a new
version of the core components. We all integrate, and we create a new repos
from the core architecture stuff, and import all our stuff over the top of
it. That way, we keep a loose coupling between sub-systems, and their stuff
never depends on ours. Also, with a split developmen repos, you can locate
the different teams on different intranets, or even on different sides of
the world, all with relatively little fuss.
Forté SCM hooks and SCCSWe use a unix version control called CMVC.
Whenever we integrate, it checks out the pex files, exports them, and checks
them back in.
John Pianezze
S1 Technologies (Asia Pacific)
Melbourne, Australia
-----Original Message-----
From: Duncan Kinnear [SMTP:[email protected]]
Sent: Wednesday, July 21, 1999 1:05 PM
To: [email protected]
Subject: List Archive and Release Management
Hi folks!
First of all, does anyone know what's going on with the list archive
on
SageIT? There doesn't seem to be a search facility anymore. Seems
a
bit weird when each message is appended with a little signature
'advertising' a searchable archive.
Second (and this is the biggy!), what procedures do people use to
manage the development, testing and release of software? I'm
talking
about how you keep them separate, how you do hot-fixes, how you
identify installed versions at customer sites, etc.
I've thought that we could do it with separate repositories for
"current
development", "testing_verXX", "release_verXY", etc., where we
export
from "development" and then import into "testing", and similarily
for
"release".
Also, we are looking at using the Forté SCM hooks and SCCS on our
Unix host to store historical versions of the projects/classes. But
we
somehow need to identify which version of a particular component is
installed at the customer site. I had thought of defining a
constant in
each project/class called "SCCS_VER" which contains the SCCS
keywords that get mapped to SCCS ID and date when put into SCCS.
Then the constant could be used to display these values in a
Window's
"About" window.
Any thoughts/opinions welcome.
Cheers,
Duncan Kinnear,
McCarthy and Associates, Email:
[email protected]
PO Box 764, McLean Towers, Phone: +64 6 834
3360
Shakespeare Road, Napier, New Zealand. Fax: +64 6 834
3369
Providing Integrated Software to the Meat Processing Industry for
over 10 years
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/forte>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/forte>

Answer 1

Under Forte 2 we used to export all projects, then import them into a make
repository, then produce an app. Due to the time involved importing &
exporting, and errors resulting from importing projects out of order, we
switched to making copies of the dev repository and producing apps from
that. For us, it used to take 2+ hours to export/import, as opposed to 5
minutes for copying repository files. Unfortunately, we have found that
unless we force-compile prior to deploying, we will get errors when
attempting to compile partitions.
Our current procedure:
Shut down dev repos
Copy to make env
make a workspace that includes all projects
force-compile
update
integrate
make a new workspace for each app to make
make each app
export code
remove unused workspaces
clean repos
-----Original Message-----
From: Peter Sham (HTHK - Assistant Manager - Software Development, IITB)
[mailto:[email protected]]
Sent: Wednesday, July 21, 1999 3:31 AM
To: John Pianezze; Duncan Kinnear
Cc: [email protected]
Subject: RE: List Archive and Release Management
Hi,
We, like what you've explained, keep different releases of our application
in different workspaces. However, when the release is getting larger, this
"check-out-every-components-then-overwrite-by-import" procedure get tougher.
Sometimes, it even creates garbage in the repository which corrupts my
workspace.
So, I have an alternative proposal on this procedure ( though I haven't
really test on this idea ) which is to create a new repository for each new
release.
What do you think?
Regards,
Peter Sham.
-----Original Message-----
From: John Pianezze [SMTP:[email protected]]
Sent: Wednesday, July 21, 1999 3:44 PM
To: Duncan Kinnear
Cc: [email protected]
Subject: RE: List Archive and Release Management
Hi back.
what procedures do people use to manage the development, testingand release of software?
It's useful to have a separate repository for Development, QA, Production,
etc. It's true that you have to 'import' between them, each time you
propagate changes. It might seem like a pain to constantly export/import,
but actually it's better that way.
Firstly, you should only export to QA when you're absolutely sure it's
ready
for quality assurance, and this doesn't happen every day (or shouldn't)
Second, the advantage of this is that you get a 'clean' import and compile
each time, with no other baggage. This is especially critical when you
migrate from QA to a production environment.
There's no need to have a testing_verXX repository, just make a different
workspace for each version of test.
Just check out all the components, import, and integrate. The 'old'
workspace will have a snapshot of the old release.
* Don't Update that old workspace or you'll lose it!
* Put an administrator password on the repos, to protect against
inadvertent usage.
* It's expensive to have many repositories running on your environment
manager, so I recommend only one repos for each of development, QA and
Deployment.
* You might want to consider only bringing up the production repos as
required, they hog RAM like crazy.
It's critical to have a complete image of each version of every
application
you have in production. That way, you can recreate any problem.
It's even useful to migrate your development repos every now and then. As
you know, these repos beasties can grow quite large, and it's god to start
from scratch on a regular basis.
For example, every month or so, our core architecure team releases a new
version of the core components. We all integrate, and we create a new
repos
from the core architecture stuff, and import all our stuff over the top of
it. That way, we keep a loose coupling between sub-systems, and their
stuff
never depends on ours. Also, with a split developmen repos, you can locate
the different teams on different intranets, or even on different sides of
the world, all with relatively little fuss.
Forti SCM hooks and SCCSWe use a unix version control called CMVC.
Whenever we integrate, it checks out the pex files, exports them, and
checks
them back in.
John Pianezze
S1 Technologies (Asia Pacific)
Melbourne, Australia
-----Original Message-----
From: Duncan Kinnear [SMTP:[email protected]]
Sent: Wednesday, July 21, 1999 1:05 PM
To: [email protected]
Subject: List Archive and Release Management
Hi folks!
First of all, does anyone know what's going on with the list archive
on
SageIT? There doesn't seem to be a search facility anymore. Seems
a
bit weird when each message is appended with a little signature
'advertising' a searchable archive.
Second (and this is the biggy!), what procedures do people use to
manage the development, testing and release of software? I'm
talking
about how you keep them separate, how you do hot-fixes, how you
identify installed versions at customer sites, etc.
I've thought that we could do it with separate repositories for
"current
development", "testing_verXX", "release_verXY", etc., where we
export
from "development" and then import into "testing", and similarily
for
"release".
Also, we are looking at using the Forti SCM hooks and SCCS on our
Unix host to store historical versions of the projects/classes. But
we
somehow need to identify which version of a particular component is
installed at the customer site. I had thought of defining a
constant in
each project/class called "SCCS_VER" which contains the SCCS
keywords that get mapped to SCCS ID and date when put into SCCS.
Then the constant could be used to display these values in a
Window's
"About" window.
Any thoughts/opinions welcome.
Cheers,
Duncan Kinnear,
McCarthy and Associates, Email:
[email protected]
PO Box 764, McLean Towers, Phone: +64 6 834
3360
Shakespeare Road, Napier, New Zealand. Fax: +64 6 834
3369
Providing Integrated Software to the Meat Processing Industry for
over 10 years
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/forte>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/forte>-
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/forte>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/forte>