[otrs] Deploy OTRS configuration from test environment to production environment

[Samuel Diniz Casimiro]

Hi everyone!

 

I’m using OTRS 4.0.11.

 

Because of some company policies, I need to set up to environments, one for testing and another for production (operational).

 

The problem is: How to export the required configuration data from test env. and deploy it into production env?

 

I know I could copy and paste the ZZZAuto.pm file, but is that enough? Is there any database configuration data I should also take care? If so, how?

 

I know I could use the provided backup.pl script, but I don’t want to backup/restore all the data, only the configuration data. Is there any way to do so?

 

Thanks in advance,

 

Samuel

[Leonardo Certuche]

Hello,

The way we have done that before is:

on app:

tar --exclude=var/article --exclude=var/tmp -cvpzf ../otrs_app.tar.gz *

on db:

mysqldump -u root -p otrs > otrs_db.sql

And then restore both on your new environment, previous installation of the product so all software requirements are already met.

---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

[Jay]

Have you checked out the /opt/otrs/scripts/backup.pl and /opt/otrs/scripts/restore.pl scripts? These are both described at https://otrs.github.io/doc/manual/admin/stable/en/html/backup-and-restore.html.

When performing restore from the generated backup files, I usually find that it's necessary to drop/create the mysql otrs database. Otherwise, the restore will complain that the database already exists.

On the production environment, generate a backup:

sudo /opt/otrs/scripts/backup.pl -d /path/to/backup/folder

On the test environment:

1. Copy the backup from the production system.

2. Drop/create the otrs database. WARNING: make sure you're on the dev environment.

mysql -e "drop database otrs;"

mysql -e "create database otrs;"

3. Restore the backup.

/opt/otrs/scripts/restore.pl -b /path/to/backup/folder/YYY-MM-DD_hh-mm/ -d /opt/otrs/

4. Verify the DB.

su - otrs -c '$HOME/bin/otrs.CheckDB.pl'

5. Re-configure the otrs cron jobs.

/opt/otrs/bin/Cron.sh restart otrs

6. To disable otrs user cron jobs, for testing or to avoid colliding with an existing production instance, disable the otrs crontab with '/opt/otrs/bin/Cron.sh stop otrs'.

7. Start the Scheduler.

su - otrs -c '$HOME/bin/otrs.Scheduler.pl -a start'

Hope this helps.

Jay

[Jay]

oops.. i missed the last part of your question. sorry.

can u just export/import the configuration directly from the UI?

Jay

[Samuel Diniz Casimiro]

Hi guys,

 

Thank you so much. But I think I wasn't clear enough.

 

Imagine I already have two environments, both operational and identical at time zero: one for testing and one for production.

 

Every time a request for change OTRS configuration arrives (some new configuration, a new dynamic field, a new ACL, new process, everything about configuration etc), I need to implement it, test it and then deploy it to production, like any other application.

 

In other words, I need to export/import all configuration data on a regular basis, but should leave the other production data intact (history of tickets, articles etc...). So drop the database is not an option.

 

Any idea?

 

Thanks

[Alvaro Cordero]

Hello Samuel, 

The best way we've found to that is as follow. 

1. Take into account that you have data tables and config tables. Data tables are the ones you just mentioned and config tables are tables like group, user, role, group-role, and so on. 

2. When you work on development (test) systems, you need to know where the changes are applied so you can move them to the production system when needed. Config is mantained in ZZZAuto files and you can move that from one server to another. 

3. Backup and update individual tables when you need to pass changes (dynamic fields, permissions, groups, roles, etc)

4. Never move or update data tables (ticket, article, faq,dynamic_field_value).

5. Processes, ACLs and stats you can export and import, but need to have config data first (dynamic Fields, Process Configuration)

We have not found a better way of doing so, you just need to be sure your systems are kept syncronized after a pass to production. 

Regards 

---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

--

Alvaro Cordero Retana
Consultor de Tecnologias

Tel: 22585757 ext 123

Email: alv...@gridshield.net