[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Health-dev] DevOps

From: Marc Murray
Subject: Re: [Health-dev] DevOps
Date: Tue, 05 Apr 2016 18:18:20 -0500

Hi Carlos and Everyone,

In my work, I have to manage (now) 6 production instances of GNU Health and 4 demo/test instances. All this is happening while we're still doing development on new modules and doing maintenance and bug-fixes on the stuff that's in production. The best part is, we have an EXTREMELY small team handling the technical details (installation, backup, upgrade etc).

While all this is happening, we have other stakeholders making plans to roll out new instances in other locations and those new instances need to be managed and updated like all the others.

This is how we do it:
Backups are done using rsync and barman[2].

So, while I've never used Vagrant, I can understand your desire to have "infrastructure as code". What I have laid out above, if you follow our use of pip, you should be able to reliably control updates to specific modules from within your vagrant scripts.

The reasoning behind using different virtualenv for different version, is to allow for an easy rollback if the upgrade fails at the database upgrade stage. If that happens, we restore the database that was backed-up before upgrade and just start trytond from the old virtualenv while we go off to figure out the issue on a non-production machine. This way, we have had very little down-time.

I hope this helps.

[1] Our internal PyPI server is an installation of localshop -
[2] Barman is an awesome tool for postgresql backups -


On Tue, 2016-04-05 at 15:17 -0500, Carlos Eduardo Sotelo Pinto wrote:

I am looking something liek that, I was to having the whole deployment [ install / upgrade / upgrade ] on code using a bos like vagrant or docker in order on havin continue sintegration and continues delivery

I have an script for tryton working on that using vagrant, and any change done is no possible to keep it as part of the process without edit the deployment scripts

Best regards

2016-04-05 14:27 GMT-05:00 Axel Braun <address@hidden>:

Am Dienstag, 5. April 2016, 13:59:56 schrieb Carlos Eduardo Sotelo Pinto:
> Yes, you are right, however it is far from having "Infraestructure as
> code", what I mean is having health on a way on working as Continues
> Delivery and Continues Integration, considering that implementing ERP
> requires more than just install

Definitely, continuous adaption is part of this.

I used to run a productive Tryton environment, and my target was always to
have as least as possible administrative effort.
So for the Tryon system we used packages from OBS (

The enhancements were implemented as separate package, build as well on OBS,
but without disclosing it to public.

Both are installed with system package management. Updates on base package
automatically trigger a rebuild of depending packages, so the whole
environment is always up to date, with minimal effort.

Just as additional thought

Carlos Eduardo Sotelo Pinto
    Senior Software Analyst Developer
    Claro RPC +51983265994 | MOV RPM( # ) +51 966110066
    GTalk: address@hidden | Skype: csotelop
    GNULinux RU #379182 | GNULinux RM #277661

No availability between 08:30 and 18:00, I will answer as soon as posible

Please consider the environment before printing this email
Join the campaign at

reply via email to

[Prev in Thread] Current Thread [Next in Thread]