Sencha Architect – Team Development in the Real World (Part 3 of 3)

Guest Blog Post

In part 1 and part 2 of this blog series, I provided details about the tools that CNX uses to manage team development with Sencha Architect, and I explained the basic process and presented some simple example scenarios. In this last installment, I will show you what happens when two or more developers make changes to the same files within an app at the same time.

As discussed in part 2, CNX assigns tasks to developers in such a way as to minimize the chances of two or more developers making changes to the same files at the same time, but of course it can and does happen.

Example 3: Multiple Developers Making Changes to the Same Area of an App at the Same Time

In this example, I will add some code to a controller and Sean (another developer at CNX) will do the same, completely unaware of what I have done. In the real world, the fact that a merge conflict arises would normally prompt me to discuss it with Sean before deciding how to resolve the merge. We will then have three choices to consider:

1. Accept my changes and dump Sean’s changes.
2. Accept Sean’s changes and dump my changes.
3. Try to gracefully merge the changes and then have one developer review and resolve any logic problems.

Let’s say Sean and I discussed enhancing the controller from part 2 to display a better temporary message window. Further, let’s say we had a misunderstanding of who was going to code that logic, so we both completed the work separately in our local copies of the app. First, here’s Sean’s version:

Sean’s Sencha Architect – Better temporary message window.

Now, here’s my version that I coded independently. Note that Sean’s and my versions are similar but not exactly the same:

Richard’s Sencha Architect – Better temporary message window.

Sean will commit and push his changes first. I won’t show screenshots of this because there won’t be any conflicts on the first push. Next, I will commit and push my changes and get a merge conflict similar to the last example:

Richard’s WebStorm – Rejection when Richard’s new message window pushed.

After clicking the Merge button, the list of files with conflicts will show:

Richard’s WebStorm – Files with merge conflicts.

The first file with a conflict is Main.js. WebStorm will nicely show my change on the left with Sean’s change on the right, and I can merge whatever side I want into the target Merge Result in the center:

Richard’s WebStorm – Merge Revisions window for Main.js.

I’ve discussed it with Sean, and we’ve agreed that his change is better, so I’ll use the arrow next to his change to merge that into the center and dump my change:

Richard’s WebStorm – Deciding on changes to accept in Merge Revisions window.

Richard’s WebStorm – Sean’s merge revision accepted in Main.js.

If there were other change blocks, I would simply go to each one of them and review it in a similar fashion. In other types of changes, I could easily incorporate pieces of one side and/or the other into the center to get the desired result.

The next file to merge is the Sencha Architect metadata file for the Main controller:

Richard’s WebStorm – Sean’s merge revision accepted in Main metadata file.

Conclusion

In this blog series, I have outlined the development tools and methodology that CNX uses to develop effectively with Sencha Architect in a team environment. The key takeaway from this series should be: it’s time to introduce Sencha Architect to your team. If you like Sencha Architect but weren’t sure how to make it work in a team environment, you should now be equipped with enough information to get started. Now that CNX has been using this development methodology for many months, we really can’t understand why we didn’t do it sooner.

Further Reading

• Git branching strategy that CNX uses.
• More info on Gitlab.
• Installing Gitlab on Debian/Ubuntu Linux