as the persistence mechanism. Problem is that most of the SmalltalkLanguage
code in the systems resides in GemStone
. We use GemKit
to manage our GemStone
code in EnvyDeveloper
4.0. It works reasonably well. There are still a few bugs, but we work in such a way that they do not bother us. Without GemKit
it would be much harder.
Many projects such as the ChryslerComprehensiveCompensation
project have taken the approach of coding, testing, and managing code in the VisualWorks
environment. On a regular basis all the code is dumped into GemStone
, tested and released to production.
It was decided here to code everything that was to be in GemStone
only. Several problems present themselves. How do we do FrequentReleases
? Each developer must be able to work in a stable version of the system until integration is desired. Each developer must be able to obtain the latest version of the system and merge changes quickly. Each developer must be able to find differences between modified code and released code. Developers must be able to quickly resolve conflicts.
Our solution was to create a GemStone
database for each developer. We also created a database for the SingleReleasePoint
workstation. Each database has the same user id created. Each developer then used the same GemStone
user id on each of the databases. Three scripts were written. One would backup the extents (physical files) of the SingleReleasePoint
workstation. The second would restore the database of the SingleReleasePoint
workstation from the backup. The third would replace a developer database with a copy of the backup of the SingleReleasePoint
is accomplished by each developer taking turns at the SingleReleasePoint
workstation. Changes are loaded into both Envy and GemStone
. Any last minute integration is done. Changes are committed into GemStone
. The UnitTest
s are run. (Most of our UnitTest
s are run in GemStone
.) If a score of 100% is achieved then the changes are released into Envy and the database backup script is run. At this point the backup of the database and the Envy released versions are exactly in sync. This is very important
and requires discipline to maintain.
If the UnitTest
score was not 100% then the code is either fixed or removed. To remove the offending code, the restore script is run to put the database back to its original state when the developer first approached the SingleReleasePoint
. While it is true that a developer could "back-out" all code changes from GemStone
and then re-commit, it is much faster, easier, and more accurate to run the restore script. Then the released versions of code are reloaded to reset Envy. Since the person using the station before you performed exactly the same process, the Envy and GemStone
versions remain in sync.
works for each developer by opening Visualworks and loading the latest versions of code from Envy and running the copy script for the database. Now the developer's image and database are identical to those on the SingleReleasePoint
workstation (and in sync). Local changes are then added and GemStone
is committed as changes are integrated. This method is very fast and only takes a couple minutes.
Every week an empty GemStone
database is created for the SingleReleasePoint
workstation. All of the code and data is dumped into it fresh, UnitTest
s are run. This ensures any out of sync code will be brought back into sync. We accept that mistakes happen.
We do things slightly differently.
Our developers also have their own GemStone
databases, but we manage our Smalltalk code in CVS [ConcurrentVersionsSystem
]. Whenever someone edits a class or method in VisualWorks
, the updated .gs file is written to the checked-out CVS tree. We have a script that files the .gs files back into GemStone
Instead of using a single integration box, we manage the configuration of our LinuxOs
development boxes so that they are all the same, and each pair can integrate on any computer. Then the other pairs merge via CVS and 'make' fresh GemStone
databases one their boxes.
The neat thing is that this script can either start off with a backup of the pristine, empty database that ships with GemStone
, or with a backup of production. We can 'make' either a development database (recent code but no real data), our a upgraded version of the production database (recent code + our live production data, migrated) on our development boxes. The same script is part of our deployment process, when we deploy to the real live production server.