2
1
0

(Asked on behalf of Fabiola Ansara and Benjamin Martinez)

We have a form that contains many components.

We do a release of that form, and we want to "Freeze" it. (We may need to do a patch later.) So we create a new version (or a copy) of that form, and only make changes to the new copy.

The problem is that if anyone makes any changes to any of the components, the same component appears in both the old and the new version of the form - and so the original form is not really frozen, it will change as the components change.

We can envisage several different solutions to this problem.

  1. We can embed the current version of the components into V1 of the form. The form will no longer refer to the components, it will just be one big form. This isn't ideal, but it's workable.
  2. We can somehow do configuration management of the form and its components within Maestro. We're not quite sure how to achieve this. 
  3. The most ideal approach would be branching. We could use the new source code management features in the latest version of Maestro to create a branch in GIT. The GIT branch would include the form and all its dependent components. Then we need a way to "recreate" that branch in Maestro, so we can work on it independently from the main branch if we need to do a patch.
  4. Other.

We would appreciate any thoughts or suggestions.

    CommentAdd your comment...

    2 answers

    1.  
      2
      1
      0

      Howard, I agree that #3 would be optimal. It is currently not possible due to the fact that we don't have a "headless" build process. The build of the final form occurs within the Maestro application. The longer term plan is to support a CI-server-based build process, and builds could be configured to check out the appropriate branch. This is in our roadmap, but not currently under development.

      One thing we are currently developing is library versioning, so if you publish V1 of your component to project library V1, and then move to library V2 for your new development, when you want to go back to your "frozen" form you could select V1 as the selected version of the library in order to do whatever you need to do with that frozen version. This is scheduled for delivery in 18.04. You could simulate this in the current version by using a name-based approach to library versioning. This approach is certainly not ideal - once you set the project's included libraries back to your "frozen" version it would affect anyone else working on other forms in that project for the duration until you set it back - but depending on your scenario and what you want to do with the "frozen" form it may help you achieve what you need until the more advanced features are available.

      We will take on board your feedback - for example it may make sense to expand the scope of our library versioning development to allow the specification of library version dependencies at the form design version level, instead of at the project level. I'll discuss with the team. 

        CommentAdd your comment...
      1.  
        1
        0
        -1

        Hi Tim

        We want to "freeze" our projects so that we can go back  to them as they were in previous sprints and make small fixes.

        Lets say right now we have a Form1 and we want to freeze it, but it contains two components so we have something like

        Form1
        	Component1
        	Component2
        

        At the end of our sprint we add a tag to our form and continue developing so we end up with something like 

        Form1#sprint1
        	Component1
        	Component2

        A couple of weeks later at sprint 5, our QC team finds a bug on Component2 which went to production at the end of sprint 1 so they ask us to fix it. But Component2 has received several new functions that out QC don't want to send to production because they haven't been properly tested. In this scenario we would need to search through all our save story to get a version where we can fix the issue with no extra features.

        Ideally we would have a tag for each Form and each Component like

        Form1#sprint1
        	Component1#sprint1
        	Component2#sprint1

        But in this scenario we would need to tag each component and each form manually (almost 50 of them) and then in case we need to go back to a previous sprint we would have to publish the whole project manually.

        We've already considered exporting all of our projects at the end of each sprint but in that case we would still need to publish every component to a new library so we don't make any conflict with our current sprint.

          CommentAdd your comment...