Increasingly, vendors understand that the inability to rapidly deploy their products affects the customers’ ability to rapidly purchase their products.
(quoted from Page 152 of The Practice of System and Network Administration, Third Edition)
I believe I first wrote that quote in 1999 when the first edition was still in draft form. That was 20 years ago. I’m embarrassed to say that in the last month I’ve had to remind two different vendors of this fact.
Any vendor that thinks automated installation is a new concept… sigh.
So what does that have to do with Chocolately?
Chocolatey is a package manager for Windows (like yum or apt-get but for Windows). It isn’t a package format, it is a wrapper that encapulates how to install software no matter the package format.
It is relatively new, but Microsoft officially supports Chocolately in NuGet as a first-class citizen. Adoption rates are going through the roof.
If you use Windows and don’t use Chocolately you are working too hard. Chocolately should be required for any software that would run on more than 5 machines, and certainly any “endpoint” software that is expected to run on all or most machines in your environment.
Which brings me to….
My expectation for Windows software:
- The Windows version will have a Chocolately feed
- The Chocolately feed will be maintained by the vendor and will be properly updated for each release
- The vendor will maintain an open source module for installing and configuring
the software using one or more of: Chef, Puppet, or Anisible.
- It doesn’t need to be all three; any one will do. Why? Because if any one such module exists, that means that the software can be configured through automated means. I use Puppet, which I admit isn’t as popular as it used to be. If there is a Chef module (recipe?), I can steal from it when I write my Puppet.
- Why should the vendor provide the module? One supported module draws all the innovation to it. It prevents the situation where there are dozens of shitty open source implementations.
- Why open source? Because there is a lot of “fit and finish” that will only come from a community effort. Some of those innovations will be weird things that the vendor could never possibly have expected: like fine-tuning it so that it works on machines with multiple NICs but you only want it to listen to one of them. Yeah, that’s weird, but if you need that feature, you need that feature.
- The Chocolately feed will be considered part of the testing and release process, not an after-thought
Oh, and let me add…
- The Chocolately feed should not be maintained by a non-employee or other open source contributor that lags months behind the official release cycle
- The vendor shouldn’t give a confused look when I ask if their endpoint software can be installed using Chocolately. They will not say things like “Oh, we haven’t gotten many requests for that”. You just spent 5 slides telling me how cutting edge you are. You blew it if you tell me that Chocolately is too “new”. You claim to be an innovator? Then lead by example.
- If you are a vendor in the “infrastructure” or “devops” space and you give a confused look when I want to automate something as basic as software installation, you’ve failed.
This year you might look like a leader for using Chocolately. Next year you’ll look like a fool for being behind.
You can learn more about Chocolately at the website: https://chocolatey.org
I’m not a Chocolately expert to guru. I just manage an SRE team that is a lot happier now that Chocolately exists.
