Hi Florian,

this is actually a very good question :)

I try to answer your questions in order:

Why do I need these 3 instances?

It depends. As a user or administrator of OpenProject you only ever need the production mode. The production mode is optimized for performance and security - this is what every production installation of OpenProject should run on.
If you want to run a command on the command line, you can prepend RAILS_ENV=production to the command to execute it in production mode (otherwise it will be executed in development mode).

The other two modes (development and test) are used for OpenProject development. The development mode is the default mode. It is used to run an OpenProject server with enabled development improvements (live code reloading, disabled caches, more detailed error messages, fake-email-sending, re-generate assets on every request, enabled code debugger, …). It is much slower but we, as a developer, don’t need to restart the server every time we change something, which is really convenient.

We use test mode to run automatic tests on the OpenProject code. This mode is again optimized for performance (so that the tests run fast) but every action is meant not to be persistent (e.g. the test database will be erased every now and then). You can see live test results at our travis-ci page.

The most important fact is, that for every mode OpenProject can use a different database (so that we don’t accidentally destroy production data while we’re testing/developing a feature). This is why you have the different categories in the database.yml file.

Is this part of Ruby or OpenProject?

This is part of Ruby.

What shall I use which instance for?

See 1.
production is used for every real-life installation of OpenProject.
development@/@test is used for developers and test is used to automatically test our code base.

Why does “bundle exec rake db:seed” load different data to dev/test/prod?

The seeding loads default data into the database. We have different requirements for different scenarios:

• In development mode we want to quickly test new features and, therefore, need some test data. It takes much time to create test data by hand, so we generate test data while seeding in development mode.
• In production mode we need some (little) default data too. This is basically the admin account, so that we have something to login into. Apart from that we leave a clean database, so that the user can configure his OpenProject instance. (Some plugins can choose to add more seed data if it makes sense for them).

Why is the performance on production so much better than on development?

The production mode is optimized for performance. It caches html pages and assets (like JavaScript and CSS). Ruby code is only parsed and compiled once, because we can assume that nobody changes the program code on a running system.

The development mode is optimized for .. well .. development. It needs to check for new code, or assets on every request; it provides a lot of functionality to enhance development and is not meant to be performant.

What do I have to consider, when using them?

If you are an OpenProject administrator always use the production mode. Apart from that is helps to know that the development mode is the default mode. This means that

bundle exec rake db:seed

will seed the database in development mode (because no other mode is given) and

RAILS_ENV=production bundle exec rake db:seed

will seed the database in production mode.

Another nice thing to know is that every mode uses it’s own database.

I hope I could answer your questions, if not don’t hesitate to ask again :)

cheers,
tessi

Hey Tessi!

Thank you very much for this very comprehensive answer. It helps a lot to understand the necessity and differences of development, test and production.

best regards,
Florian

Exploring the nuances between development, test, and production environments is crucial for any software project. It's essential to maintain a seamless transition from one stage to another to ensure a robust and reliable final product. While discussing these differences, I came across a valuable resource - https://icoholder.com/en/events. This platform seems like a great addition to any developer's toolkit, providing insights into the latest industry events that can aid in staying updated with the ever-evolving tech landscape. Integrating such resources into our development process not only enhances our knowledge but also fosters a collaborative community. Thanks for sharing this gem!