1

I am trying to do a nightly package integration with one of our projects that consumes 6 other internal teams’ -PreRelease packages.

Background Info

  • We have our own internal ProGet Server that hosts only our company packages.
  • Package IDs are in the format of: MyCompany.Project.Component
  • We have VS2015 Enterprise ($$), so our build system only has the VS 2015 Build tools installed.
  • We use CruiseControl.NET ( will be going to TFS later this year )

My integration script ( Powershell ) is something like: 

#Restores all the packages 1st
nuget restore ( Get-ChildItem $Dir -filter *.sln –Recurse ).FullName 

#Gets all the packages.configs
foreach ( $PackageFile in (Get-ChildItem $RepoDir -filter packages.config -Recurse).FullName )) 
{ 
    #Gets all the packages
    nuget list $PackageFile  

    #Filters my companies packages
    | Select-String -Pattern 'MyCompany.*' –AllMatches 

    #Removes package version and only gets the package ID
    | % { [regex]::Split($_, " ")[0] } 

    #Updates the packages
    | Start-Process nuget -ArgumentList "update $PackageFile -ID $_ -Source MyCompnySrc’s –Prerelease –verbosity detailed" -Wait –NoNewWindow
}

Then build the solution, execute unit/integration tests then either check in the new package.configs or report there are some breaking changes.

I thought about splitting MyCompany’s packages into a separate package config but thought it would be wiser to get advice before restructuring all the teams repo’s, and implementing this on other projects.

I am new to Release Engineering and have that feeling I am making this too complicated

gnat
  • 21,442
  • 29
  • 112
  • 288
Flightdeck73
  • 119
  • 1
  • Are your Nuget packages ever distributed to the public? Because if they're not, the added complexity exceeds the benefit, and you can just get rid of them. – Robert Harvey Jan 29 '16 at 15:30
  • No our packages are internal only. They biggest issue is at the end of the sprint Project E always busts because of some change in packages from our A, B, C ... projects. Then we run around for a few days with our hair on fire. What would you recommend i do differently. – Flightdeck73 Jan 29 '16 at 16:32
  • btw we also have alot of packages from nuget.org and i dont want to update those – Flightdeck73 Jan 29 '16 at 16:36
  • Use Nuget for external packages only (things like Entity Framework, etc). Ditch Nuget for your internal packages and just use DLL and project references instead. When your other developers get new changes from source control and build, their DLL references will update automatically. – Robert Harvey Jan 29 '16 at 20:34
  • 2
    Robert, I couldn't disagree with you more. I lived with a 200+ project solution with DLL references everywhere. To call updates anything less than hellish is an understatement--you can't make breaking changes without also fixing the entire system. NuGet may be a lot of work, but it tends to enforce more order and protects your end projects from extreme volatility. Each package had its place and each consumer can update in their own cadence (which, admittedly, does open another can of worms). – mgw854 Feb 05 '16 at 04:37

0 Answers0