Automate Your Code Testing and Delivery with GitHub CI/CD Actions

Whether you’re a seasoned developer or just starting, Continuous Integration and Continuous Delivery (CI/CD) is a set of practices that can help you improve the quality and speed of your software development. In this blog post, I introduce you to the typical CI/CD workflow, the key components of a workflow file, and how to set up a workflow file. We will also explain why GitHub Actions are great for CI/CD and how to use a repository as a sandbox for learning CI/CD. Finally, we will show you how to validate your YAML file syntax and check your GitHub workflow created.

So, if you’re ready to take your software development to the next level, let’s dive in!

What is CI/CD? 🤔

CI/CD stands for Continuous Integration and Continuous Delivery. These are two practices that aim to improve the quality and speed of software development.

Continuous Integration (CI) is the process of automatically testing your code every time you make a change. This helps you catch bugs and errors early before they affect the rest of your project. CI also ensures that your code is always in a consistent and working state.

Continuous Delivery (CD) is the process of automatically deploying your code to a target environment, such as a server or a cloud platform. This helps you deliver updates and features to your users faster and more reliably. CD also ensures that your code is always in a ready and releasable state.

By combining CI and CD, you can create a seamless and efficient workflow that allows you to develop, test, and deliver software with confidence and agility.

Typical CI/CD Workflow 🛠️

A typical CI/CD workflow consists of the following stages:

1. Code Commit: Developers commit their code changes to a version control system.
2. Build: The CI server automatically builds the code, including any dependencies.
3. Automated Testing: Automated tests, including unit tests, integration tests, and performance tests, are executed to ensure the code's correctness.
4. Artifact Generation: The CI server generates deployable artifacts, such as binaries or container images.
5. Staging/Pre-Production: The artifacts are deployed to a staging or pre-production environment for further testing and validation.
6. User Acceptance Testing (UAT): In some cases, user acceptance testing is performed in an environment that closely resembles the production environment.
7. Deployment to Production (CD): In Continuous Deployment, the artifacts are automatically deployed to the production environment. In Continuous Delivery, this is a manual step.
8. Monitoring and Feedback: The production environment is monitored for issues, and feedback is collected for further improvements.
9. Rollback (if necessary): If issues arise in production, a rollback to a previous version may be necessary

Why GitHub Actions are great for CI/CD? 💡

GitHub Actions is a feature of GitHub that allows you to automate your software development workflows. You can use GitHub Actions to create custom pipelines that run your code, tests, and deployments on GitHub’s servers or your own.

GitHub Actions are great for implementing CI/CD because they offer:

• Flexibility: You can use any programming language, framework, or tool that you want. You can also integrate with third-party services and APIs. You can define your triggers, conditions, and actions for your workflows.
• Scalability: You can run your workflows on GitHub’s cloud infrastructure, which can handle any load and scale up or down as needed. You can also use self-hosted runners to run your workflows on your machines or servers.
• Security: You can store your secrets and credentials securely on GitHub and use them in your workflows. You can also control the access and permissions of your workflows and repositories.
• Collaboration: You can share your workflows with your team and the GitHub community. You can also reuse and customize existing workflows from the GitHub Marketplace or other repositories.
• Visibility: You can monitor and debug your workflows in real-time. You can also view the logs, artifacts, and status of your workflows and their runs.

Key components of a workflow file 📜

A workflow file is a YAML file (example above) that defines your GitHub Actions workflow. You can create and edit your workflow file in the .github/workflows directory of your repository. A workflow file has the following key components:

• Name: You can give your workflow a descriptive name that will appear on the GitHub Actions tab of your repository. For example, name: CI/CD Workflow.

• Triggers: You can specify when and how your workflow will run. You can use events, such as push, pull_request, or schedule, to trigger your workflow. You can also use filters, such as branches, paths, or tags, to limit the scope of your workflow.

  For example, on: push: branches: [main].

• Jobs: You can define one or more jobs that will run in parallel or sequentially. Each job has a unique identifier and a set of steps that will execute on a runner. For example, jobs: build: runs-on: ubuntu-latest.

• Steps: You can define the tasks that each job will perform. Each step can run a command, a script, or an action. You can use built-in actions, such as actions/checkout or actions/setup-node, or custom actions from the GitHub Marketplace or other repositories. You can also use inputs, outputs, and environment variables to pass data between steps. For example, steps: - uses: actions/checkout@v2 - run: npm install.

Using a repository as a sandbox for learning CI/CD

If you’re new to CI/CD, it can be challenging to know where to start. One way to get started is to use a repository as a sandbox for learning CI/CD. A sandbox is a safe and isolated environment where you can experiment with new tools and techniques without affecting your production code.

Here are some steps to follow when using a repository as a sandbox for learning CI/CD:

1. Create a new repository: Create a new repository on GitHub or any other Git hosting service. Give it a descriptive name that reflects the purpose of your sandbox.
2. Define your goals: Define your goals for the sandbox. What do you want to learn? What tools and techniques do you want to experiment with? What outcomes do you want to achieve?
3. Choose your tools: Choose the tools and technologies that you want to use in your sandbox. For example, you might want to use GitHub Actions for your CI/CD pipeline, Node.js for your application, and Docker for your containers.
4. Write your code: Write your code and commit it to your repository. Make sure that your code is well-organized, well-documented, and well-tested.
5. Create your workflow: Create your CI/CD workflow using GitHub Actions or any other CI/CD tool. Define your triggers, jobs, and steps. Test your workflow and make sure that it works as expected.
6. Iterate and improve: Iterate and improve your workflow based on your goals and outcomes. Experiment with different tools and techniques. Refactor your code and your workflow as needed.

By using a repository as a sandbox for learning CI/CD, you can gain hands-on experience with CI/CD tools and techniques in a safe and controlled environment. You can also share your sandbox with others and get feedback and suggestions for improvement.

Setting up the workflow file 📃

To check if the README.md file for a GitHub profile is only using markdown code, you can use GitHub Actions to create a workflow file that checks for any syntax errors in the file. Here are the steps to set up the workflow file:

1. Create a new repository on GitHub or use an existing one.
2. Create a new file in the .github/workflows directory of your repository and name it readme-checker.yml.
3. COPY, PASTE and SAVE the following code into the file readme-checker.yml
4. Commit and merge to your main branch.

The code above checks if a .md file for a GitHub repository is only using markdown code, and the workflow is triggered by either a push or pull_request event.

The workflow has one job called lint that runs on the ubuntu-latest virtual machine, and the job has two steps:

• actions/checkout@v3: Checks out your repository code.
• DavidAnson/markdownlint-cli2-action@v11: Uses the markdownlint-cli2-action tool to check for syntax errors in the .md files in your repository, including the README.md file.

The globs parameter specifies the files to be checked. In this case, it checks all .md files in the repository except those in the test directory.

Validating your YAML file syntax ✅

You can check if your YAML file has valid syntax by using a YAML checker website. One such website is YAML Checker (https://yamlchecker.com/). It provides a simple interface to input YAML content, view your content with syntax highlighting, and instantly display any issues with your YAML along with a line number causing the problem. Once you have fixed your YAML, the validator will instantly update to indicate that your input is free of errors with a green success message.

Checking your GitHub workflow created 🫡

You can verify if the workflow is working on your GitHub Action by following these steps:

1. Open your repository on GitHub.
2. Click on the “Actions” tab.
3. Find the workflow you want to check and click on it.
4. Check the status of the workflow run. If it is green, it means the workflow passed. If it is red, it means the workflow failed.
5. Click on the workflow run to see the details of the run, including the logs and any errors or warnings.

Conclusion

In summary, Continuous Integration (CI) and Continuous Delivery (CD) are essential practices for enhancing software development quality and efficiency. GitHub Actions provides a robust automation platform for these processes. This article has covered the core components of CI/CD workflows, the use of GitHub Actions, and tips for establishing a CI/CD sandbox. By leveraging these insights and GitHub Actions, you can optimize your software development, ensuring early error detection and streamlined delivery. It's a reliable tool for both seasoned developers and beginners in the field, promoting efficient coding, testing, and deployment practices.

I hope to see you in the next reading! 😊

Keep coding! 💻

                                                             Thanks for the support❤️

References

1. Turnbull, James. Build a CI/CD workflow with Github Actions: https://github.com/readme/guides/sothebys-github-actions
2. GitHub Docs. Workflow syntax for GitHub Actions: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions
3. Streater, Annie. 5 tips for making your GitHub profile page accessible: https://github.blog/2023-10-26-5-tips-for-making-your-github-profile-page-accessible/#github-actions-workflows
4. YAML Checker: https://yamlchecker.com/