Towards our mission to be the fastest development tool for Kubernetes.
Although this is just a minor update, I wanted to provide some insights into a discussion that is ongoing among DevSpace maintainers and users for quite some time. It circles around the question:
When to rebuild an image and when to skip rebuilding during development?
devspace deploy, DevSpace checks if image-building can be skipped to speed up the deployment process. To skip image-building, two conditions have to be met:
- The Dockerfile (default:
./Dockerfile) has not changed since the most recent build process.
- None of the files within the context root folder (default:
./) has changed since the most recent build process.
If these conditions are met, DevSpace will skip rebuilding the respective image. This saves valuable time but is not enough for development using
devspace dev. However, during development using the code-synchronization feature of DevSpace, it is obvious that when editing source code files, the context of the image is constantly changing. When a developer stops
devspace dev and has to restart it again (e.g. after getting lunch, after participating in a meeting or simply at the beginning of the next workday), the context will look different than when the developer ran
devspace dev previously. If an image is fairly complex and takes 5 minutes to build even when layer caching is used efficiently, the developer is losing valuable time. This may look like a small number of minutes but when multiplying this by the number of developers in an organization and by the number of interruptions throughout the workday, the total amount of hours wasted throughout a month can be quite significant.
Rebuilding images is especially annoying when your deployments are actually up-to-date because the pods are still running and DevSpace has kept the file-system of the containers in sync via file-synchronization. In this case, running
devspace dev would often trigger an image rebuilding process which is entirely unnecessary because even though the image is out-of-date, the container file system is up-to-date already (or it will be after the code-synchronization has been running for a couple of seconds).
Initial Solution: Always Skip Image-Building
To save developers a ton of time, we changed the dev workflow in v4.0.0, so that images will only be rebuilt when explicitly running
devspace dev with the
-b / --force-build flag. This flag tells DevSpace to rebuild all images. However, from user feedback, we realized very quickly that this could be an issue as well, especially if you have some images which are rather static and others that are used in containers with file-synchronization enabled.
Imagine a scenario where you have two images which both take 8 minutes to build. One of them needs a configuration file which loaded during container startup and the other one is the main application image which is used in a container with file-synchronization. The latter is built once and then the deployment is kept up-to-date by using the code-synchronization. The other one, however, cannot use the code-synchronization because the configuration file is loaded at container startup, so updating the file inside the already running container would not change anything. For this rather static image, it would be better to rebuild it when running
devspace dev if the context (in this case: the configuration file) has changed. However, with the renewed behavior of v4.0.0, DevSpace would only rebuild the image when providing the
-b / --force-build flag but using this flag would result in both images being rebuilt instead of just one, which is obviously not ideal.
Final Solution: Sync = Skip Image-Building
When reading about these issues with the new image-building behavior in DevSpace v4, you can easily spot that there is a connection between file sync and image-building:
- If a container is using file sync, the underlying image for this container should generally not be rebuilt in most cases because the file sync will keep the container up-to-date.
- If a container is not using file sync, it is preferable to rebuild it whenever the context has changed.
This sounds trivial but is pretty hard to solve because there is no inherent connection between the sync configuration and the image that is used within the deployment used in the sync configuration. However, since v4 of DevSpace, there is the option to select a container for file sync using the
imageName option. And this made it possible to define the following behavior:
- Images which are referenced by the
imageNameoption in any of the sync configurations will not be rebuilt during the
devspace devprocess even if the context has changed.
- Images which are not referenced by the
imageNameoption in the
devspace.yamlwill be rebuilt only if their context has changed.
- Images will always be rebuilt if their Dockerfile has changed.
- All images will be rebuilt if the
-b / --force-rebuildflag is provided.
Remember that this is only the behavior for
devspace devbecause it starts the file synchronization. The command
devspace deploywill remain the same and rebuild images either if the
-b / --force-rebuildflag is provided or if their context or their Dockerfile has changed.
We hope this change will save a lot of time when developing cloud-native software using DevSpace and speed up your Kubernetes development workflow.
Feedback or Questions?
If you have any feedback or questions regarding this release or if you have any feature requests for an upcoming release, reach out to us via:
Get involved, let us build the best developer tool for Kubernetes!
We hope you will enjoy the new features and are looking forward to hearing how DevSpace v4 helps you to improve your Kubernetes development flow.