DevOps best practices in Saviynt

[Asha]

hi,

   I would like to know what DevOps best practices can be used when working with Saviynt.   

    I understand Saviynt has the 'Transport' functionality to migrate objects from one environment to another. However this feature doesnt include some critical objects like Endpoints, Entitlement Type, Dynamic Attributes, Jobs, Settings, Identity Access Rules (Technical, Business, etc). Hence these objects need to be manually created/modified in the higher environments. Any manual configurations could lead to errors. 

   It would be helpful if you can share any best practices used in migrating objects from DEV to higher environments. Also for the objects that Saviynt Transport utility supports, do you also use any repository like gitHub to saved the exported configurations in order to maintain any baseline configurations? 

Really appreciate if you can share any best practices regarding the above.   

[Srinivas]

Hello @Asha 

Have you referred our transport packages documents.

https://saviynt.freshdesk.com/support/solutions/articles/43000618939-transporting-packages

https://saviynt.freshdesk.com/support/solutions/articles/43000556361-application-onboarding

[rushikeshvartak]

If you have to migrate application use application onboarding feature and if you have to use global configuration use transport feature ( sav role , workflow etc)

[Asha]

Thanks for the response. I'm aware of the Transport utility.. But will check on Application onboarding as well. But I have the below concern with the Transport utility. 

1. For the first time a feature is migrated from the lower environment to higher environment, this utility is used to create an export package and then import it in the higher environment. 

2. Post the first migration if anyone is testing or trying out for something, they could edit the existing configurations and would not have reverted the changes. And if one another person is performing changes to the same object, they wouldnt know these changes and could start working on the modified object and this could then get migrated to higher environments with some valid changes and also unwanted changes. In order to avoid, wouldnt it be better to maintain the baseline configurations in some repository like Github and for any legitimate changes use the configs from the repository to apply fresh in the lower environment and then start applying those legitimate changes and rebaseline those objects again in the repository. 

Have you done anything like above to maintain a baseline version of the configurations? 

[rushikeshvartak]

#1 - You can also do transfer online instead of download & reuploading it again

#2 - This will be best practice should be followed by orgs for client that whichever working version of code should be maintained. you can always export always working version