Install an maintain a Tryton production environnement ?
136 views
Skip to first unread message
Christophe
May 30, 2017, 4:10:58 AM5/30/17
to try...@googlegroups.com
Hello
I begin a small reflection on how best to install and maintain a Tryton
environment in production. This obviously includes the development and testing
environment.
I define the terms a little better so that we all talk about the same thing:
- The production environment: environment where the customer captures the
actual information of the company.
- The development environment: environment where we present the first version
of functional complements requested.
- The test environment: environment where the customer can test and validate
functional complements before putting into production.
Until now I use different Git repositories (I'm more comfortable with Git than
with Mercurial) that I upgraded with our developments and / or with minor
updates from Tryton. The major updates are treated as a new project because it
is necessary to manage the complementary development and the accompaniment of
the users.
Today with technologies like virtual environments in python, pip, etc. I ask
myself questions and I wonder if our practices do not deserve to be improved,
hence this thread of discussion.
How do you respond to these needs?
Thank to your feedback.
Regards
--
Christophe
I begin a small reflection on how best to install and maintain a Tryton
environment in production. This obviously includes the development and testing
environment.
I define the terms a little better so that we all talk about the same thing:
- The production environment: environment where the customer captures the
actual information of the company.
- The development environment: environment where we present the first version
of functional complements requested.
- The test environment: environment where the customer can test and validate
functional complements before putting into production.
Until now I use different Git repositories (I'm more comfortable with Git than
with Mercurial) that I upgraded with our developments and / or with minor
updates from Tryton. The major updates are treated as a new project because it
is necessary to manage the complementary development and the accompaniment of
the users.
Today with technologies like virtual environments in python, pip, etc. I ask
myself questions and I wonder if our practices do not deserve to be improved,
hence this thread of discussion.
How do you respond to these needs?
Thank to your feedback.
Regards
--
Christophe
Dominique Chabord
May 30, 2017, 4:43:47 AM5/30/17
to tryton
2017-05-30 10:10 GMT+02:00 Christophe <c...@adiczion.net>:
>
> Until now I use different Git repositories (I'm more comfortable with Git than
> with Mercurial) that I upgraded with our developments and / or with minor
> updates from Tryton. The major updates are treated as a new project because it
> is necessary to manage the complementary development and the accompaniment of
> the users.
I was convinced by the presentation "why develop on trunk" during the
>
> Until now I use different Git repositories (I'm more comfortable with Git than
> with Mercurial) that I upgraded with our developments and / or with minor
> updates from Tryton. The major updates are treated as a new project because it
> is necessary to manage the complementary development and the accompaniment of
> the users.
last unconference.
Christophe
May 30, 2017, 5:28:12 AM5/30/17
to try...@googlegroups.com
various versions
Regards
--
Christophe
Dominique Chabord
May 30, 2017, 5:53:55 AM5/30/17
to tryton
2017-05-30 11:28 GMT+02:00 Christophe <c...@adiczion.net>:
>
> Yes me too, but now i talking about a production environments that can be in
> various versions
So this is were complexity starts. For me there should not be any
>
> Yes me too, but now i talking about a production environments that can be in
> various versions
development and test of new code on a production environment. Various
versions coexistence should be drastically limited.
On my hosted servers, I enable a "test" service for the users to
evaluate modules for their functionnality separatly from the
production service but not to implement a CI strategy ;-)
I recommand also to use this test service for a final "dry-run" before
reporting code to production service, also to check database update
without sending database outside to unsecured dev PCs.
It may also reveal a dependency problem. If it is a missing
dependency, it is little problem. If it is version dependency conflict
with production, the test session should be stopped.
Some integrators ask me for a "dev", "pre-run", "pre-prod" services.
It fits the early ages of the serveur ie the initial integration
bench, before it goes for production and should not be re-used later
for updates. Usually these integrators are more consultants than
developpers.
my 2cts
Axel Braun
May 30, 2017, 5:58:30 AM5/30/17
to try...@googlegroups.com
production environment. Local extentions can ba applied to a separate RPM and
installed / updated to production once sufficiently tested.
Cheers
Axel
--
Dr.-Ing. Axel K. Braun
M: +49.173.7003.154
T: @coogor
VoIP/Skype: axxite
PGP Fingerprint: 2E7F 3A19 A4A4 844A 3D09 7656 822D EB64 A3BA 290D
Public Key available at http://www.axxite.com/axel....@gmx.de.asc
Personal Freedom needs Free Software
ThinkPad T520 running openSUSE Tumbleweed
Kernel: 4.11.2-1-default
KDE: 5.33.0
Dominique Chabord
May 30, 2017, 6:21:41 AM5/30/17
to tryton
Hi Axel
2017-05-30 12:00 GMT+02:00 Axel Braun <axel....@gmx.de>:
>
> I'm a fan of using packages procided from your distribution for running a
> production environment. Local extentions can ba applied to a separate RPM and
> installed / updated to production once sufficiently tested.
in this case what does your update procedure look like ?
your updated specific RPM depends on the Trytond official packages, then
- stop Trytond
- save databases
- update the code with RPM
- update every database
- restart in production (and cross fingers ?)
my questions are :
- what is the roll-back procedure in case some problems appear at any step ?
- is there a dry-run possibility without stopping production ?
- do you know about real production cases where this kind of update is
proven ? ( gnu-health ?)
regards
2017-05-30 12:00 GMT+02:00 Axel Braun <axel....@gmx.de>:
>
> I'm a fan of using packages procided from your distribution for running a
> production environment. Local extentions can ba applied to a separate RPM and
> installed / updated to production once sufficiently tested.
your updated specific RPM depends on the Trytond official packages, then
- stop Trytond
- save databases
- update the code with RPM
- update every database
- restart in production (and cross fingers ?)
my questions are :
- what is the roll-back procedure in case some problems appear at any step ?
- is there a dry-run possibility without stopping production ?
- do you know about real production cases where this kind of update is
proven ? ( gnu-health ?)
regards
Sergi Almacellas Abellana
May 30, 2017, 7:32:41 AM5/30/17
to try...@googlegroups.com
El 30/05/17 a les 10:10, Christophe ha escrit:
> Hello
>
Hi,
> I begin a small reflection on how best to install and maintain a Tryton
> environment in production.
This will fun, fasten your belts!
This obviously includes the development and testing
> environment.
> I define the terms a little better so that we all talk about the same thing:
>
> - The production environment: environment where the customer captures the
> actual information of the company.
> - The development environment: environment where we present the first version
> of functional complements requested.
> - The test environment: environment where the customer can test and validate
> functional complements before putting into production.
I will probably merge the development and the test environment into a
single one. This simplifies the testing by developers and clients by
using always the same data. You can catch more corner use cases when
testing with real data ;)
I will also try to automate as much as possible the creation of the test
environment. So for me it will be a task to run by cron (each day, each
week, whenever you prefer), that does the following:
1. Restore a backup of the production database
2. Deploy the environment
3. Upgrade the database to match the environment database
4. Run the server.
>
> Until now I use different Git repositories (I'm more comfortable with Git than
> with Mercurial) that I upgraded with our developments and / or with minor
> updates from Tryton.
For me the SCM used is not relevant but what's important is to be able
to get the code of each environment and compare them. Different
techniques are available here, but basically is a matter of using
tags/branches to separate what's run on production to whats run on
development/staging.
The major updates are treated as a new project because it
> is necessary to manage the complementary development and the accompaniment of
> the users.
Development is simplified is you follow trunk, so you only need to
inform the users about new version changes and accompaniment them if
requested. For me this is more like maintenance (and not a new project),
as I think that new version upgrades are included on maintenance of
existing versions.
>
> Today with technologies like virtual environments in python, pip, etc. I ask
> myself questions and I wonder if our practices do not deserve to be improved,
> hence this thread of discussion.
You can also use containers in order to ensure that the same code use
for development is used on staging and production servers without
forcing the developers to have the same environment as your deployment
servers.
--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk
> Hello
>
Hi,
> I begin a small reflection on how best to install and maintain a Tryton
> environment in production.
This obviously includes the development and testing
> environment.
> I define the terms a little better so that we all talk about the same thing:
>
> - The production environment: environment where the customer captures the
> actual information of the company.
> - The development environment: environment where we present the first version
> of functional complements requested.
> - The test environment: environment where the customer can test and validate
> functional complements before putting into production.
single one. This simplifies the testing by developers and clients by
using always the same data. You can catch more corner use cases when
testing with real data ;)
I will also try to automate as much as possible the creation of the test
environment. So for me it will be a task to run by cron (each day, each
week, whenever you prefer), that does the following:
1. Restore a backup of the production database
2. Deploy the environment
3. Upgrade the database to match the environment database
4. Run the server.
>
> Until now I use different Git repositories (I'm more comfortable with Git than
> with Mercurial) that I upgraded with our developments and / or with minor
> updates from Tryton.
to get the code of each environment and compare them. Different
techniques are available here, but basically is a matter of using
tags/branches to separate what's run on production to whats run on
development/staging.
The major updates are treated as a new project because it
> is necessary to manage the complementary development and the accompaniment of
> the users.
inform the users about new version changes and accompaniment them if
requested. For me this is more like maintenance (and not a new project),
as I think that new version upgrades are included on maintenance of
existing versions.
>
> Today with technologies like virtual environments in python, pip, etc. I ask
> myself questions and I wonder if our practices do not deserve to be improved,
> hence this thread of discussion.
for development is used on staging and production servers without
forcing the developers to have the same environment as your deployment
servers.
--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk
Axel Braun
May 30, 2017, 7:34:06 AM5/30/17
to try...@googlegroups.com
Hi Dominique,
Am Dienstag, 30. Mai 2017, 12:21:39 CEST schrieb Dominique Chabord:
> 2017-05-30 12:00 GMT+02:00 Axel Braun <axel....@gmx.de>:
> > I'm a fan of using packages procided from your distribution for running a
> > production environment. Local extentions can ba applied to a separate RPM
> > and installed / updated to production once sufficiently tested.
>
> in this case what does your update procedure look like ?
>
> your updated specific RPM depends on the Trytond official packages, then
> - stop Trytond
> - save databases
> - update the code with RPM
> - update every database
> - restart in production (and cross fingers ?)
If you have an update in a minor release (4.4.0 -> 4.4.1) it is mostly
sufficient to stop the server and start after installing the new RPM. Done that
many times without problems
> my questions are :
> - what is the roll-back procedure in case some problems appear at any step ?
Worst case...boot into the previous snapshot (if you use btrfs)
> - is there a dry-run possibility without stopping production ?
Depends on the system landscape. If you have a 3 tier environment (Devel,
Quality and production) you may copy production to quality first and try the
upgrade in quality. Depending on the amount of extensions you have build
yourself it may not run too smooth....
Then you need to fix your extensions until it works.
To make sure your have transactional correctness an offline upgrade is the only
chance IMHO. Better save than sorry in that case.
> - do you know about real production cases where this kind of update is
> proven ? ( gnu-health ?)
For the dot-upgrades we've done that in a company in Hamburg (unless they went
out of business - not for Tryton reasons).
Cheers
Axel
Am Dienstag, 30. Mai 2017, 12:21:39 CEST schrieb Dominique Chabord:
> 2017-05-30 12:00 GMT+02:00 Axel Braun <axel....@gmx.de>:
> > I'm a fan of using packages procided from your distribution for running a
> > production environment. Local extentions can ba applied to a separate RPM
> > and installed / updated to production once sufficiently tested.
>
> in this case what does your update procedure look like ?
>
> your updated specific RPM depends on the Trytond official packages, then
> - stop Trytond
> - save databases
> - update the code with RPM
> - update every database
> - restart in production (and cross fingers ?)
sufficient to stop the server and start after installing the new RPM. Done that
many times without problems
> my questions are :
> - what is the roll-back procedure in case some problems appear at any step ?
> - is there a dry-run possibility without stopping production ?
Quality and production) you may copy production to quality first and try the
upgrade in quality. Depending on the amount of extensions you have build
yourself it may not run too smooth....
Then you need to fix your extensions until it works.
To make sure your have transactional correctness an offline upgrade is the only
chance IMHO. Better save than sorry in that case.
> - do you know about real production cases where this kind of update is
> proven ? ( gnu-health ?)
out of business - not for Tryton reasons).
Cheers
Axel
Sergi Almacellas Abellana
May 30, 2017, 7:58:15 AM5/30/17
to try...@googlegroups.com
El 30/05/17 a les 11:53, Dominique Chabord ha escrit:
versions to maintain. If you manage the infrastructure, you can limit
the number of supported versions by applying the upgrades to the latest
stable version, so you only support the last one. Here the integrator
decides which level of support wants to give.
> 2017-05-30 11:28 GMT+02:00 Christophe <c...@adiczion.net>:
>
>> Yes me too, but now i talking about a production environments that can be in
>> various versions
> So this is were complexity starts. For me there should not be any
> development and test of new code on a production environment. Various
> versions coexistence should be drastically limited.
The work needed to maintain several versions increases as the number of
>
>> Yes me too, but now i talking about a production environments that can be in
>> various versions
> So this is were complexity starts. For me there should not be any
> development and test of new code on a production environment. Various
> versions coexistence should be drastically limited.
versions to maintain. If you manage the infrastructure, you can limit
the number of supported versions by applying the upgrades to the latest
stable version, so you only support the last one. Here the integrator
decides which level of support wants to give.
Sergi Almacellas Abellana
May 30, 2017, 8:06:35 AM5/30/17
to try...@googlegroups.com
El 30/05/17 a les 12:21, Dominique Chabord ha escrit:
and you have it. If everything does not go well, restore the backup and
use the previous version code.
> - is there a dry-run possibility without stopping production ?
It's possible but when you run the database upgrade you may get blocked
with existing transactions, especially when modifying the structure of a
table used by a lots of users. The procedure will be:
1. Deploy the new version code:
2. Upgrade the database structure while not stopping the previous
server. (Here is when bad things can happen)
3. Stop the old server and start the new one.
> my questions are :
> - what is the roll-back procedure in case some problems appear at any step ?
If you are using a new virtualenv just have a backup of your database
> - what is the roll-back procedure in case some problems appear at any step ?
and you have it. If everything does not go well, restore the backup and
use the previous version code.
> - is there a dry-run possibility without stopping production ?
with existing transactions, especially when modifying the structure of a
table used by a lots of users. The procedure will be:
1. Deploy the new version code:
2. Upgrade the database structure while not stopping the previous
server. (Here is when bad things can happen)
3. Stop the old server and start the new one.
Dominique Chabord
May 30, 2017, 8:20:27 AM5/30/17
to tryton
2017-05-30 14:06 GMT+02:00 Sergi Almacellas Abellana <se...@koolpi.com>:
> El 30/05/17 a les 12:21, Dominique Chabord ha escrit:
>>
>> my questions are :
>> - what is the roll-back procedure in case some problems appear at any step
>> ?
>
>
> If you are using a new virtualenv just have a backup of your database and
> you have it. If everything does not go well, restore the backup and use the
> previous version code.
This was a question to Axel about rpm, at OS level iiuc. Do you know
> El 30/05/17 a les 12:21, Dominique Chabord ha escrit:
>>
>> my questions are :
>> - what is the roll-back procedure in case some problems appear at any step
>> ?
>
>
> If you are using a new virtualenv just have a backup of your database and
> you have it. If everything does not go well, restore the backup and use the
> previous version code.
how to revert a rpm upgrade ?
>
>> - is there a dry-run possibility without stopping production ?
>
>
> It's possible but when you run the database upgrade you may get blocked with
> existing transactions, especially when modifying the structure of a table
> used by a lots of users. The procedure will be:
>
> 1. Deploy the new version code:
> 2. Upgrade the database structure while not stopping the previous server.
> (Here is when bad things can happen)
> 3. Stop the old server and start the new one.
if you use rpm strategy, I think you cannot run two versions on the
>> - is there a dry-run possibility without stopping production ?
>
>
> It's possible but when you run the database upgrade you may get blocked with
> existing transactions, especially when modifying the structure of a table
> used by a lots of users. The procedure will be:
>
> 1. Deploy the new version code:
> 2. Upgrade the database structure while not stopping the previous server.
> (Here is when bad things can happen)
> 3. Stop the old server and start the new one.
same machine. This was the question.
>
I share Axel idea and it would be nice to update Tryton as we update
postgresql, but I think we cannot (yet ?)
Dominique Chabord
May 30, 2017, 8:31:26 AM5/30/17
to tryton
according to dependencies they need.
If a user requires two services at different versions, they will
probably be served by two separate servers.
For what you mention, the Tryton project has a policy and an
integrator may choose to vary. But the more flexible you get, the
better you face unexpected cases.
Cédric Krier
May 30, 2017, 9:55:11 AM5/30/17
to tryton
On 2017-05-30 14:20, Dominique Chabord wrote:
> I share Axel idea and it would be nice to update Tryton as we update
> postgresql, but I think we cannot (yet ?)
But it is the same procedure. Indeed PG is a little bit more complex
> I share Axel idea and it would be nice to update Tryton as we update
> postgresql, but I think we cannot (yet ?)
because pg_upgrade needs the previous binary to run.
--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/
Christophe
Jun 1, 2017, 2:36:31 AM6/1/17
to try...@googlegroups.com
Le mardi 30 mai 2017, 13:32:38 Sergi Almacellas Abellana a écrit :
> [...]
Thank you for your answers, but I think I have mispronounced the reflection I
wanted to engage, I was not looking for advice on existing possibilities but
rather an exchange about the methods you use in production on your servers or
on your clients servers to install, maintain these environments up to date and
integrate new functional add-ins.
Regards
--
Christophe
> [...]
Thank you for your answers, but I think I have mispronounced the reflection I
wanted to engage, I was not looking for advice on existing possibilities but
rather an exchange about the methods you use in production on your servers or
on your clients servers to install, maintain these environments up to date and
integrate new functional add-ins.
Regards
--
Christophe
Axel Braun
Jun 2, 2017, 5:41:49 AM6/2/17
to try...@googlegroups.com
Am Dienstag, 30. Mai 2017, 14:20:25 CEST schrieb Dominique Chabord:
> 2017-05-30 14:06 GMT+02:00 Sergi Almacellas Abellana <se...@koolpi.com>:
> > El 30/05/17 a les 12:21, Dominique Chabord ha escrit:
> >> my questions are :
> >> - what is the roll-back procedure in case some problems appear at any
> >> step
> >> ?
> >
> > If you are using a new virtualenv just have a backup of your database and
> > you have it. If everything does not go well, restore the backup and use
> > the
> > previous version code.
>
> This was a question to Axel about rpm, at OS level iiuc. Do you know
> how to revert a rpm upgrade ?
Just a reversal of a RPM should not be an issue:
> 2017-05-30 14:06 GMT+02:00 Sergi Almacellas Abellana <se...@koolpi.com>:
> > El 30/05/17 a les 12:21, Dominique Chabord ha escrit:
> >> my questions are :
> >> - what is the roll-back procedure in case some problems appear at any
> >> step
> >> ?
> >
> > If you are using a new virtualenv just have a backup of your database and
> > you have it. If everything does not go well, restore the backup and use
> > the
> > previous version code.
>
> This was a question to Axel about rpm, at OS level iiuc. Do you know
> how to revert a rpm upgrade ?
% zypper se -s pkg
will give you the list of versions that zypper knows about (has a cached
version of / can see in your repos). You can then forcefully install
(downgrade) pkg to pkg-1.2.3 with:
% zypper in --oldpackage pkg-1.2.3
You should get a warning about a downgrade. I'm not actually sure if this
will downgrade libraries (if necessary) but I would hope it does (since zypper
would see it as a reinstall with different Requires).
Question is what other adaptions are being made (e.g. changes to the
database). So the real safe way is to use a previous snapshot to go back to
start....
> > 1. Deploy the new version code:
> > 2. Upgrade the database structure while not stopping the previous server.
> > (Here is when bad things can happen)
> > 3. Stop the old server and start the new one.
>
> if you use rpm strategy, I think you cannot run two versions on the
> same machine. This was the question.
>
>
> I share Axel idea and it would be nice to update Tryton as we update
> postgresql, but I think we cannot (yet ?)
activities can not be avoided I think.
Cheers
Axel
Dominique Chabord
Jun 2, 2017, 8:19:45 AM6/2/17
to tryton
2017-06-02 11:36 GMT+02:00 Axel Braun <axel....@gmx.de>:
>>
>> I share Axel idea and it would be nice to update Tryton as we update
>> postgresql, but I think we cannot (yet ?)
>
> You mean from packages? Not sure what should stop us..... although some manual
> activities can not be avoided I think.
Which what makes all difference.
>>
>> I share Axel idea and it would be nice to update Tryton as we update
>> postgresql, but I think we cannot (yet ?)
>
> You mean from packages? Not sure what should stop us..... although some manual
> activities can not be avoided I think.
;-)
Reply all
Reply to author
Forward
0 new messages