Design: Future aspirations

WARNING

🚧 This page reflects aspirational future features of Cloudpack! 🚧

Please see the overview page and the rest of this site for the currently implemented design, and the status page for current status and plans.

Shipping and servicing

Moving code through user groups

Cloudpack servicing enables code to flow through a linear grouping of customers. This lets the most advanced users get the latest features faster, while keeping the larger user base on a more conservative upgrade interval. Shipping new updates this way gives more opportunities to back out problematic changes before the larger user base is affected.

Rolling back updates

Sometimes, shipping new dependencies ends up breaking features not covered in testing. These breaks are sometimes hard to catch. Because Cloudpack applications are reconfigurable, you can easily roll back any user group to a previous configuration in a matter of seconds, or create a new configuration which rolls back just a subset of packages.

Feature flags

Feature flags are used to enable and disable features, which is an even safer way to ship incremental changes without changing dependencies. Features built behind feature flags can be rolled out percentage based to each of the user groups progressively. If signals are fed into Cloudpack using the Signaling API, features can automatically be disabled when negative signals are detected. Changing the flags re-computes optimized builds, preventing disabled code from reaching customers and negatively impacting performance.

Enforcing compliance

While there are huge advantages of having fast inner loops and a high level of control in shipping updates to applications, this all requires that packages are built in a standard compliant way.

• They must following semantic versioning so that we don't break contracts and can upgrade without browser errors
• They must not embed webpack specifics into their code (e.g. imports to unsupported formats, require.ensure, etc)
• They must export es modules to ensure they can be bundled correctly and consumed in isolation in the browser

Cloudpack provides package linting to validate that packages are formatted in the correct way and can be upgraded. Additionally it is recommended (but not required) to use the Cloudpack build stack.

Easy dependency updates

When new versions of dependencies are available, Cloudpack can schedule updates to running your app tests against them. If your tests pass, Cloudpack can automatically upgrade your app's bundles for you. If any problems are detected, you can roll back versions automatically.

Why not just manage dependencies through a lock file?

Managing dependencies through Cloudpack gives you enormous agility to test changes and ship updates without going through the traditional friction. Traditional lock file approaches have some benefits but require many steps to go through, which becomes exacerbated when changes are required across repos.

Consider a few of the following scenarios:

Setting up an inner loop to make a change to a library

Before:

• Clone the app repo
• Clone the library repo
• Run npm link to link the library to the app repo and hope it works
• Use webpack dev server to start a local session of the app
• Debug why there are 2 copies of React in the graph

After:

• Clone the library repo
• Run cloudpack start in one or more particular packages
• Start a session with a Cloudpack-enabled app, even if you haven't cloned the app

This loads the app and all non-built resources from a cdn cache, while the package you're working on is served locally. You can also run cloudpack link in other packages to recompute the app config to load those packages locally as well.

Upgrading a dependency

Before:

• Discover new version of dependency
• Update package.json
• yarn install (updates lockfile)
• Make pull request
• Pass full CI (build the world)
• Commit changes
• Deploy new app version
• Use a deployment system to gradually direct users to new version

After:

• Cloudpack regularly monitors dependency updates available and finds something to upgrade
• Cloudpack kicks off your e2e tests with a configuration using the new dependency version
• If tests pass, enqueues an optimized build and starts rolling it through user groups