GitHub Actions runs automated workflows in response to events in a GitHub repository. A push can start a workflow that tests code or deploys a microservice. The workflow lives alongside the code it uses, so repository changes can trigger the commands needed to check and release that code. section 8.1 section 8.7.1
Start with a small YAML workflow configuration and a shell script. The simplest working example runs the script after a code push and prints “hello world” in the workflow output. Fork the example repository, clone your fork, and enable workflows in its Actions tab. Change the script, commit, and run git push; then check the workflow history on GitHub to see the result. The terminal push alone does not show whether the workflow ran. section 8.7.4 section 8.7.8
Once the trigger works, give the workflow a useful job:
- Continuous integration (CI) runs automated tests and other checks as code changes are pushed, providing early warning of problems. section 8.11
- Continuous deployment (CD) runs build, publish, and deployment commands automatically. A single-microservice deployment to Kubernetes provides a pattern to reuse for other services. section 8.0 section 8.7.11
- Keep deployment commands in shell scripts that can also be tested locally. Configure them with environment variables; use GitHub secrets for sensitive values, github.sha for an image version, and envsubst to fill parameters in deployment configuration. section 8.11
A production pipeline can delegate to several scripts that build, publish, and deploy microservices to Kubernetes. Practice manual deployment first: if the automated run fails, repeating the steps locally or manually can help isolate the problem. Reliable automation matters more as the number of microservices grows; manual or unreliable deployments become difficult to scale. section 10.10 section 10.13 section 8.11
