With the Visual Studio 2017 RC release, we've started down the path to finally shipping an official version of Visual Studio Docker tools; enabling developers to locally develop and debug containerized workloads.
The latest Visual Studio 2017 RC Docker Tools added a number of anticipated features:
- Multi-container debugging, supporting true microservice scenarios
- Windows Server Containers for .NET Framework apps
- Addition of CI build definition using a docker-compose.ci.build.yml file at the solution level.
- Return of the Publishing experience that integrates the newly released public preview of the Azure Container Registry and Azure App Service
- Configure Continuous Integration experience for setting up CI/CD with VSTS to Azure Container Services
We also spent a lot of time improving the overall quality
- Performance for first and subsequent debugging sessions, keeping the containers running
- Focus on optimized images for production deployments
- Cleanup of the docker files for consolidating on a single dockerfile for both debug and release and factoring the docker-compose files into a hierarchy, rather than parallel mode leveraging the docker-compose -f flag.
- Better handling for volume sharing failures - at least providing better insight
There are bunch of other great features and quality items that went in to the Visual Studio RC release. It would be great to hear which you like the most, or would like the most.
What about Visual Studio 2015?
The matrix of support scenarios are quite complex, particularly now that we ship inside Visual Studio. The current Visual Studio Docker Tools also focus on .NET Core with Linux, with the addition of .NET Framework targeting Windows Server Containers. While .NET Framework continues to be supported on VS 2015, the current .NET tooling has moved to Visual Studio 2017.
We also have a backlog of items that are required for RTW as well as customers asks, including:
- Open Source the Visual Studio Docker Tools
- Complete Perf work
- Cleanup some of the artifacts left behind (solution level obj folder)
- Converge the two debugging buttons as we need better solution level support for solution level debugging from VS
- Add Nano Container support for .NET Core
- Continue to improve perf for Windows Containers
- Add Visual Studio for Mac docker tooling
- Image renaming - as the image and service names are referenced in several docker-compose.*.yml files
- Language services for dockerfile and docker-compose.*.yml files
Attempting to keep both the Visual Studio 2015 and Visual Studio 2017 ship vehicles going would be fairly large effort, and if we took that on, a number of the above items would have to fall below the cut line.
Going forward, past Visual Studio 2017, we absolutely will support an N-1 support policy. Whether that's Visual Studio 2017 + 1/-1, or Visual Studio updates, we'll have to see.
However, at this point, Docker Containers are a relatively new technology that has a lot of rapid changes. We believe customers would prefer us to keep up and even lead in the tooling space as we also believe we'll attract far more customers with the new features then slowing down to support the current scenarios.
What do you think?