Simplify continuous deployment with Project Nebula

Interesting new product (Beta) from the Puppet folks:

Project Nebula automates continuous deployment of applications to multiple cloud-native targets. Our objective is to dramatically simplify continuous deployment of cloud native applications and infrastructure by composing the tools and workflows your developers already use into simple, repeatable deployment workflows.

Project Nebula →
Simplify continuous deployment with Project Nebula →

Wombat Dressing Room, an npm publication proxy on GCP

When automating the publishing of an NPM package, 2FA can get in the way, as you can’t really automate entering a 2FA auth code off a cellphone. Enter Wombat Dressing Room from Google:

With Wombat Dressing Room, rather than an individual configuring two factor authentication in an authenticator app, 2FA is managed by a shared proxy server..

  • You publish to Wombat Dressing Room, and it enforces additional security rules, before redirecting to
  • Publishes are made from a single npm account with 2FA enabled (a bot account).
  • Publishes can be made using the npm CLI, by making Wombat Dressing Room the default registry (npm config set registry

The Wombat Dressing Room is deployed to Google App Engine. They’ve been using it themselves internally for over a year, in case you were wondering if it is “production ready”.

Wombat Dressing Room Introductory Post →
Wombat Dressing Room Proxy Source (GitHub) →

On release cycles and deprecating stuff

From “What Really Happened with Vista: An Insider’s Retrospective” by Ben Fathi:

The three year release cycle meant we rarely knew what the competitive landscape and external ecosystem would look like when we started a release […] What we thought we knew three or four years ago when we planned a given OS release was laughably outdated and sometimes flat out wrong when the product finally shipped.

The best thing we could have done was to enable incremental and friction-free delivery of new cloud based services to an ever-simplifying device. Instead, we kept adding features to an existing client-based monolithic system that required many months of testing before each release, slowing us down just when we needed to speed up.

This is precisely what I love about the web: you can have multiple releases on a (more than) daily basis, pushing out small incremental changes.
The end user always has the latest version.

Thankfully we’ve also moved this way when it comes to software: things like evergreen browsers which update themselves, and automated build pipelines continuously delivering changes to your test and end users (think of your Facebook/Instagram apps updating on a bi-weekly basis) are common nowadays.

When it comes to an OS and/or software libraries it becomes more complicated though. As Ben put it:

We didn’t dare remove old pieces of functionality which were needed in the name of compatibility by applications already running on previous releases of Windows.

I especially like how the React team is handling these kind of breaking changes: a feature is first marked as deprecated for 2 release cycles before it is actually removed, giving you – the developer using it – the time to adapt:

Of course it’s not really fair comparing OSes to React: developers using React can opt-in to upgrade to a new version. When it comes to an OS it’s the user – not the developer – that decides to upgrade or not. However, if you’re making software for a living you should prepare yourself for things like this (knowing that breaking changes in OSes are prevented as much as possible) and build things as Future Friendly as possible.

Did this help you out? Like what you see?
Consider donating.

I don’t run ads on my blog nor do I do this for profit. A donation however would always put a smile on my face though. Thanks!

☕️ Buy me a Coffee ($3)

Update React Native apps in production with AppHub Deploy

Use git push to instantly update React Native apps in production.

Your JS Bundle gets store on the AppHub servers. Upon launch AppHub’s iOS library detects updates and swaps in new code and images.

[AppHub setApplicationId:@"APPLICATION_ID"];
NSBundle *bundle = [AppHub buildManager].currentBuild.bundle;
NSURL *jsCodeLocation = [bundle URLForResource:@"main"

AppHub Deploy →