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

August 27, 2014 110 Views

Guest Blog Post

Sencha Architect Team Development in the Real World Part 2 of 3 In part 1 of this blog post series, I detailed the tools that CNX uses to manage team development with Sencha Architect and presented one example to explain the basic process. In this installment, I will look at a more common scenario—two or more developers working on the same app in different areas. This turns out to be quite easy to manage because Sencha Architect metadata and JavaScript files will only change for those models, stores, controllers, views, etc. that you have actually changed. For example, if one developer changes a controller and another changes a view, these changes will be merged automatically and gracefully by Git and pushed to the Gitlab server without any trouble.

Example 2: Typical Case – Multiple Developers Making Changes to Different Areas of an App

Ok, let’s get to the example. Here, I will change the SimpleForm view again by adding a Help button at the bottom while Sean (another developer at CNX) adds the controller logic at the same time to handle what happens when that button is pressed.

Here I’ve added the Help button on the bottom toolbar:

Richard’s Sencha Architect – Added Help Button.

This is a screenshot of Sean’s Sencha Architect where he has added a Controller Action to handle when my Help button is pressed:

Sean’s Sencha Architect – Added onHelpButtonClick Controller Action.

You can see in this screenshot of Sean’s WebStorm that it’s showing only the Main controller has been changed (Note: Sean’s WebStorm is using a dark theme whereas mine is using a light gray theme. Also, ignore the .architect file in the following screenshots—I should have added it to the .gitignore file so that it was not tracked for changes.):

Sean’s WebStorm – Only the Main controller has changed.

On my WebStorm, it shows only the Viewport view class has been changed:

Richard’s WebStorm – Only the Viewport class has been changed.

Now, let’s see what happens when Sean and I both commit and push into Gitlab. First, Sean will commit and push:

Sean’s WebStorm – Commit and push his changes to the Main controller.

Now, I will commit and push the changes I made to the view:

Richard’s WebStorm – Commit and push changes to Viewport class.

In this case, since Sean has committed a change to Gitlab that I don’t have on my local copy, WebStorm is giving a push rejection message. However, on this error message, there’s an option to Merge:

Richard’s WebStorm – Push rejected with option to Merge.

Now, I will click the Merge button. As long as Sean and I have not changed any of the same files (we haven’t), I’ll go immediately to the Push window and push the changes:

Richard’s WebStorm – Push changes after a merge.

If we now look at the files on Gitlab, we can see the last person that has changed a controller is Sean and the last person that has changed a view is me:

Gitlab Server – Files after changes pushed by both Sean and Richard.

Obviously, this was a really simple scenario, but as long as multiple developers are working within different classes (i.e. files) all the changes should merge gracefully with no conflicts. At CNX, we try to assign programming tasks specifically to minimize merge conflicts.

Conclusion

In this blog post, I presented an example of how two or more developers can make changes to different areas of the same Sencha Architect app and bring those changes together gracefully. In the third and final installment of this series, I will tackle the most tricky case—multiple developers making a change to the same area of an app and resolving merge conflicts.