My favorite part of the manual description is step 7 onwards: switch to another machine to upload compiled package, really!?

And yeah - great job, Adam! If someone still building and deploying desktop applications manually - they are doing it wrong. Since when Visual Studio switched to MSBuild (read: ages), build automation is _very_ easy on Windows.

Yuuuuup. Transmit.app is the only app I knew of that would let you set MIME types on upload, which is required by ClickOnce. That being said, I didn't look very hard.

Could something like CloudBerry's S3 PowerShell snap-in set the MIME type?

http://www.cloudberrylab.com/default.aspx?page=amazon-s3-pow...

I would be far more interested in how the auto-update process works rather than hearing that someone automated their build. Would be way-crazy-awesome if they could pull it out and release it open source, but they seem to be leaning on it as a pretty serious part of their secret sauce.

Here's how we do it:

https://gist.github.com/3777989

The only other "Secret Sauce" is that you have to disable checking for updates at startup in the ClickOnce settings.

They are currently using ClickOnce for the auto-update mechanism but you may find these interesting:

https://github.com/github/Shimmer

https://github.com/synhershko/NAppUpdate

Thanks. I haven't looked at ClickOnce in a long time, interesting to hear it is a viable solution for commercial apps. For example, did not know it could update in the background for next run of the app.

It really isn't, which is sad, because it's like 95% Awesome and 5% Showstopper Bugs. Here's the most damning aspect of it: if you sign your ClickOnce application (which you are required to or else ClickOnce's installer displays scary "Don't Install This" messages), then the cert expires, every user has to uninstall and reinstall. Completely untenable. http://github.com/github/shimmer is our plan for the future.

Thanks for this reminder... documenting how to cleanly transition from ClickOnce to shimmer would be a spectacular resource.

I can't seem to find the source anywhere on GitHub for "GitHub for Windows". I work on a build team (Mostly MSBuild but transitioning to Workflow builds in the future) so I'm always interested in seeing everyone's Build and Deploy scripts.

GitHub for Windows is not open source.

Can you expand on what you mean by "Workflow builds"?

The Windows app for Github is pretty spectacular. Simple, beautiful and to-the-point.

I don't see anything in the automated release script's output about the "sanity test on XP and Vista VMs" steps? Is that still manual?

I have a paid GitHub subscription, and this is the first I've heard of GitHub for Windows.

It got fairly big attention here, and every Github page I visit has a button to launch a clone via Github for Windows. Can't remember if an email was sent out though.

Pretty much par for the course of releasing any Windows app. :)

But a good overview none the less.

You're saying that one release per week is par for the course for a Windows app? Sounds like you're selling the GitHub team short.

There's nothing novel about automating builds or pushing them out and letting an auto updater deal with them.

This is par for the course. Welcome to software 101.

They ship once a week? Great. What does that actually tell you? Almost nothing. We know nothing of why they're shipping once a week. It's not relevant, because it's not a metric that matters.

    We know nothing of why they're shipping once a week.

You might not, but someone who read the article would know:

"Shipping rapidly is important to us for so many reasons. For example, the more frequently we ship the less likely it is for large numbers of changes to build up between releases, and shipping a small release is almost always less risky than shipping a big one. Shipping frequently also requires that we make it downright simple to ship by automating it, so anyone can do it. This raises our bus factor, and also democratizes the process of shipping so there aren’t “gatekeepers” who must sign off before any software goes out the door. And by shipping updates so often, there is less anxiety about getting a particular feature ready for a particular release. If your pull request isn’t ready to be merged in time for today’s release, relax. There will be another one soon, so make that code shine!"

I don't think anything their doing is particularly novel, but I don't think it's par for the course, either. I may be wrong, but I don't think this is commonplace among Windows desktop apps. I can think of a few others, but the vast majority of examples don't have this kind of release automation.

Welcome to software 101

Maybe you didn't mean that as dismissive and rude, but it sure comes across that way. We can do better than this.

I think a new rule for snarkiness is in order: if you crap on anyone else's accomplishment you must also link to examples of your own awesomeness in the area so everyone can learn.