0

The context : we are working on Windows OS (VS 2017, VS Code) with many JavaScript files, for ex: in the 'controls' folder we will have control1.js, control2.js etc (different people working on different controls).

|- controls
     |- control1.js
     |- control2.js

On the 'apps' folder we will have : 

|-apps
    |- app1
        |- view.js
        |- controller.js
        |- model.js
    |- app2
        |- view.js
        |- controller.js
        |- model.js

Now, the idea is that the testing team will/might find errors that needs to be fixed. We will fix the code and re-deploy the fixed file (for ex. control1.js) to the specific testing team. If another team (working on a different environment) reports another error in the same file (control1.js) there is no way for us to know if the current environment has the fix mentioned above or not (only code-compare will tell us). There is no file version that will help us know where (in what version) the issue happened and in what version it was fixed.

What do we want - (maybe this problem was already solved but I didn't find anything) - we want that @ check-in-time the version of the JavaScript file to be increased (probably the release number as in C#).
We are using as version-control TFS (on premises) and VSTS/Git (online at visualstudio.com).

How ? - each JavaScript file will have some sort of header (a large area at the top of the file with some commented text) that will contain some information about the company etc ... and also the version of the file ex.: 1.0.2.23. In this way we will know in what version a fix was done (the bug tracking system requires us to mention in what version the bug was found and in what version it was fixed.

How can we simulate this in VS 2017 (2015) and also in VS Code ?
Can we have a single file (the same as AssemblyInfo.cs in C#) common to all JavaScript files and than that file to be ... merged with each JavaScript file?
In this way, if we need to change something globally we will not need to ... find/replace all over the place ?

Thank you in advance.

SevenIron
  • 31
  • 1
  • 2
  • 8

2 Answers2

0

For the situation that a file (such as control1.js) need to be modfied by multiple people:

  1. If the file need to be double tested by testing team after you fixed, you can modify the file on another branch and then merged into current working branch by testing team.
  2. If testing team won’t test the fixed file, you can modify the file directly on current branch, and push the branch to TFS/VSTS. After that, if other team members also need to modify the same team, they can pull the changes you made and fix the file based on the newest version.

For the version of file:

Actually it’s a new version when you commit changes every time, git will calculate a new SHA-1 checksum (commit id) like a11bef06a3f659402fe7563abf99ad00de2209e6, you can view in VS -> Team Explorer -> Branches -> right click a branch -> View History.

If you want to a version more readable, you can add a tag for a commit, such as in View History -> right click a commit -> Create Tag -> then enter a tag name such as 1.0.2.23.

And you don’t need a single file to record the file version since git can manage the versions for every changes you made.

To get the version that test team deployed, you can use these steps: open the release -> Artifacts -> find the build definition and build version -> find the build version in build Tab -> in the summary page you can find git version in Source version.

enter image description here

enter image description here

Marina Liu
  • 36,876
  • 5
  • 61
  • 74
  • Hi Marina - thanks for the quick answer, but this will not really solve it, as once the application is deployed we have no possibility of knowing what version each of the test team is running on. What we need is exactly what C# is doing with the AssemblyInfo.cs and each compilation increasing the release version of the assembly. We know that there is no compilation step in JavaScript - this is why I was suggesting the check-in-time as the point where the the file will be stamped with the increased version. Now, how can we achieve this ? – SevenIron Apr 12 '17 at 14:19
  • You can find the version after the application is deployed, and I added the way in my answer. – Marina Liu Apr 14 '17 at 08:30
  • Can you find the version now? Did the answer help you solve the problem? – Marina Liu Apr 18 '17 at 08:21
  • Marina, as I said the solution is not helping us but I think that is caused by a 'communication-breakdown" :-). Long-story-short: when a bug is reported we debug the remote system and pinpoint it in some .js file. From the header of that file (that should contain some company info, hash of the code, and VERSION of the code) we can file a bug that says : the 'text-box' control version M.m.r.b has a bug when key is pressed twice ;-) . We then can go ahead and fix the bug and file the 'resolved' status with the version where it was solved. Minified files or not - we react in the same way. – SevenIron Apr 20 '17 at 13:30
  • As a solution for this behaviour I thought that I might integrate with git's hooks. So, i was thinking to do the same think that you can do with ESLint, where at check-in time the code is linted. Now, in our case after successful linting we go ahead and parse-find-increment or parse-injectNew header with the necessarily information. I'm not saying that i built this mechanism yet but that's the gist of it. Now, what do you think about this approach ? (the limitation here is that the mechanism is bound to Git control system - which is not 100% OK). – SevenIron Apr 20 '17 at 13:33
  • Thank you very much ! I'll try to implement the pre-push hook as you suggested (any help is REALLY welcomed as I don't know how to write the hooks - probably stackoverflow.com will be my 'guide' ;-) ). – SevenIron Apr 21 '17 at 16:09
  • It seems pre-commit hook is more suitable for jshint, and you can refer http://stackoverflow.com/questions/15703065/setup-pre-commit-hook-jshint. – Marina Liu Apr 22 '17 at 14:17
0

We use versions formed as <major>.<minor>.<changeset>-<buildid>-<branch> to keep track of versions deployed. On each deploy custom IIS response header field "X-Release" is updated with version number so that QA/PM always can check what code version they are working with in the developers tools: Network tab of developer tools

However, we are using Octopus Deploy so cannot tell how to do this in TFS release.

Eduard
  • 897
  • 5
  • 11