Service Desk Practitioners Forum

Easy way to implement changes from development to production SD 4.5

Go to solution
Rob Jans
Trusted Contributor.

Easy way to implement changes from development to production SD 4.5


I'm looking for an easy-to-read document to go from a development environment to a production environment.
I'm using SD 4.5 SP14.
There have been created a number of changes in Business logica/forms/templates/Roles.

I was thinking about using aces, but have some issues with that.. (lack of knowledga??)

It is not clear for me to understand the total difference between production and development env.

Please help.

Cheers Rob
If you think education is expensive, try ignorance
Outstanding Contributor.

Re: Easy way to implement changes from development to production SD 4.5

Hi Rob,

for me the best way to do it is definitively through ACES. For Each Item and element create an ACES.
e.g.: DBRules you created bellonging to Service Calls.
New Codes you implemented for Service Calls.
Then Put them on a ACES Group. That will contain the release name for example.

In the Administrator console use Menu: File > ACES > Export ACES and this will generate an XML file containing your developments.

Share the file between Devlopment and Produciton environment. Connect to Production, open Administrator Console; Menu: File>ACES>Import Aces. Import the XML file you extracted before. Check the overwrite option if needed and that's it!


NB: Keep your XML file for History/Archiving purpose!

Hope this helps,
Vasily Kamenev
Acclaimed Contributor.

Re: Easy way to implement changes from development to production SD 4.5

I use ACES too, not see any other way.

Robert S. Falko
Acclaimed Contributor.

Re: Easy way to implement changes from development to production SD 4.5


We have 4 environments:
1) a play environment:
Here we try out wild ideas, and we try out upgrades.
2) a test environment
Here we implement the changes as per the RfCs that we receive. We perform unit testing, some integration testing here. When the OVSD administrator is satisfied with the change, it is transferred to the quality assurance environment via ACES.
3) a quality assurance environment
Here the end users to User Acceptance testing. This environment more or less resembles the production environment in terms of hardware architecture and transactional data. When the users accept a change, it is transferred via ACES to the Production environment.
4) a production environment

A few reasons why ACES is a good way to go, and a few caveats.

Why use ACES?
1) ACES ensures that the change you have made in Test and authorized in Quality is exactly what is made in Prod.

2)Sometimes, changes are complicated or are voluminous. It is easier and faster to use ACES to recreate them in Prod, then to retype them all.

3) ACES preserves the OIDs of your objects from one environment to another. This means, for example, that you can use ACES to transfer a set of category values, and then you can use ACES to transfer rules or other configurations that reference those category values. For this reason, you probably cannot use ACES sometimes, and other times do it manually.

Of what should you be aware?
1) Certain items cannot be transferred using aces, such as generic relations and data that is rather transferred using Data Exchange.

2) Certain items transferred with ACES reference items transferred with Data Exchange. Since Data Exchange does not preserve OIDs, this means the ACES-transferred items will not work. An example would be a checklist that references a Service. In fact, the checklist references the OID of the service, but since Data exchange does not recreate identical OIDs, the service in the target database will not be recognized by the transferred checklist.

3) You often need to transfer information that has circular references - for example, a change template together with its work order templates and work order predecessor templates. You can transfer this with ACES, but you may be required to do the transfer several times, as the first time you will see error messages - which is normal.

4) Sometimes, ACES does not work, even though it should. When this happens, I bite the bullet and do the work manually. But I always make amends by...

5) It is good practice to periodically make sure that your instances are synchronized. We do this by copying the production database onto the quality and then the test database. If you do this, you need to pay attention to potential security and capacity issues.

6) Either try to do periodic releases, or try to work on only one change at time. If you work on a lot of different changes at the same time, without implementing any in production, you risk having conflicts - especially in the roles, and you risk transferring into production changes that are not yet tested. This is because the granularity of ACES is low for certain items, like custom fields.

Good luck,