Guest Blog Post
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.
Further Reading
- This page generally describes the Git branching strategy that CNX uses:
A successful Git branching model - More info regarding Gitlab:
Open source software to collaborate on code - Installing Gitlab on Debian/Ubuntu Linux:
GitLab Community Edition Installation Guide
Hi,
This is a nicely prepared article, kudos for that. We are also working on an application using Ext Js and Java as the backend and these are the tools that we are using –
1. Sencha Architect
2. Eclipse IDE
3. SVN for version control
We are almost following the design flow and structure that you’ve highlighted in these series of articles, where we’ve merged the Architect project with our Java Web project and we maintain both the generated js files and the meta files in the version control. However, one thing that I’ve observed that is that – since we are only saving the project in Sencha Architect, only the js files are generated but the bootstrap files and the app.json are never updated.
Now, we are in the verge of integrating an external Ext Js component, which has been developed by another team [not using Sencha Architect but only with Sencha cmd]the component can be considered as a full fledged ExtJs App as it has it’s own Controllers and views defined along with other components and since they are also in the same mode of development we are expecting frequent changes in their component. This is created a bit of a concern and well, we can make it work during the development phase but we need to handle how the production build is going to happen.
With that bit of background, here is my doubt – How do we make two different apps, one developed using Sencha Architect and the other without, work in harmony?
After reviewing my own comment, it seems like my question is not really related to the article but it’d still be a lot of help if you could shed some light on it. [ I remember you mentioned something about bits of code not written in Architect, in the first article] :)
Hi good article, Now, I can understand better the work flow to work in team with Sencha Architect, but I have a doubt, from the source control how you can deploy the application to production for instance, I mean you need create a app.js?_dc=xxxxx using Sencha Cmd, Can you explain or give details about the continuous integration work flow using Sencha Architect?
regards
Frank
In response to Frank, your question about deployment to a server could probably use a whole separate blog post on its own to explain (maybe I’ll do one). But in short, we have two primary methods of deployment. One is to configure a deployment server in WebStorm and at any time we can select the app or any part of it and “copy” it up to a server. This is what we normally do during testing and QA. In situations where we are maintaining a highly controlled software product, like CNX’s Valence Framework, we have an automated script on the Gitlab server that detects a push to certain branches and triggers a build on the server. Once the build is complete the automated process then deploys the build to a server. Of course there’s a lot of little details to setting this up, so I’ll consider doing another blog post on this topic.
In response to Yellen seram, I’m not sure I fully understand the problem, but I can tell you that we do frequently share resources, components, etc. between apps. These can be Sencha Architect or not, it doesn’t matter. Sometimes we generate “packages” and reference them in other apps, sometimes we just add paths and “require” classes from other apps. My best guess is that you should be creating a “package” with you non-Sencha Architect work, but that’s just one option. If you can provide any additional details I might be able to provide more guidance.