On Wed, Jul 19, 2017 at 9:47 AM, horrido <horrido.hobbies@gmail.com> wrote:

1) When everything is a work in progress, it��s impossible to manage a
project, maintain deployed code (��what version do you have, what did you
modify? clearly that��s where the bug is��), update things (interfaces change,
updates overwrite local mods), etc.

I've been working on a big production Smalltalk application (IBM Smalltalk / VisualAge) for a long time, and the approach we take is to use the development environment for R&D, and with select beta customers, and then periodically package a runtime when we want to release to the customer base.�� It gives the best of both worlds: a live development environment with the myriad debugging and productivity advantages that that brings, and a more conventional deployment model for the customers.

��

2) The typical deployment model is to deploy a completely new virtual
machine & environment. For some things (e.g., servers), that works - and
seems to be the way of the world with containerization - but for other
things (e.g., desktop applications), deploying an entire new environment for
every patch is just a bit match.

Don't know why you'd need to deploy a completely new VM and environment with each release.�� When we give a customer an update, we give them a new packaged runtime image, which is a small fraction of the size of the VM and its supporting files.�� When we had a Smalltalk "fat client" (now our UI is RESTful web services and XHR-heavy web app), deploying the runtime image for each release worked well.