There is no time on my side to give a full and detailed answer to this as
a full book could be filled on all the possibilities and options you have in
Smalltalk.
One should remember the following few points:
1. Breaking code is nothing specific to a language. The usual weapon also
in Smalltalk is to monitor if something breaks - for instance by using CI.
Continuous integration only makes real sense when you have tests.
One should remember that "test first", "unit testing" and "Extreme
programming" (XP)
like many other things had their roots in Smalltalk. Because in dynamic
languages testing using code was and is part of the culture (ranging from
lively verifying
with workspace expressions and inspectors up to fully written tests).
The first unit testing framework "SUnit" was written by Kent Beck for
Smalltalk (SUnit), later he ported it to Java with Erich Gamma on a flight
to OOPSLA OO conference. Java helped to push the popularity afterwards.
Meanwhile also static language enthusiasts have understood that it is
better to
rely on tests than type checking compilers and they now hurry up to follow
what Smalltalk already had years ago.
One last thing you should try: try to query your system how many test
methods were
written. When you solved this easily with a Smalltalk expression retry
this in Java ;)
2. Commercial Smalltalks which are often used in big projects provide
solutions
which are repository based like the famous ENVY (written by OTI, was
in VisualAge for Smalltalk from IBM, now VAST) or Store (VisualWorks). For
more details try the commercial evaluation versions or read [1] or [2].
A screenshot of Envy can be seen in [3]. I worked with ENVY and it is really
good - but mostly only for internal work/teams. If I remember correctly
ENVY once was also available for VisualWorks (VW) ... but later got replaced
for business or license reasons. I'm not sure about that point.
Cincom developed Store for VW as a replacement which is also nice as it
allows to work
in an occasionally-connected mode, so work offline and push
packages/versions later to
a central team repo.
In the open source world there are different solutions (including Monticello
which is available for nearly all Smalltalk derivates) or newer solutions
like FileTree or Iceberg allowing to work with Git.
The workflow depends on the tool and your requirements.
3. Often it makes sense to automatically build and regular distribute a fresh
daily
developer images to the members of your team. This helps in later merging
code.
For instance Kapital (a big financial project from JP Morgan) works that
way and I've seen that model very often. See [4]
Again nothing special to Smalltalk. In more file based languages it also
makes
sense to stay close to the main line and merge as well as resynchronize
with the
team.
In Pharo for instance we have the PharoLauncher that allows you to download
any (fresh or old) image built provided by the open source community.
3. Versioning can be done on many levels. Simplest level is the image itself.
Smalltalk not only has an VM and image concept - but also the concept of a
changes
file. If you evaluate a code expression, create or modify a class or method
in the system this gets logged there.
It prevents you from loosing code and it is easy to restore quickly for
instance
an earlier method versions/editions that one has implemented.
Most Smalltalks now also work with packages and you can define package
dependencies as well as declaring versions that fit together to provide
a project, goodie or app (for instance with a Configuration class in
Monticello)
While in file based languages this is often done in an XML file (Maven for
instance)
or a JSON file in Smalltalk this is usually expressed with objects and
classes again.
This also makes it more flexible as you can very easily do queries on it or
use refactoring tools to even restructure or reconfigure.
4. Usage of shared code repositories is very common also in Smalltalk. While
you
now can also use GitHub, GitLab, Gogs and others with Iceberg and friends
in Smalltalk
there are also repository systems implemented in Smalltalk itself like
- SqueakSource (http://source.squeak.org, http://squeaksource.com)
- SqueakSource3 (http://ss3.gemtalksystems.com)
- SmalltalkHub (http://smalltalkhub.com)
5. Beside repositories where code and goodies are hosted one often finds
registries
with infos about loadable components.
Pharo for instance has http://catalog.pharo.org which is accessible also
directly from the image.
5. If you work in a team you can also use a custom update stream. This is how
for instance open source projects like Pharo and Squeak are managed.
So anyone can hit an "update" button to get the latest changes.
In Pharo http://updates.pharo.org is used and you can have a look at
UpdateStreamer
class to see how easy that works over the web or how to customize it for
own needs.
7. If one requires not only collaboration for the development team (coding) but
would like to collaborate also with other projects members on other
artefacts
(Excel, project plans, documents, ...) then one should have a look at tools
like this
http://www.3dicc.com
which is implemented in - guess what: SMALLTALK.
This list could be endless ... the first few points should only give a glimpse
on
what is there and available.
Have fun
T.
[1]
https://www.cambridge.org/core/books/mastering-envydeveloper/56EE45AFF26F80743BA46C2754C94991
[2]
http://www.cincomsmalltalk.com/main/documentation/VisualWorks/SourceCodeMgmtGuide.pdf
[3] http://www.edm2.com/index.php/Installing_the_VisualAge_UML_Designer
[4] http://www.slideshare.net/esug/13-yanndmonclair
