Hello. I am a Build Engineer for our company, and am really liking NuGet and am currently configuring a private server to help our development teams manage our internally shared libraries, as well as plans to use it to manage third-party libraries we are currently track in our SCM. I love that I could potentially not have to check in those binaries, yet still be confident I'm getting the right version of a package. Still, from my Build Engineering in an Enterprise standpoint, I have some concerns I would like to give to your development team for consideration on possible future improvements.
First, in our corporate Enterprise environment, we can't let the developers use any third-party library they come across. There are legal issues if we use something in our money-path so we have to go through an approval process. Plus we don't want 5 ways of doing the same thing floating around so we like to limit what functionality those libraries provide. But at the same time, we want to allow our developers to explore new packages, finding new and better ways of doing things. Basically we need some management, and some way to track approval levels of the packages that are available.
It would be nice if there was some way of either proxying the public server and allowing a local management group to configure which packages are approved for local use-levels, or a more dynamic, updateable private server that had some level of controlled automatic updating. We would like to give our developers access to all packages for exploration and research, but we also need to let them know what packages are approved for internal, company use. Finally, on the official build servers, we would then want to block access to non-approved packages so accidental submission of exploration to the SCM won't accidentally build with those non-approved packages.
In my implementation, I will have to manage this by informing developers that they should be looking at our private server for approved packages. I will have to grab the approved thirdparty packages off the public server and repost them on the private server. Then on the official build machines, I'll have to do something like blocking nuget.org in the hosts file to keep accidental inclusion of non-approved packages from slipping through.
For the next issue, I like the .nuget Project that allows for package updating at the start of a Visual Studio solution build process, but I would like to also be able to manage the version of the nuget.exe in this operation to match the proxy or private server above, without checking in the individual .exe's for each solution that uses nuget. I would be nice if the .nuget creation would create the .target file in a way that was Enterprise-configurable to point to the company's choice of public or private server, including the location to update the nuget.exe from. We could use registry entries, and manage them with group policies, as our developer's use MSDN to get their Visual Studio installs, so I can't do much about unattended install scripting.
I will have to add to the official build script a process to reconfigure the .target file to point at the internal server, and to grab the updated nuget.exe from that same internal server. This way, I can update the nuget.exe and the NuGet private server at the same time to make sure they keep up with each other. It would be nice if I could globally, in an Enterprise way, manage this update mechanism.
Finally, only in the case of a private server that I have to maintain the updates on, it would be nice to have a way from the public server to get the list of changes (yes, like a Continuous Integration build), and decide if I need that newer version of that changed package. If I have users that want version X of a package or newer, and we have approved the license, then it would be nice if we could work that out to automatically grab the newest version from the public server.
Also, it would be nice to know if a package's licensing has changed, so that we know if it needs to be re-authorized by our legal department. Then we could include a new version of a package as long as the license didn't change, allowing developers to specify 1.0+ for the version requirement, if they so choose.
Thank you for your time and your consideration. Please contact me if you would like further clarification on any of the points I have tried to make.
First, in our corporate Enterprise environment, we can't let the developers use any third-party library they come across. There are legal issues if we use something in our money-path so we have to go through an approval process. Plus we don't want 5 ways of doing the same thing floating around so we like to limit what functionality those libraries provide. But at the same time, we want to allow our developers to explore new packages, finding new and better ways of doing things. Basically we need some management, and some way to track approval levels of the packages that are available.
It would be nice if there was some way of either proxying the public server and allowing a local management group to configure which packages are approved for local use-levels, or a more dynamic, updateable private server that had some level of controlled automatic updating. We would like to give our developers access to all packages for exploration and research, but we also need to let them know what packages are approved for internal, company use. Finally, on the official build servers, we would then want to block access to non-approved packages so accidental submission of exploration to the SCM won't accidentally build with those non-approved packages.
In my implementation, I will have to manage this by informing developers that they should be looking at our private server for approved packages. I will have to grab the approved thirdparty packages off the public server and repost them on the private server. Then on the official build machines, I'll have to do something like blocking nuget.org in the hosts file to keep accidental inclusion of non-approved packages from slipping through.
For the next issue, I like the .nuget Project that allows for package updating at the start of a Visual Studio solution build process, but I would like to also be able to manage the version of the nuget.exe in this operation to match the proxy or private server above, without checking in the individual .exe's for each solution that uses nuget. I would be nice if the .nuget creation would create the .target file in a way that was Enterprise-configurable to point to the company's choice of public or private server, including the location to update the nuget.exe from. We could use registry entries, and manage them with group policies, as our developer's use MSDN to get their Visual Studio installs, so I can't do much about unattended install scripting.
I will have to add to the official build script a process to reconfigure the .target file to point at the internal server, and to grab the updated nuget.exe from that same internal server. This way, I can update the nuget.exe and the NuGet private server at the same time to make sure they keep up with each other. It would be nice if I could globally, in an Enterprise way, manage this update mechanism.
Finally, only in the case of a private server that I have to maintain the updates on, it would be nice to have a way from the public server to get the list of changes (yes, like a Continuous Integration build), and decide if I need that newer version of that changed package. If I have users that want version X of a package or newer, and we have approved the license, then it would be nice if we could work that out to automatically grab the newest version from the public server.
Also, it would be nice to know if a package's licensing has changed, so that we know if it needs to be re-authorized by our legal department. Then we could include a new version of a package as long as the license didn't change, allowing developers to specify 1.0+ for the version requirement, if they so choose.
Thank you for your time and your consideration. Please contact me if you would like further clarification on any of the points I have tried to make.