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.