Moving a buildout into production

11 Messages Forum Options Options
Embed this topic
Permalink
afewtips.com
Moving a buildout into production
Reply Threaded MoreMore options
Print post
Permalink
Hi,

I am starting to understand the buildout process and how to develop a site from the generic setup and skeleton.
The part I don't understand is how to take a fully developed site and move it into production.
For example, lets say I go through Martins comprehensive book (great resource) and I decide I want to move the site I developed from my local computer onto a different server intact - just as it sits on my local computer all the products and Archtypes installed and ready. Not have to reinstall anything. How do I do that?
Do I export the state of the site and then import via xml import tool?

Thanks for any help.
Francois Barriere
Re: Moving a buildout into production
Reply Threaded MoreMore options
Print post
Permalink

afewtips.com wrote:
Hi,

I am starting to understand the buildout process and how to develop a site from the generic setup and skeleton.
The part I don't understand is how to take a fully developed site and move it into production.
For example, lets say I go through Martins comprehensive book (great resource) and I decide I want to move the site I developed from my local computer onto a different server intact - just as it sits on my local computer all the products and Archtypes installed and ready. Not have to reinstall anything. How do I do that?
Do I export the state of the site and then import via xml import tool?

Thanks for any help.
I suggest to first install Plone using the installer, on your production server, so you get Python and the necessary eggs compiled and installed on your production server. Then copy your buildout config file. Remove the debug settings or create a modular buildout config file (with a production part and a debug part). Re-run buildout to install the extra products you may need.
Then either import your policy as described in Martin's book or copy over your Data.fs file. Depends on what you have on your development server and what you want to export/import. Copying the whole Data.fs is easier if you have content you have developed on your test machine and you want to move it to your production server.
The policy product is more a way to save the configuration of your Plone development server to re-create a fresh new Plone site with the same settings.

Francois.
afewtips.com
Re: Moving a buildout into production
Reply Threaded MoreMore options
Print post
Permalink
(This post was updated on )
Thanks for the reply -
I was not clear in my question.
I was assuming an existing but EMPTY install on the production server. No content.
My objective is to recreate the sites functionality including skins, css, forms, everything related to the configuration. Without having to redo the buildout and steps I did on the development server.
Do all the work on the development server and once I have everything right on the developement server, transfer the site configuration to the production server in 1 step.

Is that possible?

Maybe a tutorial exists?

Thanks


Francois Barriere wrote:
afewtips.com wrote:
Hi,

I am starting to understand the buildout process and how to develop a site from the generic setup and skeleton.
The part I don't understand is how to take a fully developed site and move it into production.
For example, lets say I go through Martins comprehensive book (great resource) and I decide I want to move the site I developed from my local computer onto a different server intact - just as it sits on my local computer all the products and Archtypes installed and ready. Not have to reinstall anything. How do I do that?
Do I export the state of the site and then import via xml import tool?

Thanks for any help.
I suggest to first install Plone using the installer, on your production server, so you get Python and the necessary eggs compiled and installed on your production server. Then copy your buildout config file. Remove the debug settings or create a modular buildout config file (with a production part and a debug part). Re-run buildout to install the extra products you may need.
Then either import your policy as described in Martin's book or copy over your Data.fs file. Depends on what you have on your development server and what you want to export/import. Copying the whole Data.fs is easier if you have content you have developed on your test machine and you want to move it to your production server.
The policy product is more a way to save the configuration of your Plone development server to re-create a fresh new Plone site with the same settings.

Francois.
afewtips.com
Re: Moving a buildout into production
Reply Threaded MoreMore options
Print post
Permalink
Another part of the question is if I develop a site with a buildout, when I want to apply that configuration to a production server, do I have to use a buildout on the production server?
It's not clear how go between enviornments.
It looks like from the response and some other reading, that recreating the configuration has to be done in steps
and cannot be processed in one step.
One of my concerns is running the buildout on a server and use up too much of the cpu.
Any insights into the way others develop in the real world would be great information.
Thanks

Sergey V.
Re: Moving a buildout into production
Reply Threaded MoreMore options
Print post
Permalink
1. Put your buildout configuration into svn. This actually includes only the root folder, bootstrap.py and buildout.cfg. You will probably need another config which includes settings which are deployment-specific, let's call it deployment.cfg.
2. Check everything out at the server:
   svn co svn://mysvnserver.com/mycoolsite
3. go to the mycoolsite folder and run bootstrap script:
   python bootstrap.py
4. Let buildout to do the rest of the job:
   bin/buildout -c deployment.cfg
5. Start the server:
   bin/instance fg (or bin/instance start)

If you made any ZODB changes at the dev site which you want to transfer to the production, you will need to copy Data.fs too.

The point is - generally you don't need to set up a Zope instance at the server separately, buildout will create it for you. All you need is Python of the right version.

In the future if you need to update your production configuration all you need is

svn up
bin/buildout -c deployment.cfg
bin/instance restart


afewtips.com wrote:
Another part of the question is if I develop a site with a buildout, when I want to apply that configuration to a production server, do I have to use a buildout on the production server?
It's not clear how go between enviornments.
It looks like from the response and some other reading, that recreating the configuration has to be done in steps
and cannot be processed in one step.
afewtips.com
Re: Moving a buildout into production
Reply Threaded MoreMore options
Print post
Permalink
Oh! Very good. I think I understand. It's starting to make sense.
Thanks very much for the reply.



1. Put your buildout configuration into svn. This actually includes only the root folder, bootstrap.py and buildout.cfg. You will probably need another config which includes settings which are deployment-specific, let's call it deployment.cfg.
2. Check everything out at the server:
   svn co svn://mysvnserver.com/mycoolsite
3. go to the mycoolsite folder and run bootstrap script:
   python bootstrap.py
4. Let buildout to do the rest of the job:
   bin/buildout -c deployment.cfg
5. Start the server:
   bin/instance fg (or bin/instance start)

If you made any ZODB changes at the dev site which you want to transfer to the production, you will need to copy Data.fs too.

The point is - generally you don't need to set up a Zope instance at the server separately, buildout will create it for you. All you need is Python of the right version.

In the future if you need to update your production configuration all you need is

svn up
bin/buildout -c deployment.cfg
bin/instance restart


afewtips.com wrote:
Another part of the question is if I develop a site with a buildout, when I want to apply that configuration to a production server, do I have to use a buildout on the production server?
It's not clear how go between enviornments.
It looks like from the response and some other reading, that recreating the configuration has to be done in steps
and cannot be processed in one step.

Markus Bleicher-4
Re: Moving a buildout into production
Reply Threaded MoreMore options
Print post
Permalink
In reply to this post by Sergey V.
Sergey V. wrote:
> 1. Put your buildout configuration into svn. This actually includes only the
> root folder, bootstrap.py and buildout.cfg. You will probably need another
> config which includes settings which are deployment-specific, let's call it
> deployment.cfg.
> 2. Check everything out at the server:
>    svn co svn://mysvnserver.com/mycoolsite
> 3. go to the mycoolsite folder and run bootstrap script:
>    python bootstrap.py
A possible trap: Make sure to use a 2.4 version of python, e.g.
python2.4 bootstrap.py

> 4. Let buildout to do the rest of the job:
>    bin/buildout -c deployment.cfg
> 5. Start the server:
>    bin/instance fg (or bin/instance start)
>
> If you made any ZODB changes at the dev site which you want to transfer to
> the production, you will need to copy Data.fs too.
>
> The point is - generally you don't need to set up a Zope instance at the
> server separately, buildout will create it for you. All you need is Python
> of the right version.
>
> In the future if you need to update your production configuration all you
> need is
>
bin/instance stop

> svn up
> bin/buildout -c deployment.cfg
> bin/instance restart
>
>
>
> afewtips.com wrote:
>> Another part of the question is if I develop a site with a buildout, when
>> I want to apply that configuration to a production server, do I have to
>> use a buildout on the production server?
>> It's not clear how go between enviornments.
>> It looks like from the response and some other reading, that recreating
>> the configuration has to be done in steps
>> and cannot be processed in one step.
>>
>

_______________________________________________
Setup mailing list
Setup@...
http://lists.plone.org/mailman/listinfo/setup
Sergey V.
Re: Moving a buildout into production
Reply Threaded MoreMore options
Print post
Permalink
A possible trap: Make sure to use a 2.4 version of python, e.g.
python2.4 bootstrap.py

Good point!
 

> In the future if you need to update your production configuration all you
> need is
>
bin/instance stop
> svn up
> bin/buildout -c deployment.cfg
> bin/instance restart

What for? If your server runs in production mode it doesn't re-read anything from the disk anyway, so you probably can remove the whole Products directory and it won't notice :) So stopping the server prior to running buildout just increases downtime from a second to several minutes.

_______________________________________________
Setup mailing list
Setup@...
http://lists.plone.org/mailman/listinfo/setup
Maurits van Rees-3
Re: Moving a buildout into production
Reply Threaded MoreMore options
Print post
Permalink
Sergey Volobuev, on 2008-08-26:

>> > In the future if you need to update your production configuration all you
>> > need is
>> >
>> bin/instance stop
>> > svn up
>> > bin/buildout -c deployment.cfg
>> > bin/instance restart
>>
>
> What for? If your server runs in production mode it doesn't re-read anything
> from the disk anyway, so you probably can remove the whole Products
> directory and it won't notice :) So stopping the server prior to running
> buildout just increases downtime from a second to several minutes.

If you run bin/buildout then you run the risk of replacing
bin/instance and parts/instance.  If the instance is still running
while doing this, you end up with a rogue process, preventing you from
restarting the instance.  You can always find it with something like
'ps aux' and kill it of course, but I prefer a more gentle approach.

--
Maurits van Rees | http://maurits.vanrees.org/
            Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]


_______________________________________________
Setup mailing list
Setup@...
http://lists.plone.org/mailman/listinfo/setup
Sergey V.
Re: Moving a buildout into production
Reply Threaded MoreMore options
Print post
Permalink

Maurits van Rees-3 wrote:
If you run bin/buildout then you run the risk of replacing
bin/instance and parts/instance.  If the instance is still running
while doing this, you end up with a rogue process, preventing you from
restarting the instance.  You can always find it with something like
'ps aux' and kill it of course, but I prefer a more gentle approach.
Well, not stopping a server works 9 times out of 10 (or even 99 out of 100, if we take into account that parts/instance is going to be replaced only when a new Zope version comes out and that happens not too often). For minor updates that's quite safe and if you're unlucky killing the rogue process manually may still be faster than waiting for buildout to finish with your server down.

Having a cache in front of Zope may help in this situation of course.
Raphael Ritz
Re: Moving a buildout into production
Reply Threaded MoreMore options
Print post
Permalink
Sergey V. wrote:

>
>
> Maurits van Rees-3 wrote:
>> If you run bin/buildout then you run the risk of replacing
>> bin/instance and parts/instance.  If the instance is still running
>> while doing this, you end up with a rogue process, preventing you from
>> restarting the instance.  You can always find it with something like
>> 'ps aux' and kill it of course, but I prefer a more gentle approach.
>>
>
> Well, not stopping a server works 9 times out of 10 (or even 99 out of 100,
> if we take into account that parts/instance is going to be replaced only
> when a new Zope version comes out and that happens not too often). For minor
> updates that's quite safe and if you're unlucky killing the rogue process
> manually may still be faster than waiting for buildout to finish with your
> server down.

As long as you know what you are doing this is just fine.

Depending on the kind of changes you did it might even be sufficient
to run

   bin/buildout -N ...

aka the 'non-update' or 'non-newest' option. This shouldn't touch your
Zope instance under most circumstances.

Raphael


>
> Having a cache in front of Zope may help in this situation of course.
>



_______________________________________________
Setup mailing list
Setup@...
http://lists.plone.org/mailman/listinfo/setup