Seaside application deployment/migration/update
Locked
 
|
Hi guys,
I'm about to release my first real world Seaside app but I'm a bit confused. How do you update your code and deal with model changes ? My first guess would be "upload an mcz file in a folder and load it from the image (on a regular basis or by manually triggering an action in the admin section of my web application)." Do you have any other way to do it ? How do handle big changes in your models ? Do you use some sort of migration ? An other problem for me is how do you deal with multiple environments ? I'm used to have a development, a staging and a production environment. In dev for example, I want to use S3 in staging and prod but not in dev. Is there any convention/approach in this field ? I use migrations, Vlad the deployer and Rails.env everyday in ruby/rails and I wonder how to tackle them in Smalltalk/Seaside... Thanks, Francois _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside application deployment/migration/update
|
|
Hi the seaside admistrator app has a tool to upload a mcz with a new version and save the image or you can update a package from a monticello repository via RFB or Screen shot tools.
Whe you talk about change, how long are that changes. ? Is The new model incompatibe with the older.? Remember when you change the class structure, the compiler make the changes for all instances. But that not enogh. You can persist the data in a chunck and recover late. Sorry for my english. Best D. Enviado desde mi BlackBerry® de Claro Argentina -----Original Message----- From: Francois Stephany <[hidden email]> Sender: [hidden email] Date: Tue, 03 May 2011 21:46:02 To: <[hidden email]> Reply-To: Seaside - general discussion <[hidden email]> Subject: [Seaside] Seaside application deployment/migration/update Hi guys, I'm about to release my first real world Seaside app but I'm a bit confused. How do you update your code and deal with model changes ? My first guess would be "upload an mcz file in a folder and load it from the image (on a regular basis or by manually triggering an action in the admin section of my web application)." Do you have any other way to do it ? How do handle big changes in your models ? Do you use some sort of migration ? An other problem for me is how do you deal with multiple environments ? I'm used to have a development, a staging and a production environment. In dev for example, I want to use S3 in staging and prod but not in dev. Is there any convention/approach in this field ? I use migrations, Vlad the deployer and Rails.env everyday in ruby/rails and I wonder how to tackle them in Smalltalk/Seaside... Thanks, Francois _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> Hi the seaside admistrator app has a tool to upload a mcz with a new version and save the image or you can update a package from a monticello repository via RFB or Screen shot tools.
I'm not that found of a GUI tool to administrate a server. Doesnt RFB add too much bloat ? Is there any command line tool to do that ? > Whe you talk about change, how long are that changes. ? Is The new model incompatibe with the older.? > Remember when you change the class structure, the compiler make the changes for all instances. But what happens to your existing data ? I know that I should store data in a separate database but for the sake of simplicity I prefer to keep my objects in the image while there are not too many data (the application I have in mind is pretty simple concerning storage). > But that not enogh. You can persist the data in a chunck and recover late. So basically I could just serialize my data, throw the image and reload the data in a new fresh image ? What do people generally do ? _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside application deployment/migration/update
|
|
In reply to this post by fstephany
Version uploader in tools is probably the easiest way to go. If you change something in your model such as deleting a variable, then that data goes away.. otherwise you can add on all you want.
If you want to make a major change, you would want to merge the data to your new objects somehow. RS Francois Stephany <[hidden email]> wrote: >> Hi the seaside admistrator app has a tool to upload a mcz with a new version and save the image or you can update a package from a monticello repository via RFB or Screen shot tools. > >I'm not that found of a GUI tool to administrate a server. Doesnt RFB >add too much bloat ? > >Is there any command line tool to do that ? > >> Whe you talk about change, how long are that changes. ? Is The new model incompatibe with the older.? >> Remember when you change the class structure, the compiler make the changes for all instances. > >But what happens to your existing data ? I know that I should store data >in a separate database but for the sake of simplicity I prefer to keep >my objects in the image while there are not too many data (the >application I have in mind is pretty simple concerning storage). > >> But that not enogh. You can persist the data in a chunck and recover late. > >So basically I could just serialize my data, throw the image and reload >the data in a new fresh image ? > >What do people generally do ? > >_______________________________________________ >seaside mailing list >[hidden email] >http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
well... I added a button on status app to "upgrade application X" and it upgrades a full metacello configuration :)
Cheers, Esteban El 03/05/2011, a las 8:37p.m., Robert Sirois escribió: > Version uploader in tools is probably the easiest way to go. If you change something in your model such as deleting a variable, then that data goes away.. otherwise you can add on all you want. > > If you want to make a major change, you would want to merge the data to your new objects somehow. > > RS > > Francois Stephany <[hidden email]> wrote: > >>> Hi the seaside admistrator app has a tool to upload a mcz with a new version and save the image or you can update a package from a monticello repository via RFB or Screen shot tools. >> >> I'm not that found of a GUI tool to administrate a server. Doesnt RFB >> add too much bloat ? >> >> Is there any command line tool to do that ? >> >>> Whe you talk about change, how long are that changes. ? Is The new model incompatibe with the older.? >>> Remember when you change the class structure, the compiler make the changes for all instances. >> >> But what happens to your existing data ? I know that I should store data >> in a separate database but for the sake of simplicity I prefer to keep >> my objects in the image while there are not too many data (the >> application I have in mind is pretty simple concerning storage). >> >>> But that not enogh. You can persist the data in a chunck and recover late. >> >> So basically I could just serialize my data, throw the image and reload >> the data in a new fresh image ? >> >> What do people generally do ? >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside application deployment/migration/update
|
|
In reply to this post by fstephany
We did development in a virtual machine that had dns setup to route external services back on itself, for stuff like email etc. With s3, we had it setup under our own domain and mapped over to s3 in production. In development, it just mapped back
to an nginx server that would serve the assets as needed. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside application deployment/migration/update
|
|
In reply to this post by EstebanLM
On 04 May 2011, at 02:10, Esteban Lorenzano wrote: > well... I added a button on status app to "upgrade application X" and it upgrades a full metacello configuration :) Indeed, you can go a long way using just the built in Seaside tools, loading packages, saving images, browsing, debugging, inspecting and changing code, almost like using a regular images, just a bit slower (and remote through a web browser). This is actually quite cool and powerful. Just make sure to set up at least password protection. On the other hand, this really only works for single image deploys. When you go to (stateful) load balancing with multiple images, the best strategy is to automatically build your own images. Then Smalltalk is a again much more similar to traditional environments, you just get your code from Monticello repositories. You will have to do a bit of shell scripting and a bit of unix voodoo. Regards, Sven _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside application deployment/migration/update
|
|
In reply to this post by fstephany
My answer in line,
Best D. On Tue, May 3, 2011 at 7:41 PM, Francois Stephany <[hidden email]> wrote: >> Hi the seaside admistrator app has a tool to upload a mcz with a new >> version and save the image or you can update a package from a monticello >> repository via RFB or Screen shot tools. > > I'm not that found of a GUI tool to administrate a server. Doesnt RFB add > too much bloat ? http://<yoururl>:<yourport>/tools/versionuploader, > > Is there any command line tool to do that ? > depends on your environment, where are seaside running? pharo, squeak, Gemstone, VW, dolphin..? >> Whe you talk about change, how long are that changes. ? Is The new model >> incompatibe with the older.? >> Remember when you change the class structure, the compiler make the >> changes for all instances. > > But what happens to your existing data ? I know that I should store data in > a separate database but for the sake of simplicity I prefer to keep my > objects in the image while there are not too many data (the application I > have in mind is pretty simple concerning storage). > good, when you apply the changes on the image, you changes are applying in all instance of your objects..if that modifications has incompatible changes, (I can guess, change a simple instance by a collection, or some thing like that), may be you needed do a script, to make a intermediate state. and run that script by seaside object inspector, by example. >> But that not enogh. You can persist the data in a chunck and recover late. > > So basically I could just serialize my data, throw the image and reload the > data in a new fresh image ? > Yeap, if you changes are, very large > What do people generally do ? > In my case, when I work with pharo (in most cases), I use the monticello's way. I don't have so much experince in gemstone, but genstome has a object version's system and you need change the instances structure explicitly > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Sven Van Caekenberghe
I'll go with the Seaside tools.
Thanks all for your answers :) > Indeed, you can go a long way using just the built in Seaside tools, loading packages, saving images, browsing, debugging, inspecting and changing code, almost like using a regular images, just a bit slower (and remote through a web browser). This is actually quite cool and powerful. Just make sure to set up at least password protection. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
Hi Francois,
As you mentioned S3, you might like to investigate #resourceUrl: and the "Resource Base Url" setting in the /config app see: http://book.seaside.st/book/in-action/serving-files/images
WAExternalFileLibrary - is also really useful during development when you're working through multiple iterations of external style sheets and image file. I run Pharo on my Amazon EC2 instances and use X11 forwarding through SSH so I don't have to install a complete graphical environment on my server, yet achieve acceptable performance when administering a remote image.
See Ramon's blog entry: http://onsmalltalk.com/2010-10-23-faster-remote-gemstone (Ubuntu), and http://nickager.com/blog/Installing-Gemstone-on-an-Amazon-EC2-Linux-instance/ (for Amazon EC2 Linux based image - scroll to "Configuring GemTools").
Note both these blog entries discuss Gemtools and Gemstone, but should work equally well for a recent Pharo installation. Nick _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside application deployment/migration/update
|
|
In reply to this post by fstephany
Francois wrote:
>How do you update your code and deal with model changes ? We develop in Pharo and run production in Gemstone. We started just scp-ing the monticello files and use Gemtools over remote X on ssh. Some model changes need migration scripts, but automigrate is enough about 70% of the iterations. We then moved to a combination of puppet (no server) and git, bash scripts, monticello files, gofer, and topaz scripts. Some patches we do directly with Gemtools. We are now moving to jenkins, vagrant and chef. Stephan _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
On May 4, 2011, at 2:12 PM, Stephan Eggermont wrote:
> Francois wrote: >> How do you update your code and deal with model changes ? > > We develop in Pharo and run production in Gemstone. > > We started just scp-ing the monticello files and use Gemtools over > remote X on ssh. Some model changes need migration scripts, > but automigrate is enough about 70% of the iterations. > > We then moved to a combination of puppet (no server) and git, > bash scripts, monticello files, gofer, and topaz scripts. Some patches > we do directly with Gemtools. > > We are now moving to jenkins, vagrant and chef. What do those migration scripts look like? When do you run them in the deploy process? When do you write the migration scripts? How do you test them? Cheers, Pat _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Stephan Eggermont-3
Hi Stephen,
I'm very interested in scripting my Gemstone EC2 configuration - see http://nickager.com/blog/Installing-Gemstone-on-an-Amazon-EC2-Linux-instance/
It looks like that is something that could be scripted with chef http://www.opscode.com/chef/ In case you're doing something similar I'd be very interested in collaborating.
Nick _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |