Reacting to success or failures is again super simple thanks to GitHub’s job status check functions.If anything fails our own dreipol/github-actions/slack actions are triggered and inform all developers about the error.extracting licenses from used third party dependencies and validating the usage) are green, the new Docker image is pushed to our Google Cloud Registry In the now built image, we trigger our test suite which includes any kind of tests from the backend and frontend depending on the tech stack used in the project(thanks to service containers triggering integration tests that rely on a database is trivial).The projects Dockerfile includes everything necessary to run the project like installing front-, backend- and system dependencies or optimizing static assets.Build a new image from the current codebase and use the existing one for possible cache benefits.Log in to Google Cloud with the gcloud CLI and pull an existing image for the current branch (if any).A typical example would be the Slack API key which allows our actions to post updates to a specific Slack channel. The introduction of organization-wide secrets helped us to greatly reduce the complexity of managing these sensitive values. These can be extracted from the repository secrets. All jobs are run on the ubuntu-latest runner.Īctions have access to specific environment variables defined in the workflow. Together they form the steps in our 3 jobs: build, notify-slack and deploy-prod. We developed 12 custom actions, which are basically small scripts run in their own Docker container. They consist of Workflows, Events, Jobs, Steps and Actions. In short, actions are defined in a YAML file directly in your project’s repository and allow you to trigger a series of commands after an event has occurred, in our case a push to the repository in question. It took another year though for dreipol to fully commit (pun intended) to them and move away from CircleCI. GitHub Actions were released in 2018 and we instantly knew that this could greatly improve our deployment process. We use different branching strategies depending on the project but most of the time a developer creates a pull request from his or her respective feature branches which will then be merged after a review - a deployment is born. It all starts with a git push to one of the branches connected to a deployment. Let’s break the above overview down and see what really happens in each step.ĭeployment flow visualized. This means there were on average 7 to 8 deployments to any one of our many projects per day. Since every deployment triggers a message in our internal Slack channel, a glance at said channel shows that the above-mentioned actions were triggered around 230 times in March alone.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |