12. EPMO Open Source Coordination Office Redaction File Detail Report

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.

12.1 Files compared

# Location File Last Modified
1 REFDOC-v2.1.0.zip\NVCC\Documentation ReleasePlan.html Thu Oct 19 17:36:40 2017 UTC
2 REFDOC-v2.1.0.zip\NVCC\Documentation ReleasePlan.html Wed Nov 8 16:10:03 2017 UTC

12.2 Comparison summary

Description Between
Files 1 and 2
Text Blocks Lines
Unchanged 2 500
Changed 1 2
Inserted 0 0
Removed 0 0

12.3 Comparison options

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

12.4 Active regular expressions

No regular expressions were active.

12.5 Comparison detail

  1   <h1>Steps  to deploy  a new vers ion from d evelopment </h1>
  2   <ol>
  3   <li>Make s ure you ar e on the < code>devel op</code>  branch and  are up to  date with  what is o n the remo te git/TFS  server
  4   <ul>
  5   <li>
  6   <p><code>g it checkou t develop< /code></p>
  7   </li>
  8   <li>
  9   <p><code>g it fetch</ code></p>
  10   </li>
  11   <li>
  12   <p><code>g it status< /code></p>
  13   <p>You sho uld see &q uot;Your b ranch is u p-to-date  with 'orig in/develop '&quot;. 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.</p>
  14   <p>If you  are not up  to date,  you may ne ed to do a  <code>git  pull</cod e> and pos sibly reso lve confli cts, pushi ng your re sult back  to the rem ote git/TF S server.< /p>
  15   </li>
  16   </ul>
  17   </li>
  18   <li>Branch  from <cod e>develop< /code> int o <code>re lease-X.Y. Z</code> w here <code >X.Y.Z</co de> is the  to-be-rel eased vers ion number
  19   <ul>
  20   <li><code> git checko ut -b rele ase-X.Y.Z< /code></li >
  21   </ul>
  22   </li>
  23   <li>Update  version n umber and  release da te in code  and verif y version  history
  24   <ul>
  25   <li>In NVC C.WebUI/Vi ews/Help/A bout.cshtm l, the ver sion numbe r and rele ase date a re hard-co ded near t he top</li >
  26   <li>In NVC C.WebUI/Vi ews/Help/N ews.cshtml , review t he descrip tions of t he changes  from the  previous v ersion. Th is descrip tion is in tended for  the end-u ser audien ce and sho uld be wri tten in la nguage app ropriate f or that au dience. Ev ery versio n should h ave at lea st one ent ry describ ing what c hanged.</l i>
  27   <li>Commit  these fil es to the  release br anch.</li>
  28   </ul>
  29   </li>
  30   <li>Merge  the releas e branch b ack into < code>devel op</code>  and push < code>devel op</code>  to the rem ote origin
  31   <ul>
  32   <li>
  33   <p><code>g it checkou t develop< /code></p>
  34   </li>
  35   <li>
  36   <p><code>g it merge - -no-ff rel ease-X.Y.Z </code></p >
  37   <p>Resolve  any confl icts.</p>
  38   </li>
  39   <li>
  40   <p><code>g it push or igin devel op</code>< /p>
  41   <p>Resolve  any confl icts.</p>
  42   </li>
  43   </ul>
  44   </li>
  45   <li>Back-u p the exis ting versi on on the  production  server. O pen <code> \\ DNS . URL         \ DNS . URL         </code> in  Explorer.  Right-cli ck on the  <code>NVCC </code> di rectory an d select & quot;Send  to&quot; - &gt; &quot ;Compresse d (zip) fo lder&quot; . After th e &quot;Co mpressing. ..&quot; d ialog fini shes, chan ge the res ulting fil ename <cod e>NVCC.zip </code> to  <code>NVC C_N.N.N_YY YYMMDD</co de> where  <code>N.N. N</code> i s the <em> previous</ em> versio n number a nd <code>Y YYYMMDD</c ode> is th e <em>curr ent</em> d ate in fou r-digit ye ar, month,  day forma t (without  delimiter s). (e.g.  <code>NVCC _1.6.2_201 60916.zip< /code>)</l i>
  46   <li>Deploy ment. Chan ge back to  the relea se branch  and publis h to produ ction.
  47   <ul>
  48   <li><code> git checko ut release -X.Y.Z</co de></li>
  49   <li>From V isual Stud io, Build  -&gt; Publ ish select ing Produc tion</li>
  50   <li>Any pe rmissions  needed to  be checked ?</li>
  51   </ul>
  52   </li>
  53   <li>If any  changes w ere needed  to be abl e to publi sh, commit  these cha nges to th e release  branch and  then merg e these ch anges back  into deve lop (see a bove step  for detail s). Hopefu lly, this  step shoul d not be n ecessary.< /li>
  54   <li>Merge  the releas e branch i nto <code> master</co de>
  55   <ul>
  56   <li>
  57   <p><code>g it checkou t master</ code></p>
  58   </li>
  59   <li>
  60   <p><code>g it merge - -no-ff rel ease-X.Y.Z </code></p >
  61   <p>There s hould not  be any con flicts wit h this.</p >
  62   </li>
  63   </ul>
  64   </li>
  65   <li>Tag th e master b ranch with  a tag of  the format  <code>vX. Y.Z</code> . Give it  the commit  message & quot;Versi on X.Y.Z&q uot;
  66   <ul>
  67   <li><code> git tag -a  -m &quot; Version X. Y.Z&quot;  vX.Y.Z</co de></li>
  68   </ul>
  69   </li>
  70   <li>Push t he master  branch to  the remote  origin, i ncluding t he new tag .
  71   <ul>
  72   <li><code> git push - -tags orig in master< /code></li >
  73   </ul>
  74   </li>
  75   <li>Change  back to d evelop bra nch to gua rd against  inadverte nt commits  to the ma ster branc h.
  76   <ul>
  77   <li><code> git checko ut develop </code></l i>
  78   </ul>
  79   </li>
  80   <li>Delete  the relea se branch  since it h as been co mpletely m erged into  both deve lop and ma ster
  81   <ul>
  82   <li><code> git branch  -d releas e-X.Y.Z</c ode></li>
  83   </ul>
  84   </li>
  85   <li>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?)</l i>
  86   </ol>
  87   <h1>Steps  to re-depl oy the cur rent relea se</h1>
  88   <ol>
  89   <li>Checko ut the <co de>master< /code> bra nch of the  repositor y
  90   <ul>
  91   <li><code> git checko ut master< /code></li >
  92   </ul>
  93   </li>
  94   <li>Verify  the check out is cle an and up- to-date
  95   <ul>
  96   <li>
  97   <p><code>g it fetch - -tags</cod e></p>
  98   </li>
  99   <li>
  100   <p><code>g it status< /code></p>
  101   <p>You sho uld see &q uot;Your b ranch is u p-to-date  with 'orig in/master' &quot;. Ad ditionally , there sh ould be no  modified  file or st aged files . Untracke d files ar e allowed  so long as  you are s ure they a re not nee ded to be  recorded i n the proj ect reposi tory.</p>
  102   </li>
  103   </ul>
  104   </li>
  105   <li>Deploy ment
  106   <ul>
  107   <li>From V isual Stud io, Build  -&gt; Publ ish select ing Produc tion</li>
  108   </ul>
  109   </li>
  110   </ol>
  111   <h1>Steps  to rollbac k to a pre vious rele ase</h1>
  112   <ol>
  113   <li>
  114   <p>Make su re you hav e the most  recent up dates from  the centr al reposit ory</p>
  115   <ul>
  116   <li><code> git fetch  --tags</co de></li>
  117   </ul>
  118   </li>
  119   <li>
  120   <p>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</p >
  121   <ul>
  122   <li><code> git tag -- list -n</c ode></li>
  123   </ul>
  124   <p>or more  detail (i ncluding t ag date an d message)  with</p>
  125   <ul>
  126   <li><code> git for-ea ch-ref --f ormat=&quo t;%(refnam e:short) % (taggerdat e) %(subje ct)&quot;  refs/tags< /code></li >
  127   </ul>
  128   </li>
  129   <li>
  130   <p>Checkou t the appr opriate ta g based on  its short  tag name< /p>
  131   <ul>
  132   <li><code> git checko ut vX.Y.Z< /code></li >
  133   </ul>
  134   <p>You wil l get a me ssage like </p>
  135   <pre><code > Note: ch ecking out  'v1.6.0'.
  136  
  137    You are i n 'detache d HEAD' st ate. You c an look ar ound, make  experimen tal
  138    changes a nd commit  them, and  you can di scard any  commits yo u make in  this
  139    state wit hout impac ting any b ranches by  performin g another  checkout.
  140  
  141    If you wa nt to crea te a new b ranch to r etain comm its you cr eate, you  may
  142    do so (no w or later ) by using  -b with t he checkou t command  again. Exa mple:
  143  
  144      git che ckout -b & lt;new-bra nch-name&g t;
  145  
  146    HEAD is n ow at 12ad e2d... Mer ge branch  'release-1 .6.0'
  147   </code></p re>
  148   <p>with ta gs, SHA's  and messag es appropr iate to yo ur release </p>
  149   </li>
  150   <li>
  151   <p>Deploym ent</p>
  152   <ul>
  153   <li>From V isual Stud io, Build  -&gt; Publ ish select ing Produc tion</li>
  154   </ul>
  155   </li>
  156   <li>
  157   <p>Return  your worki ng directo ry to a us able state  (<code>de velop</cod e> or what ever branc h you were  working o n)</p>
  158   <ul>
  159   <li><code> git checko ut develop </code></l i>
  160   </ul>
  161   </li>
  162   </ol>
  163   <h1>Steps  to create  a hotfix</ h1>
  164   <p>A hotfi x differs  from a reg ular relea se in that  it is an  urgent, ty pically sm all change  to the to ol. It spe cifically  is not to  include an y of the d evelopment  that has  been done  (and merge d into <co de>develop </code>) s ince the l ast releas e. Typical ly, the de cision tha t a hotfix  is needed  is made e ven before  any code  that will  go into th e hotfix i s written.  A hotfix  starts fro m <code>ma ster</code >, and its  changes w ill go bot h into <co de>master< /code> for  productio n and <cod e>develop< /code> so  that they  are not lo st in late r version. </p>
  165   <ol>
  166   <li>Make s ure you ha ve a clean  repositor y; stash a ctive chan ges on you r active b ranch, if  any</li>
  167   <li>Checko ut the <co de>master< /code> bra nch of the  repositor y
  168   <ul>
  169   <li><code> git checko ut master< /code></li >
  170   </ul>
  171   </li>
  172   <li>Verify  the check out is cle an and up- to-date
  173   <ul>
  174   <li>
  175   <p><code>g it fetch - -tags</cod e></p>
  176   </li>
  177   <li>
  178   <p><code>g it status< /code></p>
  179   <p>You sho uld see &q uot;Your b ranch is u p-to-date  with 'orig in/master' &quot;. If  you are b ehind <cod e>origin/m aster</cod e>, and ca n fast-for ward, do s o: <code>g it pull</c ode>. Addi tionally,  there shou ld be no m odified fi le or stag ed files.  Untracked  files are  allowed so  long as y ou are sur e they are  not neede d to be re corded in  the projec t reposito ry.</p>
  180   </li>
  181   </ul>
  182   </li>
  183   <li>Branch  from <cod e>master</ code> into  <code>hot fix-X.Y.Z< /code> whe re <code>X .Y.Z</code > is the t o-be-relea sed versio n number.  Typically,  this will  just be a n incremen t of <code >Z</code>
  184   <ul>
  185   <li><code> git checko ut -b hotf ix-X.Y.Z</ code></li>
  186   </ul>
  187   </li>
  188   <li>Make w hatever ch anges are  needed to  fix the pr oblem that  this hotf ix is mean t to solve . Commit t hese chang es to the  hotfix bra nch.</li>
  189   <li>Update  version n umber and  release da te in code  and verif y version  history
  190   <ul>
  191   <li>In NVC C.WebUI/Vi ews/Help/A bout.cshtm l, the ver sion numbe r and rele ase date a re hard-co ded near t he top</li >
  192   <li>In NVC C.WebUI/Vi ews/Help/N ews.cshtml , review t he descrip tions of t he changes  from the  previous v ersion. Th is descrip tion is in tended for  the end-u ser audien ce and sho uld be wri tten in la nguage app ropriate f or that au dience. Ev ery versio n should h ave at lea st one ent ry describ ing what c hanged.</l i>
  193   <li>Commit  these fil es to the  hotfix bra nch.</li>
  194   </ul>
  195   </li>
  196   <li>Merge  the hotfix  branch ba ck into <c ode>develo p</code> a nd push <c ode>develo p</code> t o the remo te origin
  197   <ul>
  198   <li>
  199   <p><code>g it checkou t develop< /code></p>
  200   </li>
  201   <li>
  202   <p><code>g it merge - -no-ff hot fix-X.Y.Z< /code></p>
  203   <p>Resolve  any confl icts.</p>
  204   </li>
  205   <li>
  206   <p><code>g it push or igin devel op</code>< /p>
  207   <p>Resolve  any confl icts.</p>
  208   </li>
  209   </ul>
  210   </li>
  211   <li>Deploy ment. Chan ge back to  the hotfi x branch a nd publish  to produc tion.
  212   <ul>
  213   <li><code> git checko ut hotfix- X.Y.Z</cod e></li>
  214   <li>From V isual Stud io, Build  -&gt; Publ ish select ing Produc tion</li>
  215   </ul>
  216   </li>
  217   <li>If any  changes w ere needed  to be abl e to publi sh, commit  these cha nges to th e hotfix 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.</ li>
  218   <li>Merge  the hotfix  branch in to <code>m aster</cod e>
  219   <ul>
  220   <li>
  221   <p><code>g it checkou t master</ code></p>
  222   </li>
  223   <li>
  224   <p><code>g it merge - -no-ff hot fix-X.Y.Z< /code></p>
  225   <p>There s hould not  be any con flicts wit h this.</p >
  226   </li>
  227   </ul>
  228   </li>
  229   <li>Tag th e master b ranch with  a tag of  the format  <code>vX. Y.Z</code> . Give it  the commit  message & quot;Versi on X.Y.Z&q uot;
  230   <ul>
  231   <li><code> git tag -a  -m &quot; Version X. Y.Z&quot;  vX.Y.Z</co de></li>
  232   </ul>
  233   </li>
  234   <li>Push t he master  branch to  the remote  origin, i ncluding t he new tag .
  235   <ul>
  236   <li><code> git push - -tags orig in master< /code></li >
  237   </ul>
  238   </li>
  239   <li>Change  back to d evelop bra nch to gua rd against  inadverte nt commits  to the ma ster branc h.
  240   <ul>
  241   <li><code> git checko ut develop </code></l i>
  242   </ul>
  243   </li>
  244   <li>Delete  the hotfi x branch s ince it ha s been com pletely me rged into  both devel op and mas ter
  245   <ul>
  246   <li><code> git branch  -d hotfix -X.Y.Z</co de></li>
  247   </ul>
  248   </li>
  249   <li>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?)</l i>
  250   </ol>
  251  

Araxis Merge (but not the data content of this report) is Copyright © 1993-2016 Araxis Ltd (www.araxis.com). All rights reserved.