After our recent introduction
of Now + Github
, we have been hard at
work on making key improvements, such as deployment from forks and workflow improvements.
Today, we are happy to unveil the most important additions for this integration yet:
- Every push is built and deployed, not just pull requests.
- The master branches can now be auto-aliased to custom domain(s) or subdomain(s).
- PR Reverts result in instant rollbacks, due to Now's immutable architecture.
Submitting and merging a pull request with changes that are automatically deployed and aliased.
Once our GitHub App
is installed, any repository with a
file (even if
empty) will be automatically built and deployed in the cloud.
Until today, this would only happen when submitting a pull request. We are happy
to announce that effective immediately, all your pushes will be honored.
Every push is deployed automatically.
If Now needs to give you feedback about an error, such as an invalid
configuration, we will provide feedback inline with the commit:
Any obstruction to deployment will be pointed out, helping to quickly get your changes live.
now.json contains an
"alias": ["my-domain.com", "www.my-domain.com"]
When a deployment is built as a response of a push or merge to the
master branch, we will alias automatically if successful.
Let's take a look at a simple example:
With an alias configured, every push to the master branch will result in automatic deployment and aliasing.
For teams and production-critical websites, pushing to master is not always
regarded as the best practice. However, this same behavior also applies to
merging pull requests to master.
Typically, the workflow for your team will be something like this:
- A PR is submitted by an engineer.
- Every push in the PR gets its own unique, immutable and forever-available deployment.
- The rest of the team can access deployments by clicking on ✅ or the Checks UI.
- Reviewers (such as your QA team) will take a look at the code and test the website or API.
Each pull request is automatically deployed with each push, allowing you and your teammates to review the live changes instantly.
This means that if a deployment fails to be built or tested, the aliases will not be applied.
When we think about the problem of "deploying every push", we look at it from a
slightly different angle: we think of it as synchronizing the state of your branch
with the intended Now state.
Consider this example: at the same exact time, 5 different developers
working on a GitHub repository connected to Now merge 3 pull requests and force-push to master twice.
This is how our system will handle this scenario:
- The first push will start building.
- All subsequent pushes, while the last one is building, will be queued behind it.
- By the time the first one finishes building successfully, the alias will not be applied, since our system knows that it is not the final intended state.
- The most recent deployment will be prioritized, built and, if successful, aliased to your desired domain(s).
Our GitHub integration depends on the same public APIs
that we document and share
with our customers.
In any distributed system such as ours, it is accepted that all kinds of transient
failures can occur. For example, we might be able to build your project, but the API
call to perform an alias might transitively fail.
In the spirit of synchronization, we provide you with strong guarantees that we
will back off and retry the operation until the state between GitHub and your Now deployment and subsequent alias converges.
In other words, once GitHub notifies us and successfully queues the job with us,
we ensure its successful (eventual) execution.
One of the highlights of our system is that we consistently map all code and
configuration to a unique URL.
In other words, if you do not make any changes to your code and run now, we
will give you the URL for the deployment we already have.
Deployments with no difference in content to previous deployments will result in the same link to the first deployment, instantly.
This property happens to be critical when the need to quickly roll back a
Consider the following example:
master branch is perfectly in sync to Now.
- A reviewer merges a PR with a change and forgets to thoroughly verify the changes.
- When the deployment builds and is put online, you realize the application does not look good.
- You, therefore, revert the PR and merge it. In this step, the code and configuration
now perfectly matches a deployment URL Now previously had! Therefore, Now does not
need to re-create nor re-build anything, and the alias is performed in a matter
Reverting a change will result in an instant rollback.
While we are very proud of the engineering and design efforts that went into
making this set of features possible, we really want to credit our amazing
community for pushing us to get here.
Your feedback helps us make the best product and experience possible.
We think the best way to build the Cloud infrastructure we all want is as part
of an open dialogue with our customers. Please join us
and share your feedback and insight.