[GemStone-Smalltalk] GemStone code management techniques
Paul Baumann via GemStone-Smalltalk
gemstone-smalltalk at lists.gemtalksystems.com
Mon Dec 4 13:43:11 PST 2017
One solution with a long history is called GemKit. GemKit allows GS/S
code to be maintained using the same code repository and development
tools as a client dialect of Smalltalk (VisualAge or VisualWorks).
GemKit is designed to work in conjunction with GemBuilder for Smalltalk
GemKit started as a framework developed by GemStone Consulting at
customer sites with updates shared between customers. It was sold as a
product for several years and then had several years of abandon. While
employed with GemStone/GemTalk I refined it into a product that was
released under an open source license for anyone to use. It was
originally ENVY/Developer based, so it worked with VisualSmalltalk,
VisualWorks, and VisualAge. At that time I had refined it to have a
common code base for all three ENVY supported dialects. I ported it to
VW Store (with assistance from Joseph Bacanskas) at a Camp Smalltalk
event in Colorado. I significantly refined GemKit after my time with
GemStone as new employers needed it. Currently there is a GemKit for
VisualAge (that I developed at WAMU) and a GemKit for VisualWorks (that
I developed at ICE). For both variants I had separately refactored about
90% of the code. There are now easier maintained object models in both,
but the models were created at different times and are not the same
between VA and VW. GemKit was open source and had also evolved from the
original consulting code. There are likely several variants all called
"GemKit". David Buck had ported GemKit for VW to a newer version of VW
for one of his clients, ICE also uses GemKit for the latest VW but by
different effort. I no longer maintain this code and have no idea
whether David or ICE would be the best source for updates to that code.
Sharing of changes is expected by the open source license, but there is
no incentive system to do this and so code just disappears as companies
do. Older versions may exist on SourceForge.
Answers to your specific questions:
1) GemKit uses the native code management tools of VA (ENVY) or VW
(Store). GS code is maintained through a client image that immediately
updates GS if there is an active session. It is possible to manage GS
code without a GS session and update GS later either by code comparison
tools or by change scripts. All special tools (like code refactoring)
are available to GS code through GemKit.
2) GS code is traditionally stored in separate "GS_" prefixed
applications/packages. Newer versions of GemKit allowed a package to
contain a mix of client and GS code (distinction was at the class level
rather than by package). Class extensions are fully supported just as
you would expect it to work for client code.
3) I also created version control systems for both WAMU and ICE. That
was never part of the original GemKit. The version control system is
effectively part of GemKit now. The original GemKit produced GS
fileouts. The newer GemKit can also produce fileouts as change sets and
that have better support for GS class extension permissions. The release
tools were designed to incentivize developers to quickly integrate their
working changes to reduce code merge effort and generally reduce bugs
from delayed integrations. It was compliant with all the buzzwords
expected now, before the buzzwords were thought of. The release tools
proved extremely important for team productivity and build quality.
4) Interactive updates can be made by logging into GS and comparing a
loaded or specific version of code with what exists in GS. Releases are
typically deployed with GS patch files (.gs fileout). A fileout can be
produced for all the code of a release or to bring code from any
specific version up to a targeted version. GS class extension code (that
requires SystemUser or DataCurator login) is in a separate but similarly
named "_extensions.gs" patch file. When a class schema is changed then a
patch will include all the code of all subclasses too. Class migrations
and version-specific update code is traditionally part of the .gs update
script. If you create a patch to go from version 1 to 10 and there are
several version and that have pre and post migration code then that pre
and post code is automatically combined to work as you would hope. At
ICE they wanted to separate and customize this code for each upgrade,
and so that is possible too.
I have the impression that GemTalk is finding reduced customer demand
for GBS. That means that GemKit is less used too. GemTalk now has more
emphasis on web clients and code management through Monticello and git.
GemKit is an established way of GS code management that is again falling
to neglect. GemKit might possibly be the best solution out there but
there isn't much of a market to share a specialized tool like this.
GemKit became significantly refined over the years but you'll still find
some messy code in there. It works well though and has had years of
mission-critical utility. In a very real sense, GemKit for VW has such
utility that it alone can be a reason to buy licenses for VW and GBS.
GemTalk stands behind Monticello, so you might try that solution first
to see if it meets your needs.
Retired from Software Development
On 12/04/2017 09:47 AM, via GemStone-Smalltalk wrote:
> We're interested to know what techniques other GemStone users are
> using for their GS Smalltalk code management and deployment processes,
> hence a few very general questions to anybody inclined to answer:
> 1)What tools/editors do you use for writing GS Smalltalk code?
> 2)What packaging system do you use for organising your code and
> separating out your extensions to core classes from GemTalk Systems'
> own code?
> 3)Which version control system do you use, and in what kind of
> structure do you store your code (what does one file in your source
> code repository represent, if file-based)? How do you extract a
> deployable set of changes from your version control system?
> 4)What mechanism do you use for uploading code to your production
> GemStone DB?
> Any feedback much appreciated!
> Thanks and regards,
> GemStone-Smalltalk mailing list
> GemStone-Smalltalk at lists.gemtalksystems.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the GemStone-Smalltalk