Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Dont know if this helps anyone but just wanted to followup my own questions:</p> <p>Questions:</p> <p>Would you include Proj B, C, &amp; D in the directory structure of Proj A? If so, when compiling each project, would you make the release directory for the each project the Proj A Bin directory?</p> <p>We decided to keep proj A (Sitecore web) as a separate repository inside a Sitecore rCS folder. This folder contains repositories and a DLLs folder: dlls dev1_PUBLIC dev2_PUBLIC dev3_PUBLIC INTEGRATION_STAGING PRODUCTION_STAGING</p> <ol> <li>To start a feature/fix all developers install a vanilla Sitecore and do a PULL to update there local master from PRODUCTION_STAGING</li> <li>Checkout a local feature branch, naming it according to ticket/project. Run local updateDll.bat to pull down updated dlls.</li> <li>Do work, commit often, test and verify</li> <li>PUSH local master</li> <li>PUSH to "xxxx_PUBLIC".</li> <li>Contact Integration manager so that he/she can PULL from public to INTEGRATION_STAGING.</li> <li>IM pulls to Integration (QA), runs local updateDll.bat, notifies dev to go ahead and test integration to Sitecore or other project</li> <li>If test is verified, IM will schedule PULL to PRODUCTION and run local updateDll,bat. If Production is good, IM will PULL changesback down to PRODUCTION_STAGING so that a fresh copy is ready. </li> </ol> <p>We decided to have proj B, C and D (C# components) have their own repository per project inside a dotNetProjects folder. Each project folder contains a number of repositories: dev1_PUBLIC dev2_PUBLIC dev3_PUBLIC INTEGRATION_STAGING PRODUCTION_STAGING</p> <ol> <li>To start a feature/fix all developers CLONE a copy of PRODUCTION_STAGING to there local pc.</li> <li>Checkout a local feature branch, naming it according to ticket/project.</li> <li>Verify output folder for project points to "releasedlls" folder in dotNetProjects projects. Do work, commit often, test, verify and build project. verify dll datetime stamp. </li> <li>PUSH local master</li> <li>PUSH to "xxxx_PUBLIC".</li> <li>Contact Integration manager so that he/she can PULL from public to INTEGRATION_STAGING.</li> <li>IM pulls to Integration (QA), runs local updateDll.bat, notifies dev to go ahead and test integration to Sitecore or other project</li> <li>If test is verified, IM will schedule PULL to PRODUCTION and run local updateDll,bat. If Production is good, IM will PULL changesback down to PRODUCTION_STAGING so that a fresh copy is ready. </li> </ol> <p>How/when would you automate the inclusion Proj B, C, &amp; D "dlls" into Proj A bin directory? Output folder for each project is set to dotNetProjects/releasedlls folder which is not a repository, just a folder to house dll related to SItecore. Developers adding features/fix to sitecore must run updateDll.bat locally to get the newest version of the dll. Here is the simple script:</p> <pre><code>xcopy /E /Y "\\servername\dotNetProjects\ReleaseDlls\*.dll" C:\development\sitecore\WebSite\bin </code></pre> <p>NOTE: </p> <ul> <li><p>Steps 4-8 are identical above, the editor was giving me a headache so I just left the redundancy.</p></li> <li><p>With all the dlls involved, in regards to Sitecore, we still wanted to gitignore dlls because it could be a headache for our business users. So to maintain dlls as an ignored file our workaround is the quick fix above. This is not what we'd like it to be but if it works for you, use it, if not, disregard.</p></li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload