← Back to team overview

openerp-community team mailing list archive

Re: Deployment best practices

 

hello all,

a deployment issue I have with the Anybox recipe is that if you target HEAD
or say last:1 on bzr branches, the recipe will try to grab the last
available revisions. But it won't freeze anywhere the versions being
actually deployed. So if in an other environment you want to replicate the
environment or if you want to roll back a deployment it falls short.
I may be wrong but I think the same issue happens with the eggs you don't
specify the version. I mean it's cool to let the door open to the newest
things. But once it's actually deployed you make like to know what exactly
has been deployed for reference.

What is the idea? never say last:1 / HEAD and always specify revisions to
deploy? That sounds possible, but is it ideal?

An alternative could be that when the recipe is "converged" to the desired
state, it could produce some kind of buildout.lock file where exact
revision converged would be kept under revision control.
Several packages management have a similar strategy, like:
Gemfile/Gemfile.lock for bundler, Berksfile/Berksfile.lock for Berkshelf
and it's extremely efficient.
Is there such a concept with Buildout? How?

BTW,

After I contributed a generic bzr provider for Chef
https://github.com/akretion/ak-bzr (yes that was before the surprise git
migration but will certainly be useful for v7 still).
and after I generalized a config parser so it can now parse buildout
configurations https://github.com/akretion/configparser
my idea is to advance our ak-openerp-base Chef recipe
https://github.com/akretion/ak-openerp-base so I will create e new OpenERP
env provider that will be able to take a buildout.cfg build specification
as an input and converge it but using Chef tools inside the Chef (solo or
server) environment instead of Buildout (so you don't give up on Chef
tooling in the context of Chef as you would be delegating the installation
to Buildout). It will use virtualenv but only optionally.
So I'm actually interested in knowing what is the idea to pin the exact
branch revisions and module versions with buildout.cfg

Any help is welcome.


Regards.





On Fri, May 23, 2014 at 9:05 AM, Yannick Vaucher <
yannick.vaucher@xxxxxxxxxxxxxx> wrote:

> Maybe you want to take a look at for instance deployement:
>
> https://pypi.python.org/pypi/anybox.recipe.openerp
>
> Cheers,
>
>
> On Fri, May 23, 2014 at 1:46 PM, Phui Hock <phuihock@xxxxxxxxxxxx> wrote:
>
>> Hello all,
>>
>> OpenERP doesn't advocate any standard steps to deploy a new or update an
>> existing instance. I draw much of the inspiration from pip and use fabric.
>>
>> 1. "freeze" modules (create a installed.txt) for modules that are
>> currently installed
>> 2. update ir_module_module table and set installable = False for other
>> modules
>> 3. pack the modules into a distribution zip
>> 4. commit installed.txt and tag project
>>
>> I am not sure if this is the best way. Any other strategies that you may
>> have developed over the years that you can share?
>>
>> Chang Phui Hock
>> CODEKAKI SYSTEMS (R49045/14) - A web-dev company
>> Skype: phuihock
>> Website: http://www.codekaki.com
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-community
>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> Yannick Vaucher
> Business Solutions Software Developer
>
> Camptocamp SA
> PSE A, CH-1015 Lausanne
> Phone: +41 21 619 10 30
> Office: +41 21 619 10 10
> http://www.camptocamp.com/
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>
>

Follow ups

References