Redmine

If you trust developers with passwords to repositories (I use read only accounts to repositories from redmine) :

1) setup a cron job that dumps production into dev environment

The idea behind this is to ensure that what you develop is quite close to what you see in production. Caveat: always ensure and double check that what you are about to do is on your devsite, as mistaking a dev vs prod is easy. Best: use alternate theme for dev site, so less confusion.

• mysqldump proddb > proddb.sql
• cat proddb.sql | mysql devdb

2) migrate restored schema to dev redmine settings (rake migrate?)

• rake db:migrate RAILS_ENV="dev"

this will update schema diffs between your prod (older schema, newest data), to what is required by the dev. Now oyu will have newest data + newest schema.

3) dev more

now you can do more of dev

your testing environment will be similiar, except, less cron job, and more controlled about db/file changes.

cheerios

Thanks Zarooba.

I don´t realy see the point of a cron job, anyway it can be usefull. Using diferent themes is usufull, and I´m already doing so.

Maybe I don´t understand very much how exactly the RAKE MIGRATE works.

The point is, I don´t see diferent files for each environment in directories, so don´t know the moment I modify something, how to replicate that into another environment. For example, plugins should be placed on </redmine>/vendor/plugins/, but how do I tell for which environment it is for so that it is developed/tested without afecting each other or even production. Same if modifying other files, code, options.

From the begining, the idea is to have 3 diferent environments dev,test,prd all the same.

Over time, the idea is to develop/change/install/etc only on dev, then replicate in test, and then to prd. Is this the intention of the environments ? How do I configure/intall redmine to work this way ?

Thanks,

well, no

Redmine built in environments are to run same code with different dbs. This is good for two types of scenarios:

• perform tests on same code as prod, but with different database.
• run multiple prod environments (one code base, but different dbs). say, you got 10 independent dev teams, and each dev team manages 10 projects

I you want to run different codebases then you need separate redmine directories (someone please correct me). Rake migrate is designed to help you migrate the schema. My example was more to deal with upgrading Redmine. Say, you are running 0.7.3 in prod. You want to test 0.8.3. First you will backup prod. Then restore it onto your test db. Then you will run rake-migrate to upgrade db schema from 0.7.3 to 0.8.3, then you will run redmine 0.8.3 pointed to your test db.

Notice: here you have different redmine code base, each pointing to different db.

cheerios

As far as I understand, what you´re saying is quite the same. If it´s another version, it´s similar to changing the code/installing new plugins/etc my self. New versions surely include this kind of things.

You mean that in this scenario, I should install redmine in a new directory ?

Eg: I´m running 0.7.3, need to migrate to 0.8.3, I will install 0.8.3 in another directory, copy the DB, rake-migrate to upgrade db schema.

I thought of this scenario, but thought that environments have other improved functionality. The idea was to perform tests on different code as prd, so prd didn´t get affected by any changes not fully tested. And one´s ready, replicate changes.

I think I should try with diferent installations.

Thanks