In this post we will assume that you practice Continuous Integration (CI) and have a product which is packaged as a Docker image. As your next step you are looking to implement Continuous Deployment (CD) from scratch or move to it from a Continuous Delivery workflow. Our aim will be to build and push a docker image to Docker Hub using GitHub actions.

Continuous Integration (CI) is a practice that requires developers to push code into a shared repository several times a day. When pushing our code to a shared repository, we should strive to ensure that our code is syntactically correct and builds so that other developers can grab the latest copy and begin iterating upon it easily. Today we are going to look at this principle and how we can easily identify and correct common coding mistakes when designing Service Contracts for Application Programming Interfaces (APIs). Specifically, we will explore how we can use Git hooks as a mechanism for ensuring a RAML Service Contract is valid using a Linter called RAML Enforcer.

When working inside a Continuous Integration (CI) and Continuous Delivery (CD) environment, portability of code is often a core concern that needs to be addressed. Developers write code locally and need some level of assurance that it will run consistently regardless of where it is deployed. This is an area where Docker shines. The goal of this post is to run a script, written with Node.js, inside a docker container. It assumes that you have an existing script which requires access to files on the local file system as well as an account on Docker Hub.

Within a Continuous Integration (CI) and Continuous Delivery (CD) environment, the first principles is that no code is delivered without automated tests. Today we are going to look at this principle and how we can easily identify and correct common coding mistakes when designing Service Contracts for Application Programming Interfaces (APIs). Specifically, we will explore how Linting can be used for this purpose.