Should I keep versioning role-based views?

Hi everyone,

We've been using Git to deploy Sugar code on premise for a while now, and since my customer started playing with role-based views, I ask myself this question : Should I keep versioning those views?

The obvious answer is "Yes, you should, it's still code", but given the fact that those views are applied to a role thanks to the role's ID, shouldn't we consider them as being environment-specific and stop tracking them?

My customer created some roles on Test and Production via Administration, defined some corresponding views in test that we cannot make work in production because the roles have different IDs on different environments... So now, I'm stuck between two possibilities :

 - stop tracking role-based views and let my customer play with it without caring

 - continue to track them, but then I need to transfer roles from test to production (and, in one way or another, prevent anyone from creating new roles in production to avoid issues...)

How would you recommend to proceed with those views? Matt Marum, Lauren Schaefer, any advice?

Thanks,

Christopher Cacciatore

  • Hi Christopher,

    If this is my project, the short answer will be "yes, version them".

    To make this works for you, you may want to consider transfer the role and related views from Production to Test instead. This will make versioning easier.

    Also set the expectation that the testing data on Test  may not be transferred to Prod.

    Regards,

    Romney

  • Hello Romney,

    We had exactly the same problem in our organization, particularly for role based views and dropdowns.

    We decided to keep them in git and we created a simple(bash) script that after each deployment will copy the role files from dev roles to the corresponding production roles.
    The link between dev and production role ids was defined in a simple config file, different for each environment.

    Don't hesitate to ask if you need further clarifications.

    Regards,

    George