Docker is the industry standard for containerization when developing and deploying microservices. You’re able to use the same containers across every stage of the SDLC, which leads to a smoother developer experience. However, your local container orchestration looks nothing like your production orchestration, and that’s where you run into the classic “but it works on my machine” issue.
Shipyard helps developers bridge that gap, and deploy their Dockerized services into Kubernetes pre-production environments. This helps teams approximate how their code changes will fare in production.
Shipyard and Docker have a shared philosophy
Docker is beloved by many devs, and one of the main reasons is that it abstracts away much complexity of software sharing and delivery. It eliminates the need for multiple builds for different machines, makes cleanup easy, lets you share an image with your colleague knowing it will run as expected, isolates an app from the rest of your machine, etc etc.
Shipyard similarly improves DevEx by simplifying the preview/test stages: specifically, it removes the (heavy) lift that is setup and config from Kubernetes orchestration. Once you’ve set up an app with Docker Compose, it works on Shipyard, and you can share that running app with teammates (without them needing to pull the images and run that on their machine). You’re able to view changes or run your tests without needing to call in a staging deployment, and you don’t need to trigger teardown either.
Docker and Shipyard both are built to reduce unnecessary toil and frustration, and illuminate a “paved path” to shipping software. Engineering managers know that time spent frustrated is not only time wasted, but also a detriment to morale and overall productivity.
How Shipyard spins up a Docker environment for every PR
Once you commit code or update your Docker image in your registry, you don’t need to do anything else before your test environment is ready on Shipyard. Shipyard uses your Docker Compose as its application definition, so if your app works locally with docker compose up, it will work on Shipyard.
When GitHub, Bitbucket, or GitLab webhooks send a pull/merge request event to Shipyard, it will begin to provision a new environment. Services will build from your repo’s Dockerfiles, or pull the images specified in your Docker Compose from their remote registry. Shipyard uses Kubernetes orchestration for preview environments, so your app will autoscale and auto-recover. You’ll see a comment on the pull/merge request when it’s ready, with an access link.
The Shipyard environment is a complete app, and has full services instead of stubs or mocks. It also is hydrated with a copy of real (or realistic) data, which you can snapshot at any point to manage state. Since the environment is isolated, you can push high-risk (and agent-written) code to it without risking it affecting your other environments, as there are no shared services or dependencies.
Is Shipyard right for your Docker workflow?
If you’re already using Docker containers to develop your app, you’re basically Shipyard-ready. There’s only so much compute you have on your machine, and this won’t scale for the sophisticated E2E testing that you need before a deployment. Shipyard allows you to have multiple concurrent environments, so you can compare new features to main or test multiple branches in parallel.
Conveniently, Shipyard is reactive (in that it responds to repo events), so you don’t have to really change your workflow to use it. Your Docker + Shipyard workflow might look similar to this:
- You commit and push some code to a branch in your git repo
- Shipyard builds your Docker images reflecting the new changes, or pulls them from your container registry
- Shipyard orchestrates and deploys the containers in an isolated ephemeral environment
- You access the environment via an SSO-enabled link
- You trigger a CI run against the environment link
- A test fails; you push a quickfix commit
- Shipyard auto rebuilds and redeploys the affected service(s)
Faster feedback loops == better DevEx
One of the biggest detractors from shipping fast is the time you spend waiting. This happens at every stage of development: waiting for tickets, waiting for review, waiting for tests to run, waiting for an approval, waiting for an environment, etc. Having self-service infrastructure can help eliminate most (if not all) of these infra-related blockers, so there’s a straighter path from developing a feature to deploying it. Plus, you won’t suffer from the burnout/frustration along the way.
Shipyard makes pre-production environments easy. Your Compose config is your Shipyard config, and from there, you can get easy scalable orchestration for your Dockerized application. But don’t just take our word for it; try it yourself free for 30 days and see what you think.
