Best practices for a Tryton testing instance

Support System Administrator
1

Hi,

We are gonna to deploy a Tryton testing instance (not demo purpose) for one of our customers and I want to share with you our thoughts about it in order gain some experience, trick… from the community.

Goals

  • Allow customer to introduce data, execute workflows… before production in order to verify the expected results
  • Probe new modules not available in production instance

Features

  • Restore into testing instance db backup from production in order to allow user di testing with his ‘real’ data and use cases
  • Use a fake smtp server in order to evict send nothing to third parties from testing instance
  • Use a distinct theme (css for SAO) in order to allow user distinguish between production and testing instances

Doubts

  • Deploy testing instance in the same machine that production?
  • How to restore data from production to testing?
    • With a cron-like job?
    • Allowing to user to do that?

Thoughts?

off topic PS -> Is it possible in discourse have post in draft mode? (For this post I accidentally published before finish it)

2

Hello,
this is part of my daily deliverables, so I tell you how it is done. It may or may not fit your need.

Yes, this requires test software to be compatible or almost compatible.
One of my customers uses a second service to extract data during night with minimal impact on production performance.

Yes, I do this exactly.

I don’t do this.
I may replace automatically official document templates (invoices and sales) with “test-only” tagged templates. I’m not sure it works if the user has modified templates via the user interface.

Yes I do so, but with a bit thought multi-tenant solution.
Separate linux users with isolated home directories, separate code directories, separate postgresql user … not 100% but accepted by all my customers
The advantage is that final test is performed in the exact same environment than the production server.
Some customers use a capability to copy tested code from test to production for an update.

Customers choose what actions they need. In practice, they use both data replication every night and manual replication from the GUI.
They can replicate production data and also reset a test database from a reference.

Hope this helps.

3

I always try to avoid this practice because:

  • testing users have often more right than on production so they may have access to sensitive information like employees cost value etc.
  • to respect the GDRP, you will need to have the same level of security on the testing server than on production because it will store personal data. So in some way, you need to at least pseudo-anonymize it.
  • the production database can contain credential to production services like for example for Stripe. So there are risks to execute real payment from the testing server.

So for me, it is better that the testing server has its own data set.

We always recommend to use a separate machine because un-tested code may consume all resources and thus block the production.

4

So in this case perhaps would be better to have not a testing instance as a solution to probe new modules not available in production

We think in a distinct css to allow user visually distinguish when he is in a production or testing instance

I take note of the Stripe credentials use case.

Do you think the same if we quit probing new modules as a goal?

5

We do use a real data backup for testing database, but the database is always restored in demanad and using a backup. The propouse of the script is to update the required data form the production database to match the testing requeriments.

Altought the script can be executed on a cron job we normally used it on demand (and not so often), as the user normally want’s to keep the tests that he have done on testing enviroment.

We normally use the same instance but with a separate docker deployment, using a new container for each component of the deployment: database and uwsgi server(s).

We’ve never done this as we use a diferent URL to access the test server. So by having a look at the SAO url or the tryton pofile you can easly distinguish on which environment you may be working one.

Having said that, I’ve seen some companies that change the company name for the testing instance. So it also allows you to distinguish on which server you are working.

6

testing new modules is the main point in having a test instance.

It is sometimes a legal requirement not to be able to generate fake invoices from a test server.

When external interaction configuration is in service config file, it is easy.
When it is in the database, I patch (break) the database upon restoration process.
Problem is to know what to patch.

7

I think so but if to reach that goal it will overhead the process of database restoration maybe it’s loadable to restrict the goals in order to simplify the final solution.

Note that I began separating a demo instance from the testing instance.

What about a final solution where the simplest way to reach the goals consist of:

  • A testing instance to allow user introduce data before go production to allow him get confidence with the system
  • A testing instance to probe new modules not available in production instance
  • A demo instance to show the system (this will not rely on a restoration from database production)

Anyway and a bit off-topic I would share with you that I’m very proud of this community. I feel that share with you that kind of posts is like do it with my teammates. I really feel that sharing that with the community will improve the final implementation.

Thanks to all of you.

8

On my services this is the role of the “training instance”, a third one.
It is managed differently because its code is a copy of production code.
At SISalp, any customer gets 3 instances by default : production, training and test.

Keep any demo far from production. It is a honey pot for the worst of the web.
Mine are managed on separate servers.

1 Like