Author Topic: [Share] Approach to Handle User's Working Branch and Master Branch in coArchi  (Read 165 times)

xiaoqi

  • Active Member
  • ***
  • Posts: 81
  • Today is the Tomorrow we talked about Yesterday
Hello all,

Our architect team adopted Archi and coArchi during past year, and gradually have more and more colleagues joining the collaboration, not only in the local self model.

To publish the model within team, we use Microsoft Azure DevOps Repo for hosting the model with Git protocol, and create "working branch" for each practitioners, so there're numbers of user working branch and one master branch exist in the Workspace.

It is not surprise within multiple innovative architect when all start contributing and making branch behind/ahead master always, but it is really challange to ensure preventing the merging issue as we all together maintaining one central "master" repository.

After several times' "nightmare" for solving Merging error, we found out it is critical for team all keep the same view on not only just User Branch and Master Branch, but also need to clearly understanding the Local Branch and Remote Branch.

Here, would like to share with you on the approach summarized for how to handle "model code" moving among those concepts, it may not the perfect, but we think it is good enough for now and people start to familiar and we see Merge conflict is seldom happens.

Hope to hear from experts here on your experience and comments as well.

The diagram is created using PlantUML, you can find source here https://github.com/yasenstar/info_zone/blob/master/archi/handle_branch.puml

May you have a nice day,
Xiaoqi

Phil Beauvoir

  • Administrator
  • Hero Member
  • *****
  • Posts: 1639
  • Code Punk
    • Archi
Hi Xiaoqi,

thanks for sharing this, it's very helpful. I like that you've created it using PlantUML.

> After several times' "nightmare" for solving Merging error...

I think that when we come back to working on coArchi 2 we'll consider the pain points and attempt to ease them. We'll be using structural diff rather than textual diff, but as we use git we can't get away from the concepts of remote and local branches, and the commit, push and pull actions.

Regards,

Phil
If you value and use Archi please consider making a donation! https://www.archimatetool.com/donate

Jean-Baptiste Sarrodie

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 729
  • Archi Evangelist and Contributor. Visionary.
    • About me...
Hi,

Thank you for sharing.

It seems to me that several actions could be removed by using the "online" merge option. The goal of this option is to make sure you refresh both the source and target branches that you are gonna merge, and then publish the result. Maybe the only issue is that even after a successful merge one can want to review the result before publishing, but other than that, that's a single clic action for the whole process.

Regards,

JB
If you value and use Archi please consider making a donation! https://www.archimatetool.com/donate

xiaoqi

  • Active Member
  • ***
  • Posts: 81
  • Today is the Tomorrow we talked about Yesterday
Hi Phil and JB, thanks for your quick feedback.

To Phil:

- the "nighemare" is little relating to our tool, my observation is the key to make things smooth is to have team working in the common way, that takes time and once more colleagues adopts the serious steps, "conflicts" happened less.
- glad to know "structural diff" will replace the "textual diff", believe that will prevent big part of issues, however, dealing between our coArchi and variable practical git repo will still need the team to trial and align

To JB:
- You point one of the key reason that I'd like to manage merge first then publish second, that really give person a chance of breathe (;-)) if any content conflicts happen, however, in my other model, I tried "online" merge option and that running perfectly
- Another reason, beyond model itself, is try to prevent the issue happens purely due to network connectivity, some of our team members are using VPN when working from home, and our repo is hosted in company's intranet, merge first in local can give assurance of the model is safety first, then publishing step will be the only step that need to call remote

Looking forward to your coArchi2 soon, nice day,
Xiaoqi

Jean-Baptiste Sarrodie

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 729
  • Archi Evangelist and Contributor. Visionary.
    • About me...
Hi,

Another reason, beyond model itself, is try to prevent the issue happens purely due to network connectivity, some of our team members are using VPN when working from home, and our repo is hosted in company's intranet, merge first in local can give assurance of the model is safety first, then publishing step will be the only step that need to call remote

In fact, the "online" merge does exactly what you describe in your diagram: it first make sure that your local branches are up to date, then does a local merge, then (if no issues) publishes the result. So network is not more of an issue than in your workflow.

The only real limitation for most users is this final publication which shouldn't be ^done before some sort of review.

Regards,

JB
If you value and use Archi please consider making a donation! https://www.archimatetool.com/donate

xiaoqi

  • Active Member
  • ***
  • Posts: 81
  • Today is the Tomorrow we talked about Yesterday
Thanks JB for your explanation, I'll try to observe and hope to recommend "online" merge in our way of working ASAP.

Regards, Xiaoqi