Integrating Multiple project parts into one GIT repo

I've got some questions and here's the scenario:

• I've got one big Sitecore CMS website (Proj A) that has a ton of native dll's as well as custom ones that we've created to enhance funct on the site.

• The custom dlls are generated by individual VS projects (Proj B, C & D) that we manually compile and then move the finished product (dll) to Proj A bin directory.

• We currently have Proj A repositories for PROD, Integration, Public as well as every developer typically clones a copy of PROD to work features/fixes.

• Proj B, C & D are not setup under version control as of yet because we havn't found a way to easily integrate it's release into Proj A. Using the integration manager workflow, we let everyone do their feature/fix and then we merge it to an Integration repository. At this point we're ready todo the following:

  1. Recompile Proj B, C, & D
  2. Robocopy release files from each project to the Proj A bin folder
  3. Recompile/build Proj A and deploy to Integration server.

Questions:

1. Would you include Proj B, C, & 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?

2. How/when wo开发者_如何学Gould you automate the inclusion Proj B, C, & D "dlls" into Proj A bin directory.

3. Can you recommend a way that would streamline the integration of these files?

NOTE: I've researched Reps within Reps as well as submodules but not sure if i need just a hybrid of both.

Any recommendations would be greatly appreciated. Thanks and have a nice nite. foxtrotzulu

We have a similar situation with an ASP.NET Web application that depends upon other projects.

Our solution has been to create the Web application and each dependency as a separate VS solution in a separate repository, then define the repositories for B, C, D as submodules in the repository for A.

The VS solution for A includes the copies of the projects B, C, and D that are provided by the submodules, and these projects are project references in the project for A.

This solves 1 and 2 because you can just build project A in the normal way and B, C, and D will automatically be built from source and the DLLs copied into the build directory for A.

1. If you create a solution you can add your website/webproject and your other projects to this solution. if you then add references from the website/webproject to those "custom dlls" the dll's should get copied over (by default, otherwise there is an option for this iirc).

2. I would automate them if they were specific for Proj A, if they are things like internal APIs, utilities etc that all projects use, I wouldn't include them in the Proj A solution.

3. Not sure if I would recommend this way, but if you have the custom DLLs built somewhere automatically (using CruiseBuild or the like) and then committed to the repository you could add an External "update". But this could just as easily be a problem, if new changes would break Proj A often.

This is by no means a complete offer, but maybe a partial answer to your question.

Dont know if this helps anyone but just wanted to followup my own questions:

Questions:

Would you include Proj B, C, & 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?

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

1. To start a feature/fix all developers install a vanilla Sitecore and do a PULL to update there local master from PRODUCTION_STAGING
2. Checkout a local feature branch, naming it according to ticket/project. Run local updateDll.bat to pull down updated dlls.
3. Do work, commit often, test and verify
4. PUSH local master
5. PUSH to "xxxx_PUBLIC".
6. Contact Integration manager so that he/she can PULL from public to INTEGRATION_STAGING.
7. IM pulls to Integration (QA), runs local updateDll.bat, notifies dev to go ahead and test integration to Sitecore or other project
8. 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.

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

1. To start a feature/fix all developers CLONE a copy of PRODUCTION_STAGING to there local pc.
2. Checkout a local feature branch, naming it according to ticket/project.
3. 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.
4. PUSH local master
5. PUSH to "xxxx_PUBLIC".
6. Contact Integration manager so that he/she can PULL from public to INTEGRATION_STAGING.
7. IM pulls to Integration (QA), runs local updateDll.bat, notifies dev to go ahead and test integration to Sitecore or other project
8. 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.

How/when would you automate the inclusion Proj B, C, & 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:

xcopy /E /Y "\\servername\dotNetProjects\ReleaseDlls\*.dll" C:\development\sitecore\WebSite\bin

NOTE:

• Steps 4-8 are identical above, the editor was giving me a headache so I just left the redundancy.

• 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.