Working with large packages
skycaptain
Posts: 21
We have managed to craft Redgate DM to do what we want. However, some of our packages are large (700MB). This has 2 side effects on our deployment:
1- Failure to load package version numbers from package feed as package feed request timed out. Although we have some scripts to keep the packages feed clean and tidy at all times.
2- Upload packages to target machines step, takes a long time top just copy the files from the server to the client. Just to give an idea. Deploying a 700MB packages to 13 machines takes between 30 and 43 minutes.
We are currently looking into setting up a separate NugetServer but would definitely appreciate and help/ suggestions or similar experiences.
1- Failure to load package version numbers from package feed as package feed request timed out. Although we have some scripts to keep the packages feed clean and tidy at all times.
2- Upload packages to target machines step, takes a long time top just copy the files from the server to the client. Just to give an idea. Deploying a 700MB packages to 13 machines takes between 30 and 43 minutes.
We are currently looking into setting up a separate NugetServer but would definitely appreciate and help/ suggestions or similar experiences.
SkyCaptain
Comments
First of all I would check why your package is so big, do you include static content such as pictures or files that do not change frequently and could instead be stored on a share? This could have positive performance implications as you could cache these static files very easily once they are separated.
If the file is large because of static data, considering using backups instead, with an after deploy powershell script to restore them.
Second, our package feed is not designed for large packages, or a large number of packages, so you could replace it with a more robust feed that might be better for your needs.
(http://documentation.red-gate.com/displ ... kage+feeds)
Lastly, you could optimise your network infrastructure by using fast storage and having the packages stored on a machine that is connected via a fast connection to the place you will deploy it. This is the last resort option, because improving your hardware and networking may only make a small difference.
We could reduce the size of our packages (a little) but the issue wouldn't have been resolved. I was just thinking there may be other solutions we didn't think of. Infrastructure! unfortunately isn't an option !.
However, replacing the feed does sound like a good approach.
Thanks very much for your help.
Could I ask why your packages are so big? What do they contain? I might be able to help more if I knew more about what you're packaging and deploying.
Sean