go into production to do list

Hi,

my project will soon reach a point to go into production for a beta user group, yeah:-)
I dont want to forget anything to do for deployment.
Is there an actual list anywhere?

I think the information at this page
http://www.seaside.st/documentation/faq/deployment-and-maintenance
is outdated.

I dont have the following messages in my image:
WADispatcher>>trimForDeployment
>>isDeployed

The old Book informaton is outdated
WAGlobalConfiguration setDeploymentMode
WAGlobalConfiguration setDevelopmentMode
http://www.pharobyexample.org/versions/PBE1-2009-10-28.pdf

And the new Book can not be downloaded (the links do not work):
http://rmod.lille.inria.fr/pbe2/#

Ok, all I need is a list of things to do when I want to go into production.

I should not be the only person looking for this ;-)

Sabine

Sabine Knöfel wrote

Ok, all I need is a list of things to do when I want to go into production.

I should not be the only person looking for this ;-)

No, you are not!

Did you see: http://book.seaside.st/book/advanced/deployment/deployment-preparing

WAAdmin applicationDefaults
    removeParent: WADevelopmentConfiguration instance

does work - but is buggy. Have a look at:

http://stackoverflow.com/questions/13075919/correctly-removing-development-toolbar-in-seaside,
http://stackoverflow.com/questions/17288227/seaside-with-pharo-2-0-3-0-how-to-set-deployment-mode
and at:
http://code.google.com/p/seaside/issues/detail?id=746

I had to play a lot with the webinterface to set everything right.

Also a bit outdated, but still interesting, the Seaside deployment description on Linode:
https://library.linode.com/frameworks/seaside

If you find more answers, i would definitively like to read about it :)

Sabine Knöfel wrote

Ok, all I need is a list of things to do when I want to go into production.

I should not be the only person looking for this ;-)

No, you are not!

Did you see: http://book.seaside.st/book/advanced/deployment/deployment-preparing

WAAdmin applicationDefaults
    removeParent: WADevelopmentConfiguration instance

does work - but is buggy. Have a look at:

http://stackoverflow.com/questions/13075919/correctly-removing-development-toolbar-in-seaside,
http://stackoverflow.com/questions/17288227/seaside-with-pharo-2-0-3-0-how-to-set-deployment-mode
and at:
http://code.google.com/p/seaside/issues/detail?id=746

I had to play a lot with the webinterface to set everything right.

Also a bit outdated, but still interesting, the Seaside deployment description on Linode:
https://library.linode.com/frameworks/seaside

If you find more answers, i would definitively like to read about it :)

Sabine Knöfel wrote

Which image do you use as base image for deployment?
Loading all my code/prereqs from a new image takes about 2 hours!

My deployed Seaside application runs still Pharo 1.4 Summer Edition.
And yes, i also feel loading all the code takes too long. But it got faster recently in 2.0.
You probably also know the readymade and sometimes broken Seaside jobs on the Pharo contributions Jenkins Server? https://ci.inria.fr/pharo-contribution/

I would also be interested reading how the deployment process is for projects like Smalltalkhub or commercial Seaside applications.

Am 02.09.13 14:44, schrieb Sabine Knöfel:
>
> At
> http://book.seaside.st/book/advanced/deployment/deployment-preparing some
> points are outdated, e.g .the links to the core or kernel images.
> Which image do you use as base image for deployment?
> Loading all my code/prereqs from a new image takes about 2 hours!
Hmm. Are you updating your base components (I mean Seaside, dev tools of
all kinds, DB access layer, Zinc) frequently?
I guess you're not if you want to make progress in your own code base
instead of hunt for bugs every time you set up a new image.

I use VAST and there you always have your local Repository (or maybe on
the lan), so loading a few frameworks can take up to a few minutes, but
never such a long time as you mention.

I guess what I'd do is to make a base image with all components I need
from the web and store it as my starting point. My own code would not be
in there, because that is what changes most. This image file would
either be kept in a read-only directory or under source control. This is
to avoid things like saving a modified version of it by accident.

Whenever I need a new image, I'd use that "base image" and load my own
stuff from my local Monticello into it.
I even do that in VAST to save those 8 minutes every morning.
I think that is the best thing to do in order to keep a stable base.
Of course you should go through the trouble of spending these 2 hours
from time to time to make sure you can still start from scratch if
something's wrong.

Still I am glad I have envy, because it can tell me instantaneously if
an image contains changes from a base version. VAST and envy are a great
team for config management and for detection of changes. (Although its
diff tools for resolving conflicts and such are ... well, dated).

Another possibility would be to clone all the code you need locally and
write your own ConfigurationOf.. and stuff. I know much too little about
these to make an informed comment, but my stomach says that is not a
good idea and your time can be spent for more important stuff.

Just my opinion

Joachim

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> I use VAST and there you always have your local Repository (or maybe
> on the lan), so loading a few frameworks can take up to a few minutes,
> but never such a long time as you mention.
>
> I guess what I'd do is to make a base image with all components I need
> from the web and store it as my starting point.

Sorry, I didn't really answer your question, because you wanted to know
which image to start with.

So here's my (old-fashioned) take:
I would always use the official image from Pharo-project.org. This is
because it is the most likely image to be available whenever you need to
build a fresh one. If you use somebody's preconfigured image, you never
know what they actually did to make it. If they can offer a procedure
that reliably recreates their image, then this is fine.

That is why I always roll my eyes if somebody offers me a ready-made
image with whatever in it. I don't want to be relying on something that
I cannot recreate in a catastrophic case. If I keep a copy of the image
in the Pharo distribution and keep records of what I have to do to load
my stuff and get it running, that is the most reliable strategy, IMO.
Or, even better, if I have a piece of code that does all the nasty work
for me.


Just my 2 cents

Joachim

--
-- 
----------------------------------------------------------------------- 
Objektfabrik Joachim Tuchel          mailto:[hidden email] 
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg     http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 02 Sep 2013, at 20:47, MartinW <[hidden email]> wrote:

> Sabine Knöfel wrote
>> Which image do you use as base image for deployment?
>> Loading all my code/prereqs from a new image takes about 2 hours!
>
> My deployed Seaside application runs still Pharo 1.4 Summer Edition.
> And yes, i also feel loading all the code takes too long. But it got faster
> recently in 2.0.

Yes, the latest 2.0 has got the code loading speedup from 3.0, it makes a huge difference.

Also note that you do not have to start from scratch each time !

Ideally you would build from a stock image to your custom image using one master metacello config. Later on, you can just take that image and reload the config, which will only load changed code. This scenario makes even more difference in day to day practice.

Sven_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside