3 ms·

I always wondered, how do you deploy it? Are you able to use git or other VCS? Are there other developers working on the same image?

melvinroest 4y ago
I don't know much about deployment. In terms of version control, we use git. I find it a bit tricky though as there's a git repo inside the Pharo image, and then there's the file based git repo and they need to be kept in sync. I've gotten used to that though, but it's not ideal. Every developer has their own image. It's easy to set up an image (though I always need to check the company docs on how to exactly do it), but then you download your own image. These images can be different from each other as well, as only the code checked in to git is the same.
deleted 4y ago
[deleted]
0x445442 4y ago
The image is just an in memory representation of the code. At any point one can export the code representation in the image to an external text file in a number of different formats. These external text files can be version controlled with Git or any other VCS. In turn the the text files can be imported into an image as well. I never worked with Smalltalk professionally but I imagine deployment works in a very similar way to the deployment pipelines you might be used to. Start with a base image, import code pulled from the VCS repo, start the image, run some test verifications and copy the image to its designated virtual insurance host.
- codesnik 4y ago
  it's not only a code, it's a also current _state_ of the system, no? some kind of root/singleton objects, their instance variables, etc. I mean, for a web application most state should be in a database, but this takes some discipline. And importing updated code to a live system sounds like a black magic. What happens while it's still in progress? Or does one have to start a new process, like we do in other frameworks? Erlang has live updates, but I imagine live update in smalltalk works very differently. So many questions!
  - 0x445442 4y ago
    Yeah, the entire state can be saved off. I was just trying to limit the context of the reply to code WRT VCS. > I mean, for a web application most state should be in a database, but this takes some discipline. This state could also reside in an image and Smalltalk has solutions like GemStone and Magma (OODBMS) solutions. > And importing updated code to a live system sounds like a black magic. Yeah, I don't think for most use cases this would be done. A new image would be built and deployed with the relevant code changes applied.
  - folmar 4y ago
    The short answer is: just try it, you are in for a lot of fun and puzzles. If you have Windows nearby I would recommend Dolphin Smalltalk due to a great system browser. > it's not only a code, it's a also current _state_ of the system There is no difference in Smalltalk. The code includes all the created instances with current field values. > updated code to a live system From the user point of view everything is simple, yet the simplicity is the advantage of the compiler, not the user. If you update the code the instances that you upgrade run the new code, and if you don't upgrade the old objects they run the old code.
- whartung 4y ago
  Typically, a ST image is a combination of the base image, and the change set applied to the image. The change set can be code loaded in from an external source, or someone hacking in the system. By default, all changes made to an image are serialized to a changes file. That way, if your image implodes, you can start with the previous image and roll forward your changes. That said, projects in general are NOT change sets. They're just collections of classes serialized out as ST source code. These source code files capture the state of the source code within the image, but not the state of the image itself. Done properly, you don't have any aspects of the source code depending on some existing state within the image, but not captured in a class. But, you don't know that for sure. All of the source code relies somewhat on the vast amount of global state within the image. If global variables make you itch, well, let me introduce to you an ST image. Pharo is a fork of Squeak, and it's distributed as an image. Now the Pharo folks have done a lot of VM work, but even in the beginning I imagine that having a chain of custody of source code that converted a stock Squeak image into a nascent Pharo image probably never existed. I bet even with their long github history it would be very difficult to generate later Pharo images from source code checked in to github. The ST image is a ball of clay that the developers add to and cut away from in an ad hoc manner. I'm sure they strive to repeatability and such, but I imagine it's not really a high priority for them when some sneaks into a core developers image (which can be from their work, or changes merged from someone else). Having been raised in a world of "make clean install", where the finished product is a deterministic result of all these pieces I can see and touch, the ST image world has always made me a bit uncomfortable. Obviously the users cope, and it's a "me" thing, but there you are.
sebastianconcpt 4y ago
The way I like to deploy a Smalltalk backend service is when developers have their cloned git repos and follow gitflow, one new directory for a new branch, so they can: 1. Build a local image intended to help with 1 branch (branched out of fresh cloned develop). 2. Add changes, unit and system tests for TDD/regression defense/coverage. 3. Commit and push code to share with the teammates. 4. Open PR to develop when ready/PR's approved 5. Eventually merge develop into master and version bump for release 6. The PRs running CI/CD pipelines with the full battery of tests and 7. The final docker image that devops can consume at will for deployment under their load balancer or whatever architecture they had setup. In this style, images generated by work on bugfix or feature branches are optionally disposable after its PR. The dev can choose to archive or not.

melvinroest 4y ago

I don't know much about deployment. In terms of version control, we use git. I find it a bit tricky though as there's a git repo inside the Pharo image, and then there's the file based git repo and they need to be kept in sync. I've gotten used to that though, but it's not ideal. Every developer has their own image. It's easy to set up an image (though I always need to check the company docs on how to exactly do it), but then you download your own image. These images can be different from each other as well, as only the code checked in to git is the same.

deleted 4y ago

[deleted]

0x445442 4y ago

The image is just an in memory representation of the code. At any point one can export the code representation in the image to an external text file in a number of different formats. These external text files can be version controlled with Git or any other VCS. In turn the the text files can be imported into an image as well. I never worked with Smalltalk professionally but I imagine deployment works in a very similar way to the deployment pipelines you might be used to. Start with a base image, import code pulled from the VCS repo, start the image, run some test verifications and copy the image to its designated virtual insurance host.

codesnik 4y ago
it's not only a code, it's a also current _state_ of the system, no? some kind of root/singleton objects, their instance variables, etc. I mean, for a web application most state should be in a database, but this takes some discipline. And importing updated code to a live system sounds like a black magic. What happens while it's still in progress? Or does one have to start a new process, like we do in other frameworks? Erlang has live updates, but I imagine live update in smalltalk works very differently. So many questions!
- 0x445442 4y ago
  Yeah, the entire state can be saved off. I was just trying to limit the context of the reply to code WRT VCS. > I mean, for a web application most state should be in a database, but this takes some discipline. This state could also reside in an image and Smalltalk has solutions like GemStone and Magma (OODBMS) solutions. > And importing updated code to a live system sounds like a black magic. Yeah, I don't think for most use cases this would be done. A new image would be built and deployed with the relevant code changes applied.
- folmar 4y ago
  The short answer is: just try it, you are in for a lot of fun and puzzles. If you have Windows nearby I would recommend Dolphin Smalltalk due to a great system browser. > it's not only a code, it's a also current _state_ of the system There is no difference in Smalltalk. The code includes all the created instances with current field values. > updated code to a live system From the user point of view everything is simple, yet the simplicity is the advantage of the compiler, not the user. If you update the code the instances that you upgrade run the new code, and if you don't upgrade the old objects they run the old code.
whartung 4y ago
Typically, a ST image is a combination of the base image, and the change set applied to the image. The change set can be code loaded in from an external source, or someone hacking in the system. By default, all changes made to an image are serialized to a changes file. That way, if your image implodes, you can start with the previous image and roll forward your changes. That said, projects in general are NOT change sets. They're just collections of classes serialized out as ST source code. These source code files capture the state of the source code within the image, but not the state of the image itself. Done properly, you don't have any aspects of the source code depending on some existing state within the image, but not captured in a class. But, you don't know that for sure. All of the source code relies somewhat on the vast amount of global state within the image. If global variables make you itch, well, let me introduce to you an ST image. Pharo is a fork of Squeak, and it's distributed as an image. Now the Pharo folks have done a lot of VM work, but even in the beginning I imagine that having a chain of custody of source code that converted a stock Squeak image into a nascent Pharo image probably never existed. I bet even with their long github history it would be very difficult to generate later Pharo images from source code checked in to github. The ST image is a ball of clay that the developers add to and cut away from in an ad hoc manner. I'm sure they strive to repeatability and such, but I imagine it's not really a high priority for them when some sneaks into a core developers image (which can be from their work, or changes merged from someone else). Having been raised in a world of "make clean install", where the finished product is a deterministic result of all these pieces I can see and touch, the ST image world has always made me a bit uncomfortable. Obviously the users cope, and it's a "me" thing, but there you are.

sebastianconcpt 4y ago

The way I like to deploy a Smalltalk backend service is when developers have their cloned git repos and follow gitflow, one new directory for a new branch, so they can: 1. Build a local image intended to help with 1 branch (branched out of fresh cloned develop). 2. Add changes, unit and system tests for TDD/regression defense/coverage. 3. Commit and push code to share with the teammates. 4. Open PR to develop when ready/PR's approved 5. Eventually merge develop into master and version bump for release 6. The PRs running CI/CD pipelines with the full battery of tests and 7. The final docker image that devops can consume at will for deployment under their load balancer or whatever architecture they had setup. In this style, images generated by work on bugfix or feature branches are optionally disposable after its PR. The dev can choose to archive or not.