Lighter deployments mean faster workflow
When you deploy an application on Scalingo, the first step you’re dealing with is the build:
During the “Build” step, our deployment infrastructure is detecting the language and frameworks you are using. This step is based on open-source buildpacks. According to the chosen buildpack, the runtime and the dependencies of your application are installed. They are either gathered from the Internet or fetched from our local caches.
Then, from all the files composed by your application, the runtime of the technology you’re using and the dependencies of your app, an application image is built. This is basically a docker image which has the specificity to be composed of only one layer. This image is stored in a private docker registry. It is now ready to be used by the nodes selected by the orchestrator service. All the nodes fetch the image in order to execute your application on their own and start the correct process(es) for it.
As stated in this description, the image is the piece of data which is moving around in our internal network to allow each node of the cluster to execute your applications. So there is one important thing to understand: the lighter your image, the quicker your deployment.
How to ensure that your image stays small:
- If you have a large amount of static assets, upload them to an external provider like Amazon S3 or OVH RunAbove Storage, then clean them from your application
- Create a
.slugignorefile to exclude files from the image (documentation). For instance all the build dependencies which have been installed alongside your application. If your Java application has built a ‘.war’ file, you don’t need to keep all the unpackaged ‘.jar’ files in the image. - Do not keep unused dependencies. As dumb as it sounds, the amount of applications with dead dependencies is important. When you stop using an external dependency, remove it from your app through your dependency manager.
Those practices will help you to get a smaller image. It means, less bytes to transfer from server to server, and then, a faster deployment process. From this speed and operation repeatability, you won’t hesitate whether you should deploy your application now or after the next feature. Just do both and adopt continuous delivery.
