Continuous Integration With GitHub Actions

Implement three different workflows to test, bump the version, and publish a new release. This tab allows you to add a workflow to your repository.

Introduction

If you have a GitHub repository, you might have seen a tab called Actions:

This tab allows you to add a workflow to your repository, that is, an automated process to run on certain events to build, test, package, release, or deploy any project on GitHub. To help you do this, GitHub introduces what’s called GitHub Actions. These are tasks or tools stored in a GitHub repository that perform an action. For instance, actions/checkout will execute a git checkout command for you. There are numerous actions in GitHub Marketplace.

In this tutorial, I’ll be explaining the process I’ve taken to automize the development lifecycle of an open-source framework, SwiftUIPager. Although some of the actions used in the workflows might be related to this library’s platform, iOS, we’ll focus on the general concepts to help you understand the key ideas.

Over the next sections, we’ll be working on three different workflows to:

• Unit-test the package and report code coverage
• Bump the version and create a tag
• Publish a new release and deploy/distribute it

Unit-Test and Code Coverage

Workflow essentials

First thing is to go to the tab Actions in your repository, where you should see something like this:

GitHub will suggest some templates for you to use. The suggestions may vary depending on the main language of your repository. If you see any that fit your purposes, go ahead and click on it to add it. In my case, I’ll hit “set up a workflow yourself.” This creates some boilerplate. Let’s take a look:

Let’s explain what’s happening here:

1. Workflows are labeled with a name. This is useful once we’ve set up a couple as it’ll help us identify which one is running
2. Workflows are triggered by events. These events might be a push to master, a pull request, a new tag, the publication of a new release, and so on. See all supported events.
3. Workflows are composed of jobs. These are the actions that will take place once the workflow is triggered. Jobs are tagged (in this case, our only job is tagged as build ) and define an environment to run on: Windows, macOS, Ubuntu, (see all virtual environments). This is important because some actions are designed to run in a specific environment. Finally, jobs are broken down into steps. These steps run sequentially, opposite to jobs that will run in parallel unless explicitly defined as sequential.

programming continuous-delivery ios devops

DevOps is supposed to help streamline the process of taking code changes and getting them to production for users to enjoy. But what exactly does it mean for the process to be "streamlined"? One way to answer this is to start measuring metrics.

How to build and deploy Continuous Integration, Delivery with Jenkins for microservices application on Kubernetes and serverless

DevOps and Cloud computing are joined at the hip, now that fact is well appreciated by the organizations that engaged in SaaS cloud and developed applications in the Cloud. During the COVID crisis period, most of the organizations have started using cloud computing services and implementing a cloud-first strategy to establish their remote operations. Similarly, the extended DevOps strategy will make the development process more agile with automated test cases.

Continous integration helps bring systems and dependencies together faster. Continous delivery reduces time to market. Which is best for your organization?

A quintessential piece for anyone working with distributed systems is the Fallacies of Distributed Computing by L Peter Deutsch. Even when working with modern platforms such as Kubernetes, the assertions made in the Fallacies of Distributed Computing prove to be very true around latency, bandwidth and system administration.