The community will be in read-only from Tuesday 11:59pm (PST) to Wednesday 7:30am (PST)
The community will be in read-only from Tuesday 11:59pm (PST) to Wednesday 7:30am (PST)
Service Desk Practitioners Forum
cancel
Showing results for 
Search instead for 
Did you mean: 

SD: Going from development to production

Highlighted
Susana.gi_1
Super Collector

SD: Going from development to production

Hi all,
we have started a SD installation project, so we have a SD system for development, and we are going to install another 2 servers for the production enviroment (configured as "multiple servers").

So we want to migrate configurations from development server to production enviroment, including rules, language translations, etc.

Has anybody any experience about it?
What is the best approach for such a migration?

We're going to continue with this project, so we'll have to go from development to production several times a year.

Thanks and regards,
Susana
6 REPLIES
Mark O'Loughlin
Honored Contributor

Re: SD: Going from development to production

Hi Susana,

you can use ACES to export the configuration changes from develoment to production.

You can use data exchange to export data from development and import it to production
Gyula Matics_1
Honored Contributor

Re: SD: Going from development to production

Before going live, do the development on the production environment.

After that, copy the production database to the development server. Do the deveolpment on the development environment. Copy the changes to the production environment using ACES.

After releases, copy the live server back to the development environment, so that they are in sync.
Marc Hummel
Frequent Visitor

Re: SD: Going from development to production

Another thing you can do is detach t&d DB and attach in prod, this will pull over all rules etc.. as they are stored in the DB, this will pull EVERYTHING over from t&d so make sure you want everything first, ex. you probably dont want the demo DB data, so if that's where you started then go with other suggestions i.e. ACES and DE.
hth
Wounds heel, Pain fades... chix dig scar's, oh and everybody WangChung.
Robert S. Falko
Honored Contributor

Re: SD: Going from development to production

Susana,

We use the same approach as Gyula. However, it is worth emphasizing the importance of ALWAYS using ACES to move changes from Test to Prod. This is the only way you can ensure that the OIDs (the internal primary keys of rows in the DB tables) are correct in both environments.

Here's an illustration of the principle. You create a custom field in Test, then you create the "same" custom field in Prod. They will have different OIDs. If you create, for example, a DB rule in Test and try to use ACES to move it to Prod, it will fail.

So, either you always use ACES, or you will not be able to use it at all for many types of objects.

If you become unsynchronized, copying the database from Prod to Test allows you to become synchronized again so you can use ACES.

-Josh
Robert S. Falko
Honored Contributor

Re: SD: Going from development to production

Susana,

I forgot to mention that changes to labels, translations, etc., cannot be migrated using ACES. OVSD normally comes with the DataExchange configuration files to enable you to move this information. Just remember to define the source (test) database as an OVSD source.

-Josh
Susana.gi_1
Super Collector

Re: SD: Going from development to production

Hi all,
thank you to everybody for your replies.

We've also installed Service Navigator Value Pack on our development server, and we'll install it in our production server.

Is it a problem to use your indications above?

Thanks and regards,
Susana.
//Add this to "OnDomLoad" event