My company uses Azure DevOps and utilized Pipelines for building, testing and deploying (currently NuGet packages) .Net Framework apps.

My boss has made it clear he wants us to containerize all our microservices and at some point start using Kubernetes. During this process we will also port our apps to .Net Core, one by one.

After I had made a multistage Dockerfile (building and runtime, but not testing yet) for one of our microservices, he suggested we could simplify it by continuing to use Pipelines to build and test the apps and in a later task add the compiled app to a Docker container in Azure DevOps. This seems to be an anti-pattern as far as I know (I may be wrong), and I understand his desire for simplicity.

Is this an anti-pattern or is it a good idea?

1 Answer 1


I'd say it is an anti-pattern as you lose the portability of Docker. Now you will be relying on the build server's configuration instead of portable base image.

If reducing complexity of the Dockerfile is the goal why not do something like this:

  1. Build the .net core project in Docker (eliminates reliance on the build server).
  2. Run the tests (inside or outside of Docker).
  3. Now push the image and run it.

Basically break your Dockerfile into three discrete pipeline steps. This allows the build to fail on a discrete step. It also reduces the complexity of the Dockerfile (at the cost of increased complexity in your pipeline).

  • How can I run unit tests outside docker if I build the project in Docker?
    – user16086
    Jul 18, 2019 at 15:38
  • When you build in the first step you can grab the .dll and other files as an artifact. It would be much easier to just use another Dockerfile in step 2 that uses the image from Step 1. Jul 18, 2019 at 15:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.