Development Environment Considerations for Containerized Applications

When an application is built and deployed as a container there are a few considerations that need to be made in terms of developer experience. More specifically a decision needs to be made as to how much the developers are going to build the application like it is really built, and if they are going to run it like it really runs on their machines.

Why is this important?

Having local development more closely resemble how the actual application is built and deployed has many advantages. The more that can be accomplished on the development machine will provide quicker feedback in regard to the status of the build and the status of the application after testing. This also means there should be fewer differences, or surprises, when the application is moved beyond the developer machine.

What are the challenges?

Many development environments are provided to developers in the form of a virtual desktop image. Some virtualization options make it difficult, and sometimes impossible, to run Docker inside of them. There is also an impact to the time it takes for developers to test changes within the application. Running a Docker build and then stopping and starting the application can sometimes take a long time. It is critical to try to lessen the amount of time it takes for a code change to be able to be tested.

Is there a compromise?

A good middle-ground is to provide the tools and documentation to allow for testing code in the developer IDE and also from within the running container as a mapped volume. The location of the compiled code can be mapped as a volume to the location that it resides within the container. This allows for the code produced from the developer IDE to be used within the running container. However, in containers such as java based containers a restart is still needed for code changes to be applied.

A summary of the different routes to testing changes are as follows:

1. Testing completely in the IDE

   • Pros:
     • Fast application and testing of changes
     • No problems if within a Virtual Desktop Image (VDI)
   • Cons:
     • Not known if changes broke the Docker build
     • Not known if configuration changes are also needed to run the container

2. Running the latest application image as a container with volume mounts

   • Pros:
     • The code is running in the container
     • Configuration changes are known
     • No Docker build needed
   • Cons:
     • Not known if changes broke the Docker build
     • Container may need restarted after changes.

3. Running a Docker build and running the resulting image as a container

   • Pros:
     • No difference between the local and real environment
   • Cons:
     • Running a Docker build and running the image as a container after every code change can take a very long time

Conclusion

There is not a right answer for everyone. The pros and cons need to be considered based on the needs of developers and the specific requirements of the application. Providing developers with the ability to build and run the application as a container when they need to is in most cases sufficient for debugging and fixing any issues that may arise from the development environment being different.