Building the application

Once the deployment has been triggered, the next phase is named build.
During this step, the deployment system detects the technologies used by the
application and installs everything required in order to make it runnable.

For instance, in the case of a Ruby on Rails application, the correct version
of Ruby is installed, then all the gems are downloaded using bundle and the
assets are precompiled.

This process to detect the technology and to install all its dependencies is
based on open-source tools named buildpack. At the beginning of the build, the
officially supported buildpacks
are automatically used to detect which one can be used to build the
application, they usually cover most use cases.

However it may happen your application technology is not detected, or your
application is using multiple stacks (i.e. Python + Node.js), both these cases
are also covered.

As mentioned before buildpacks are open-source and other hosting providers are
also using them to deploy applications, thus the developer community has
developed a wide range of buildpacks for almost any kind of technology. The
platform has been designed to be extended by community buildpacks, learn how
to do it here.

If a project is based on multiple language runtimes, buildpacks can be combined
to install dependencies of multiple stacks. A custom buildpack has been created
to achieve this goal: the multi buildpacks.

Rolling out the new version of the application

Once your code is built, the deployment arrives at its last step, aiming at
replacing the previous version of the application by the one which just got
built. This step ensures the platform is able to achieve
zero-downtime/rolling deployments of application. The process is the
following:

Start containers with the new version of the application

Wait them to be ready: TCPSYN are sent to web and tcp containers,
to check if the process inside them has correctly started and is listening
to the port defined by the environment variable PORT. More details about
container start operations is available here.

If a postdeploy hook is
defined, it is executed in a one-off container of the new version of the
application. In the case the hook fails, the deployment would stop and the
previous version would keep running.

Network traffic is routed to the containers hosting the new version of the
application.

Once these 4 steps have ended successfully, the deployment is considered as
successful, and the order to shutdown is
sent to old containers. They now have 30 seconds to cleanup cleanly.