I need to update a software framework once it has been deployed.
The framework we are creating is made up of .NET 4.0 libraries (in Visual Studio). This common set of code libraries will be available for 2 .NET Windows services, a standalone .NET application, and a .NET MVC 4 website. (The services will run on a single server, and the standalone application will be used by a select few individuals.)
We are in the early stages of the project, and the big questions that have come up are:
- What happens when we have to make a change to 1 or more of the framework files?
- How do we deploy patches and/or updates to each part that relies on the framework?
- What considerations can we make early on to make the update/patching process easier later on?
This is the first time our small team has tackled a problem like this and we’re not sure what the best practices are.
edit
We have 4 software pieces that rely on the framework: 2 services, 1 app, 1 website. Once this all hits production, there are already upgrades and updates planned. The updates will require changes to the framework files and the programs. My question was intended to refer to that later process of redeploying the upgrades. Once we’re in production, and we’ve coded the updates/upgrades to the framework files, the applications, and the website, deploying those updates will need to happen as quickly as possible. What do we need to do to streamline that process?
Edited to reflect comments:
For development you want Nuget…
You can easily run your own nuget repository (can be a folder, TeamCity has one built in, etc).
Build the libraries with a self contained suites of tests, use semantic versioning, update and deploy at will – semver and the nuget systems will give you enough control to avoid updates you want to defer for a given application.
The rest hangs off standard good practice – automate your deployments up front (ideally be able to spin up desired state for your servers automatically), run a build server, automated tests at many levels… it should then all “just work” (-:
So – following comments – the key in the above is automate your deployments. For websites this is generally not particularly hard, there are a wide variety of options (I have had success with WebDeploy but my needs are not complex). For applications you can look at ClickOnce or variations thereon (or at things like windows store apps that are geared to automated updates). the services are probably the hardest to automate deployment for, but again there’s scope within MSDeploy as well as other systems. The other big issue tends to be database schemas – but migrations (that’s the key word!) can be automated so its not a show stopper and if you start on the basis that your schema changes are automated then you’ll have a high level of confidence in any given instance of that schema being what you expect it to be.
The more you’re able to automate your deployment processes up front the less stressful the whole process is liable to be (because its trivial to set up a test/qa/staging environment) – especially if you remember to regularly test both clean deployments and updates.
Again I have to confess to being a some way from this happy state for some of the stuff I look after – but that’s kinda why I understand the desirability of getting there.
1
For production you want to use Windows installer – MSI – files.
Once its installed correctly, you can use patch installation file to update (msp files).
The Windows Installer site has a whole heap of information on patching and upgrading.
I’d use Wix to create the installer files in the first place.
3