There's not a whole lot on continuous integration/continuous delivery on AZ‑800,
just little hints of it here and there.
This is an architectural diagram that shows one of
Microsoft's reference architectures,
this one showing how you could possibly implement some of the
Azure container tools in a CI/CD process.
But we have our engineer using their tools,
whatever it might be, Visual Studio in this example,
committing code changes to a central Git repository.
Now this example assumes that the team is using Azure DevOps.
Normally, you would have your pipeline,
your build pipeline set to auto trigger when a
CodeCommit happens in your repository, and let's assume that's what happens.
So that CodeCommit from that engineer would then trip off the
build process where you're building the software and you're
running tests against it, etc. etc. etc.
We can incorporate tasks in our Azure DevOps pipelines to
interact with all of the Docker services.
We might in that build process build one or more images and
then push them to Azure Container Registry.
Once that build completes,
we could do a continuous delivery where in a separate release pipeline we
have it set such that when there's a build artifact,
create a new release,
and that new release may then deploy those Azure Container Registry images to,
for example, a managed Kubernetes architecture.
Now this slide is outdated.
It says Azure Container Service.
We would say Azure Kubernetes Service.
ACS was the Microsoft v1 approach at doing enterprise scale containers. Nowadays, we just have AKS, so note that well, all right?