Just read “CoApp: An open-source package management system for Windows”.
I really respect what CoApp is trying to do. It can be amazingly difficult, and tedious, to deploy various applications types on the Windows platform. Its not like the problem hasn’t been solved. Its unfortunately been solved too many times, by too many.
Of course, anytime you have something amazingly tedious and difficult it needs to be automated. The Windows platform has needed this forever.
Unfortunately, what Windows users got, at least for the desktop, was Windows Installer technology. I never really liked this technology, for a variety of different reasons, but the biggest problem I have with them are that I just don’t care. I don’t care to see your company’s logo, I don’t care to see a progress bar going across the screen, I don’t care to plug in options – I just don’t care. I got frustrated that it would take someone with a PhD in Windows Installer technology to be able to produce a package you could install.
There have been advancements recently, most notably MSDeploy, that seem like they should be able to fit the bill, but they still seem focused on web projects only. I still have hopes for an extensibility model for MSDeploy that is something we can build on. The Web Platform Installer is also a huge step forward – again, would be nice if it were opened up, which is where I think CoApp might come in.
You know your data center operations teams have also solved this problem of packaging, deployment, and dependency management, but its still likely to be focused on a couple of notable application types: web applications and Windows services.
I work for corporate America - which has a plethora of bad practices, some I probably perpetuate, and many I'm not proud of, but every once and a while we go and do something worthwhile. For us, it was the development of PANDA. PANDA, Packaging and Deployment Automation, is as much process as it is actual tooling.
PANDA actually started with the requirement of a repeatable deployment for web sites, windows services, click once applications and just basic file copies. To solve this problem, we chose to rely heavily on convention, with a sprinkle of configuration metadata.
The idea of a PANDA ‘package’ was born, and that package had a specific structure. In addition, it was decided that all applications would have specific target locations, based on conventions set by our operations team. A PANDA package, being heavily file centric, might look like this:
- /WindowsServices/{service}
- /Web/{website}/{virtual root}
- /ClickOnce/{app}
- /Config
- /Workflows
- /Files/{bucket}
This package structure, combined with some magical application metadata, would allow us to write generic MSBuild scripts that would simply know how to execute what was in the package. Samples of application metadata for a Windows service might be:
- service name
- display name
- service account
- executable
- startup type
- restart properties
The Windows service developer would include in their project, not an Installer project, but simply an xml file with a well known schema – a .deploy file. In this case, it would be service.deploy. Changing any of the properties of the service simply meant modifying the service.deploy file and executing the deployment. The actual application code didn’t need to be recompiled each time.
Other application types would have their own metadata schema.
This PANDA package is then what all of our software builds produce. We use Team Foundation Server, but instead of regular output from a build, build output gets rolled into a PANDA package. If a developer needs to install those bits, either on their local machine, or a server, the experience is the same – they execute the deploy.bat found in the package.
Assuming that the deployment package had a consistent structure, we then built MSBuild targets that knew how to install whatever happened to be in the package. Our deployment tools, and scripts, really just reused some community task libraries and a single custom library that was essentially a data access layer for our PANDA package.
The overall execution of the deployment had just a few high level MSBuild targets:
- PreDeploy – users could provide their own MSBuild scripts, following the convention of *.predeploy and PANDA would execute them
- StopServices – can’t copy over files in use
- CopyFiles – a top-level target that….copies files, it actually chains together other file copy operations
- CopyConfig, CopyServices, CopyWebs,CopyClickOnces,CopyWorkflow
- Uninstall Services – it was easier to uninstall services
- Install Services – since we uninstall, we pick up any changes to metadata (e.g. service name)
- Start Services – respected the startup type in service metadata
- PostDeploy – users could provide their own MSBuild scripts, following convention of *.postdeploy
Each target was smart enough that if there was nothing in the package that matched its criteria, then it didn’t do anything. And that's it. The MSBuild scripts just know how to execute the package, which has a consistent structure.
Here is the breakdown of *.deploy files:
- service.deploy – metadata for Windows services
- site.deploy – web site metadata
- apppool.deploy – app pool metadata
- webapp.deploy – virtual directory metadata
- clickonce.deploy- click once metadata
- files.deploy – files manifests. Only required for copying files that didn’t already fall into an application archetype – usually one off
A PANDA package could contain a single file, or single set of application components, or it could contain and aggregate of many application components, or indeed entire systems – all in a single PANDA package that has a one click installation (deploy.bat).
Other features of PANDA (not exhaustive):
- application metadata can specify arbitrary target server role (e.g. ‘web server’, ‘app server’, ‘mylabenvironment’), so application bits only get copied and installed if target server role matches
- environmental overrides – e.g. use different service account name for DEV, QA, Staging and Production environments.
- use of hashed passwords – we request provisioning of service accounts by our security group. We don’t actually receive a password, but the hash. PANDA will decrypt the hash and install using actual accounts. Passwords aren’t in the open and developers could care less what the actual value is.
Some notable PANDA shortfalls:
- PANDA packages are not zipped. We have the actual step to insert into the packaging process to zip up the bits, we just aren’t using it because we are blessed with near infinite bandwidth in our data centers.
- PANDA tools need to be deployed to any server, or desktop, prior to attempting to execute a PANDA package. We would like to eventually include the tools required for THAT package version
I didn’t realize I had typed this much until just now.. My intention was not really to toot the horn (toot! toot!) on PANDA – rather pointing out the need to have roll something like PANDA at all.
Granted, PANDA is in its infancy. My preference is that it stay there and not any more time be spent on enhancing it. It meets the current needs of several different teams. I’d rather it was killed off by something supported by either Microsoft, or the community – we don’t want to maintain it indefinitely, but probably would with no other choice. I’ve often thought about approaching our management team about releasing PANDA into the community in hopes it would gain support there.
Would anyone else use something like PANDA?
