A feature is finished, but customers cannot use it while it waits for a release. A long gap between writing code and running it also makes failures harder to trace: a later configuration change may break the release. Deployment closes that gap by making a built product run where people can use it. section 4.0 section 1.2.4
Delivery and deployment are different steps. Publishing a binary to a repository delivers an artifact; starting it as a service deploys it. A library may need delivery but no deployment. Depending on the product, deployment might mean running a container, installing an application on a server, or setting up a serverless function. section 4.1 section 1.2.4
Keep the path from change to use short:
- Build and test a small increment, then publish its artifact. A simple working API can support a demo or let a teammate begin integration before every feature is complete. section 2.5 section 4.1
- Choose a place to run it. Hosted functions and platforms can keep early deployment cheap; a container runtime offers more control over what runs. section 1.3.3 section 7.5
- Automate the deployment and check the running result. A Cloud Run pipeline can deploy a container image, then call the deployed API URL with curl. section 7.5
- Watch usage and failures after release. Customer feedback, metrics, and alerts help determine what to fix—and whether the deployment approach still fits. section 1.2.4 section 11.1
Listing 7.2 pipeline.yml
deploy-container:
name: Deploy Container buildpack
runs-on: ubuntu-latest
needs: containerize-buildpack
if: ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }}
steps:
- name: Deploy to CaaS
id: deploy
uses: google-github-actions/deploy-cloudrun@main
with:
service: translate #1
image: gcr.io/${{ secrets.GCP_PROJECT_ID }}/hello-api:latest #2
credentials: ${{ secrets.gcp_credentials }}
- id: test #3
run: curl "${{ steps.deploy.outputs.url }}/hello"
The pipeline job deploys a container image to Google Cloud Run only on a push to main, then calls /hello at the URL returned by deployment. section 7.5
For a Kubernetes deployment, the word also names a specific resource. A Deployment defines the containers to run in pods and their scaling; a Service routes requests to them. That adds control, but hosted runtimes can handle much of this work without requiring a team to maintain a cluster. section 10.3 section 7.5
Listing 10.2 deployment.yml
apiVersion: apps/v1
kind: Deployment #1
metadata:
name: hello-api #2
spec:
replicas: #3
selector:
matchLabels:
app: hello-api
template:
metadata:
labels:
app: hello-api
spec:
containers:
- name: hello-api
imagePullPolicy: Always
image: gcr.io/PROJECT_NAME/hello-api:latest
ports:
- containerPort: 8080 #4
name: hello-api-svc #5
The Kubernetes manifest shows a Deployment naming a container image, selecting its pods by label, and declaring the application port. section 10.3
