-
Notifications
You must be signed in to change notification settings - Fork 11
Github Actions
At the most basic level, GitHub Actions brings automation directly into the software development lifecycle on GitHub via event-driven triggers. These triggers are specified events that can range from creating a pull request to building a new brand in a repository. All GitHub Actions automations are handled via workflows, which are YAML files placed under the .github/workflows directory in a repository that define automated processes.
Actions minutes is the time it takes to compute and execute specific automated tasks on GitHub-hosted runners, which host all workflow executions. If a specific job takes two minutes to execute, for example, that counts toward the total included minutes per month a developer has per their plan. A GitHub Free account comes with 2,000 minutes a month that can be used on private repositories (developers have unlimited use of GitHub Actions on a public repository with a self-hosted runner). While a developer’s chosen OS doesn’t impact the length of time it takes to run a workflow, it does impact how much each workflow counts against their minutes per month. This is called the minute multiplier. Workflows executed on a Windows or macOS hosted GitHub runner consume minutes at 2 and 10 times the rate that jobs on Linux consume.
CI/CD falls under DevOps (the joining of development and operations) and combines the practices of continuous integration and continuous delivery. CI/CD automates much or all of the manual human intervention traditionally needed to get new code from a commit into production such as build, test, and deploy, as well as infrastructure provisioning. With a CI/CD pipeline, developers can make changes to code that are then automatically tested and pushed out for delivery and deployment. Get CI/CD right and downtime is minimized and code releases happen faster.
Continuous integration is the practice of integrating all your code changes into the main branch of a shared source code repository early and often, automatically testing each change when you commit or merge them, and automatically kicking off a build. With continuous integration, errors and security issues can be identified and fixed more easily, and much earlier in the software development lifecycle.
By merging changes frequently and triggering automatic testing and validation processes, you minimize the possibility of code conflict, even with multiple developers working on the same application. A secondary advantage is that you don't have to wait long for answers and can, if necessary, fix bugs and security issues while the topic is still fresh in your mind.
Common code validation processes start with a static code analysis that verifies the quality of the code. Once the code passes the static tests, automated CI routines package and compile the code for further automated testing. CI processes should have a version control system that tracks changes, so you know the version of the code used.
Continuous delivery is a software development practice that works in conjunction with continuous integration to automate the infrastructure provisioning and application release process.
Once code has been tested and built as part of the CI process, continuous delivery takes over during the final stages to ensure it can be deployed’s packaged with everything it needs to deploy to any environment at any time. Continuous delivery can cover everything from provisioning the infrastructure to deploying the application to the testing or production environment.
With continuous delivery, the software is built so that it can be deployed to production at any time. Then you can trigger the deployments manually or move to continuous deployment where deployments are automated as well.
(CI/CD pipelines)[https://about.gitlab.com/blog/2019/07/12/guide-to-ci-cd-pipelines/] are the top-level component of continuous integration, delivery, and deployment. Pipelines are a collection of jobs that are divided by stages.