Produced by Araxis Merge on 11/9/2017 10:44:34 AM Eastern Standard Time. See www.araxis.com for information about Merge. This report uses XHTML and CSS2, and is best viewed with a modern standards-compliant browser. For optimum results when printing this report, use landscape orientation and enable printing of background images and colours in your browser.
| # | Location | File | Last Modified |
|---|---|---|---|
| 1 | REFDOC-v2.1.0.zip\NVCC\Documentation | ReleasePlan.md | Thu Oct 19 17:36:40 2017 UTC |
| 2 | REFDOC-v2.1.0.zip\NVCC\Documentation | ReleasePlan.md | Wed Nov 8 16:10:22 2017 UTC |
| Description | Between Files 1 and 2 |
|
|---|---|---|
| Text Blocks | Lines | |
| Unchanged | 2 | 272 |
| Changed | 1 | 2 |
| Inserted | 0 | 0 |
| Removed | 0 | 0 |
| Whitespace | |
|---|---|
| Character case | Differences in character case are significant |
| Line endings | Differences in line endings (CR and LF characters) are ignored |
| CR/LF characters | Not shown in the comparison detail |
No regular expressions were active.
| 1 | # Steps to deploy a new versio n from dev elopment | |
| 2 | ||
| 3 | 1. Make su re you are on the `d evelop` br anch and a re up to d ate with w hat is on the remote git/TFS s erver | |
| 4 | * `git checkout develop` | |
| 5 | * `git fetch` | |
| 6 | * `git status` | |
| 7 | ||
| 8 | Yo u should s ee "Your b ranch is u p-to-date with 'orig in/develop '". Additi onally, th ere should be no mod ified file or staged files. Un tracked fi les are al lowed so l ong as you are sure they are n ot needed to be reco rded in th e project repository . | |
| 9 | ||
| 10 | If you are n ot up to d ate, you m ay need to do a `git pull` and possibly resolve co nflicts, p ushing you r result b ack to the remote gi t/TFS serv er. | |
| 11 | 2. Branch from `deve lop` into `release-X .Y.Z` wher e `X.Y.Z` is the to- be-release d version number | |
| 12 | * `git checkout -b release -X.Y.Z` | |
| 13 | 3. Update version nu mber and r elease dat e in code and verify version h istory | |
| 14 | * In N VCC.WebUI/ Views/Help /About.csh tml, the v ersion num ber and re lease date are hard- coded near the top | |
| 15 | * In N VCC.WebUI/ Views/Help /News.csht ml, review the descr iptions of the chang es from th e previous version. This descr iption is intended f or the end -user audi ence and s hould be w ritten in language a ppropriate for that audience. Every vers ion should have at l east one e ntry descr ibing what changed. | |
| 16 | * Comm it these f iles to th e release branch. | |
| 17 | 4. Merge t he release branch ba ck into `d evelop` an d push `de velop` to the remote origin | |
| 18 | * `git checkout develop` | |
| 19 | * `git merge --n o-ff relea se-X.Y.Z` | |
| 20 | ||
| 21 | Re solve any conflicts. | |
| 22 | ||
| 23 | * `git push orig in develop ` | |
| 24 | ||
| 25 | Re solve any conflicts. | |
| 26 | 4. Back-up the exist ing versio n on the p roduction server. Op en `\\ DNS . URL \ DNS . URL ` in Explo rer. Right -click on the `NVCC` directory and selec t "Send to " -> "Comp ressed (zi p) folder" . After th e "Compres sing..." d ialog fini shes, chan ge the res ulting fil ename `NVC C.zip` to `NVCC_N.N. N_YYYYMMDD ` where `N .N.N` is t he _previo us_ versio n number a nd `YYYYMM DD` is the _current_ date in f our-digit year, mont h, day for mat (witho ut delimit ers). (e.g . `NVCC_1. 6.2_201609 16.zip`) | |
| 27 | 5. Deploym ent. Chang e back to the releas e branch a nd publish to produc tion. | |
| 28 | * `git checkout release-X. Y.Z` | |
| 29 | * From Visual St udio, Buil d -> Publi sh selecti ng Product ion | |
| 30 | * Any permission s needed t o be check ed? | |
| 31 | 6. If any changes we re needed to be able to publis h, commit these chan ges to the release b ranch and then merge these cha nges back into devel op (see ab ove step f or details ). Hopeful ly, this s tep should not be ne cessary. | |
| 32 | 7. Merge t he release branch in to `master ` | |
| 33 | * `git checkout master` | |
| 34 | * `git merge --n o-ff relea se-X.Y.Z` | |
| 35 | ||
| 36 | Th ere should not be an y conflict s with thi s. | |
| 37 | 8. Tag the master br anch with a tag of t he format `vX.Y.Z`. Give it th e commit m essage "Ve rsion X.Y. Z" | |
| 38 | * `git tag -a -m "Version X.Y.Z" vX. Y.Z` | |
| 39 | 9. Push th e master b ranch to t he remote origin, in cluding th e new tag. | |
| 40 | * `git push --ta gs origin master` | |
| 41 | 10. Change back to d evelop bra nch to gua rd against inadverte nt commits to the ma ster branc h. | |
| 42 | * `git checkout develop` | |
| 43 | 11. Delete the relea se branch since it h as been co mpletely m erged into both deve lop and ma ster | |
| 44 | * `git branch -d release-X .Y.Z` | |
| 45 | 12. Notify users of updated ve rsion. Inc lude the m ost recent changes t hat are li sted in Ne ws.cshtml. (what pro tocol?) | |
| 46 | ||
| 47 | # Steps to re-deploy the curre nt release | |
| 48 | ||
| 49 | 1. Checkou t the `mas ter` branc h of the r epository | |
| 50 | * `git checkout master` | |
| 51 | 2. Verify the checko ut is clea n and up-t o-date | |
| 52 | * `git fetch --t ags` | |
| 53 | * `git status` | |
| 54 | ||
| 55 | Yo u should s ee "Your b ranch is u p-to-date with 'orig in/master' ". Additio nally, the re should be no modi fied file or staged files. Unt racked fil es are all owed so lo ng as you are sure t hey are no t needed t o be recor ded in the project r epository. | |
| 56 | 3. Deploym ent | |
| 57 | * From Visual St udio, Buil d -> Publi sh selecti ng Product ion | |
| 58 | ||
| 59 | # Steps to rollback to a previ ous releas e | |
| 60 | ||
| 61 | 1. Make su re you hav e the most recent up dates from the centr al reposit ory | |
| 62 | * `git fetch --t ags` | |
| 63 | 2. Determi ne the tag correspon ding to th e version you want t o rollback to. A lis t of all t he tagged versions c an be gott en with | |
| 64 | * `git tag --lis t -n` | |
| 65 | ||
| 66 | or mor e detail ( including tag date a nd message ) with | |
| 67 | * `git for-each- ref --form at="%(refn ame:short) %(taggerd ate) %(sub ject)" ref s/tags` | |
| 68 | 3. Checkou t the appr opriate ta g based on its short tag name | |
| 69 | * `git checkout vX.Y.Z` | |
| 70 | ||
| 71 | You wi ll get a m essage lik e | |
| 72 | ||
| 73 | No te: checki ng out 'v1 .6.0'. | |
| 74 | ||
| 75 | Yo u are in ' detached H EAD' state . You can look aroun d, make ex perimental | |
| 76 | ch anges and commit the m, and you can disca rd any com mits you m ake in thi s | |
| 77 | st ate withou t impactin g any bran ches by pe rforming a nother che ckout. | |
| 78 | ||
| 79 | If you want to create a new bran ch to reta in commits you creat e, you may | |
| 80 | do so (now o r later) b y using -b with the checkout c ommand aga in. Exampl e: | |
| 81 | ||
| 82 | git checko ut -b <new -branch-na me> | |
| 83 | ||
| 84 | HE AD is now at 12ade2d ... Merge branch 're lease-1.6. 0' | |
| 85 | ||
| 86 | with t ags, SHA's and messa ges approp riate to y our releas e | |
| 87 | 4. Deploym ent | |
| 88 | * From Visual St udio, Buil d -> Publi sh selecti ng Product ion | |
| 89 | 5. Return your worki ng directo ry to a us able state (`develop ` or whate ver branch you were working on ) | |
| 90 | * `git checkout develop` | |
| 91 | ||
| 92 | # Steps to create a hotfix | |
| 93 | ||
| 94 | A hotfix d iffers fro m a regula r release in that it is an urg ent, typic ally small change to the tool. It specif ically is not to inc lude any o f the deve lopment th at has bee n done (an d merged i nto `devel op`) since the last release. T ypically, the decisi on that a hotfix is needed is made even before any code that will go i nto the ho tfix is wr itten. A h otfix star ts from `m aster`, an d its chan ges will g o both int o `master` for produ ction and `develop` so that th ey are not lost in l ater versi on. | |
| 95 | ||
| 96 | 1. Make su re you hav e a clean repository ; stash ac tive chang es on your active br anch, if a ny | |
| 97 | 2. Checkou t the `mas ter` branc h of the r epository | |
| 98 | * `git checkout master` | |
| 99 | 3. Verify the checko ut is clea n and up-t o-date | |
| 100 | * `git fetch -- tags` | |
| 101 | * `git status` | |
| 102 | ||
| 103 | Yo u should s ee "Your b ranch is u p-to-date with 'orig in/master' ". If you are behind `origin/m aster`, an d can fast -forward, do so: `gi t pull`. A dditionall y, there s hould be n o modified file or s taged file s. Untrack ed files a re allowed so long a s you are sure they are not ne eded to be recorded in the pro ject repos itory. | |
| 104 | 4. Branch from `mast er` into ` hotfix-X.Y .Z` where `X.Y.Z` is the to-be -released version nu mber. Typi cally, thi s will jus t be an in crement of `Z` | |
| 105 | * `git checkout -b hotfix- X.Y.Z` | |
| 106 | 5. Make wh atever cha nges are n eeded to f ix the pro blem that this hotfi x is meant to solve. Commit th ese change s to the h otfix bran ch. | |
| 107 | 6. Update version nu mber and r elease dat e in code and verify version h istory | |
| 108 | * In N VCC.WebUI/ Views/Help /About.csh tml, the v ersion num ber and re lease date are hard- coded near the top | |
| 109 | * In N VCC.WebUI/ Views/Help /News.csht ml, review the descr iptions of the chang es from th e previous version. This descr iption is intended f or the end -user audi ence and s hould be w ritten in language a ppropriate for that audience. Every vers ion should have at l east one e ntry descr ibing what changed. | |
| 110 | * Comm it these f iles to th e hotfix b ranch. | |
| 111 | 7. Merge t he hotfix branch bac k into `de velop` and push `dev elop` to t he remote origin | |
| 112 | * `git checkout develop` | |
| 113 | * `git merge --n o-ff hotfi x-X.Y.Z` | |
| 114 | ||
| 115 | Re solve any conflicts. | |
| 116 | ||
| 117 | * `git push orig in develop ` | |
| 118 | ||
| 119 | Re solve any conflicts. | |
| 120 | 8. Deploym ent. Chang e back to the hotfix branch an d publish to product ion. | |
| 121 | * `git checkout hotfix-X.Y .Z` | |
| 122 | * From Visual St udio, Buil d -> Publi sh selecti ng Product ion | |
| 123 | 9. If any changes we re needed to be able to publis h, commit these chan ges to the hotfix br anch and t hen merge these chan ges back i nto develo p (see abo ve step fo r details) . Hopefull y, this st ep should not be nec essary. | |
| 124 | 10. Merge the hotfix branch in to `master ` | |
| 125 | * `git checkout master` | |
| 126 | * `git merge --n o-ff hotfi x-X.Y.Z` | |
| 127 | ||
| 128 | Th ere should not be an y conflict s with thi s. | |
| 129 | 11. Tag th e master b ranch with a tag of the format `vX.Y.Z`. Give it t he commit message "V ersion X.Y .Z" | |
| 130 | * `git tag -a -m "Version X.Y.Z" vX. Y.Z` | |
| 131 | 12. Push t he master branch to the remote origin, i ncluding t he new tag . | |
| 132 | * `git push --ta gs origin master` | |
| 133 | 13. Change back to d evelop bra nch to gua rd against inadverte nt commits to the ma ster branc h. | |
| 134 | * `git checkout develop` | |
| 135 | 14. Delete the hotfi x branch s ince it ha s been com pletely me rged into both devel op and mas ter | |
| 136 | * `git branch -d hotfix-X. Y.Z` | |
| 137 | 15. Notify users of updated ve rsion. Inc lude the m ost recent changes t hat are li sted in Ne ws.cshtml. (what pro tocol?) |
Araxis Merge (but not the data content of this report) is Copyright © 1993-2016 Araxis Ltd (www.araxis.com). All rights reserved.