• State Not Answered
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 139 views
  • Users 0 members are here
Options
Related

Different methods to handling development contention?

Ben

This really is a broader question as I'm interested how people are handling development contention.

We have several developers all being tasked with building new initiatives as well as trying to handle all the work related to portal migration (old => Angular). This is also deployed up 4 environments with strict controls over code promotion.

Because so many things are being touched, and client priorities keep changing, there are often instances where different developers need to alter the same object in different ways. This in turn can quickly lead to transporting issues and possible code reversion.

For us, I don't see it as realistic to be trying to continually discuss what objects we're touching in the system (we have enough meetings as it is with little time for productive work), and often we won't know exactly which objects until we get into it.

I'm interested how people tackle this and handle these kind of conflicts. Whether this is technology or processes or something else. Also interested if One Identity have been reconsidering their Transport processes/code management, especially in light of a lot of tasks being moved to Web Based from Fat Clients.

Parents
  • 0

    No one has ever had this challenge or found a workable solution?

  • 0 in reply to Ben

    Hello Ben,

    Maybe I'm too pessimistic but I don't think you will get any guidance on this topic from One identity or partners because:
    - there is no clear cut answer/solution for this challenge
    - from Quest's perspective this something that partners can help you with (via consultancy)
    - some partners have build there own solutions for this, so it's a selling point for them to choose them over other partners.

    See this sort of similar post also waiting for an answer...
    www.oneidentity.com/.../angular-web-portal-deployment-strategy---transport-packages-vs-environment-specific-builds

    In a nutshell my personal way of working, also not perfect but... it works for me.
    Source control all processes, sync projects and SystemLibrary just to keep track of what has changed.
    Export/Import processes via Designer/scripted XML export option www.oneidentity.com/.../how-to-export-import-processes-from-command-line
    Export/import sync projects support.oneidentity.com/.../how-to-export-the-synchronization-project-shell-from-the-synchronization-editor
    Schema extensions in production are done with the XML file option and then create transports to be placed back in OTA (to keep the GUID's consistent)
    3/4 times a year the production env. is cloned and used as a staging env. (without target system connectivity) just to validate transports.
    Always create dedicated custom attributes for each target system type on the OOTB tables. Don't use the customproperty01..09 with value templates that are shared between multiple target systems.
    Always think of using the sync editor/SQL first before creating custom processes/custom vbscripts/value templates. The operational guys and girls will thank you for this.
    Use custom tables (staging tables) to import HR data into the OOTB tables: Person, Department ect... instead of large SQL/vbscripts that calculate everything in runtime.
    Always restrict the DB permissions on the lowest level via permission groups (by making copies of VI_4_ALLUSER, VI_4_ALLMANAGER) instead of filtering/customizing/hiding access in the API server/HTML application.

Reply
  • 0 in reply to Ben

    Hello Ben,

    Maybe I'm too pessimistic but I don't think you will get any guidance on this topic from One identity or partners because:
    - there is no clear cut answer/solution for this challenge
    - from Quest's perspective this something that partners can help you with (via consultancy)
    - some partners have build there own solutions for this, so it's a selling point for them to choose them over other partners.

    See this sort of similar post also waiting for an answer...
    www.oneidentity.com/.../angular-web-portal-deployment-strategy---transport-packages-vs-environment-specific-builds

    In a nutshell my personal way of working, also not perfect but... it works for me.
    Source control all processes, sync projects and SystemLibrary just to keep track of what has changed.
    Export/Import processes via Designer/scripted XML export option www.oneidentity.com/.../how-to-export-import-processes-from-command-line
    Export/import sync projects support.oneidentity.com/.../how-to-export-the-synchronization-project-shell-from-the-synchronization-editor
    Schema extensions in production are done with the XML file option and then create transports to be placed back in OTA (to keep the GUID's consistent)
    3/4 times a year the production env. is cloned and used as a staging env. (without target system connectivity) just to validate transports.
    Always create dedicated custom attributes for each target system type on the OOTB tables. Don't use the customproperty01..09 with value templates that are shared between multiple target systems.
    Always think of using the sync editor/SQL first before creating custom processes/custom vbscripts/value templates. The operational guys and girls will thank you for this.
    Use custom tables (staging tables) to import HR data into the OOTB tables: Person, Department ect... instead of large SQL/vbscripts that calculate everything in runtime.
    Always restrict the DB permissions on the lowest level via permission groups (by making copies of VI_4_ALLUSER, VI_4_ALLMANAGER) instead of filtering/customizing/hiding access in the API server/HTML application.

Children
No Data