Results 1 to 4 of 4

Thread: Sencha Architect GIT versioning

  1. #1
    Sencha User
    Join Date
    Aug 2014
    Posts
    21

    Default Answered: Sencha Architect GIT versioning

    Hello everyone,

    I'm trying to decide whether the Sencha Architect software is a good solution for my agile team or not.
    I made a test application with a colleague following the Sencha architect instructions for teamwork.

    My problem is that my sencha application needs to be tested on a local server which is different than the one provided by Sencha Cmd to access external data.

    The .XDS file needs to be put on the git repository as it is mandatory in a given project, and it enters in conflict everytime we commit data because of the export path and publishing options that differ from my colleague's machine and mine. The issue, seemingly discussed in this thread (which just won't load on my sencha forum account due to permissions), is that the export path of both our localhosts are unfortunately part of the versioned XDS file.

    Of course such a conflict is pratically unacceptable, as it is a common agreement among developpers that IDE preference files should never be part of a versioned source code.

    Is there thus a way to commit development work made on several architect installations (with different settings) without getting a conflict every time changes are made or do we actually need to install a common development server which will be used by every developper in our project?

    Thanks in advance,

    Pierre

  2. Hi Pierre,

    Happy to help where I can!

    1. With the urlPrefix, if each developer is publishing then you may want to do something similar to symlinks for your webserver, such as creating aliases or virtual directories so the same URL points to the publish directory in each environment, but...

    2. More importantly, we use the publish feature pretty rarely. Each of the developers on our team has made a virtual directory in his webserver pointing to the Architect directory. We're using ColdFusion, so in .sencha/app/sencha.cfg we've changed "app.page.name" to "index.cfm", we made some customizations to index.cfm, and we disabled the "Overwrite index file on save" option in Architect. Architect generates all the source files on save so there's no need to publish before testing (save for the final phase of testing). Just point the browser to the hosted index.cfm file and away you go. Making and testing a change is really quick -- the slowest part is probably just waiting for the browser to load all the JS files since we usually leave cache busting on.

    Edit:
    To simplify, in your situation I would have each developer point his webserver to the Architect project directory on his system. Publishing can be pretty slow, but thankfully there shouldn't be any need to publish often during testing.

  3. #2
    Sencha User
    Join Date
    Jul 2014
    Posts
    33
    Answers
    1

    Default

    Hi Pierre,

    Our team is also using a git workflow for agile-ish development.

    I agree that preference files should not need to be versioned. It's unfortunate that Architect requires the XDS file to be versioned -- or at least, appears to do so.

    Architect doesn't have any "New Project from Existing" feature like Eclipse does, but you can create a "dummy" Architect project and use its XDS to open the real project. E.g., create an empty project and then move its XDS to the directory of an existing project. There are caveats of course, such as issues that might come up if the framework version changes, but this would at least take you one step closer to unversioning the XDS file.

    In any case, the best option when path configurations vary between developers is generally to use symlinks to make the environments as similar as possible. For example:

    Web-hosted directory:
    Code:
    /var/www/html/SuperCoolProject/
    Development (Architect) directory:
    Code:
    /home/me/development/extjs/SuperCoolProject/architect/
    Make symlink:
    Code:
    ln -s /var/www/html/SuperCoolProject/ /home/me/development/extjs/SuperCoolProject/published
    # Windows: mklink /J <LINK> <TARGET>
    Do not track symlink:
    Code:
    echo '/published' >> .gitignore

  4. #3
    Sencha User
    Join Date
    Aug 2014
    Posts
    21

    Default

    Hello mhill, Thank you very much for your answer already.

    I'm making sym links on windows to see what happens. I still have 2 problems:

    * My XDS file still contains a urlPrefix variable which may differ between me and my colleagues (it's a link to "http://localhost:8080/Extjs5Test" on my windows, I'm not sure I can make a symbolic link here as easily as the other one).

    * Building still takes around 20 seconds for a rather small project, which is a real pain to debug.

    Do you have any insight on these issues? T

    hanks again for your time,

    Pierre

  5. #4
    Sencha User
    Join Date
    Jul 2014
    Posts
    33
    Answers
    1

    Default

    Hi Pierre,

    Happy to help where I can!

    1. With the urlPrefix, if each developer is publishing then you may want to do something similar to symlinks for your webserver, such as creating aliases or virtual directories so the same URL points to the publish directory in each environment, but...

    2. More importantly, we use the publish feature pretty rarely. Each of the developers on our team has made a virtual directory in his webserver pointing to the Architect directory. We're using ColdFusion, so in .sencha/app/sencha.cfg we've changed "app.page.name" to "index.cfm", we made some customizations to index.cfm, and we disabled the "Overwrite index file on save" option in Architect. Architect generates all the source files on save so there's no need to publish before testing (save for the final phase of testing). Just point the browser to the hosted index.cfm file and away you go. Making and testing a change is really quick -- the slowest part is probably just waiting for the browser to load all the JS files since we usually leave cache busting on.

    Edit:
    To simplify, in your situation I would have each developer point his webserver to the Architect project directory on his system. Publishing can be pretty slow, but thankfully there shouldn't be any need to publish often during testing.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •