We're sorry but this app doesn't work properly without JavaScript enabled. Please enable it to continue.

This lesson's interactive features are locked, please to keep using them

The Bigger Picture

This is the last lesson, but before we go, I want to reiterate how Docker fits into the software development lifecycle, particularly at modern "DevOpsy" tech companies, because it's really important to understand.

The Deployment Process
  1. The developer (you) writes some new code
  2. The developer commits the code to Git
  3. The developer pushes a new branch to GitHub
  4. The developer opens a pull request to the main branch
  5. A teammate reviews the PR and approves it (if it looks good)
  6. The developer merges the pull request
  7. Upon merging, an automated script, perhaps a GitHub action, is started
  8. The script builds the code (if it's a compiled language)
  9. The script builds a new docker image with the latest program
  10. The script pushes the new image to Docker Hub
  11. The server that runs the containers, perhaps a Kubernetes cluster, is told there is a new version
  12. The k8s cluster pulls down the latest image
  13. The k8s cluster shuts down old containers as it spins up new containers of the latest image

It's Never the Same

While the deployment process I've outlined above is a common one, especially at newer "cloud native" companies, two companies rarely have identical processes. Instead of GitHub, it might be GitLab. Instead of Docker Hub, it might be ECR. Instead of Kubernetes, it might be Docker Swarm or a more managed service.

That said, I hope this helps give you an idea of what to expect in the wild.

Click to play video