Overview - Day 1

If you already have access to a development cluster that has been set up with the Toolkit you can get started deploying an application to the cluster with an Enterprise-grade devops pipeline. While you are there, you can also explore the Cloud-Native Toolkit Developer Dashboard and/or the OpenShift console to learn how to leverage those resources to increase productivity building cloud-native applications.

In the DevOps process, Artifact Management generally refers to the activities around storing and managing assets that are produced during the continuous integration process. Depending upon the development language, an “asset” could be any number of things:

Besides the contents of the asset, many of those types of artifacts also involve a particular protocol for how they are shared and consumed (e.g. maven repository for jar libraries).

There are a number of tools available to handle manage artifacts, from roll-your-own file systems to enterprise-grade software. Currently the Cloud-Native Toolkit supports provisioning the following Artifact Management tools:

In IBM Garage Method, one of the Develop practices is to automate tests for continuous delivery, in part by using static source code analysis tools. SonarQube automates performing static code analysis and enables it to be added to a continuous integration pipeline. The environment’s CI pipeline (Jenkins, Tekton, etc.) includes a SonarQube stage. Simply by building your app using the pipeline, your code gets analyzed, just open the SonarQube UI to browse the findings.

Static code analysis (a.k.a. code analysis) is a method of debugging by performing automated evaluation of code without executing the program. The analysis is structured as a set of coding rules that evaluate the code’s quality. Analysis can be performed on source code or compiled code. The analyzer must support the programming language the code is written in so that it can parse the code like a compiler or simulate its execution.

Static code analysis differs from dynamic analysis, which observes and evaluates a running program. Dynamic analysis requires test inputs and can meansure user functionality as well as runtime qualities like execution time and resource consumption. A code review is static code analysis performed by a human.

Static code analysis can evaluate several different aspects of code quality, such as:

Static code analysis collects several metrics that measure code quality:

A Quality gate defines a policy that assesses pass/fail whether or not the number of issues and their severity is acceptable.

In IBM Garage Method, one of the Develop practices is continuous integration. The environment uses a Jenkins pipeline to automate continuous integration.

Continuous integration is a software development technique where software is built regularly by a team in an automated fashion. This quote helps explain it:

An Image Registry is a repository of versioned container images. It is perhaps a subset of the larger Artifact Management topic but has special considerations.

A specific protocol has been defined around building, pushing, tagging and pulling container images to and from an Image Repository. Typically, the continuous integration process is responsible for verifying and building the application source into an image and pushing it into the registry. At deployment time, the deployment descriptor (e.g. kubernetes resource definition) references the image at its location within the image registry and the container platform pulls the image and manages the running image in the cluster. Tools like skopeo can also be used within the process to copy images from one registry to another.

There are a number of options available for the Image Registry, both running in-cluster and outside of the cluster. Red Hat OpenShift even provides an image registry as part of the platform. While an intermediate image registry might be used during the CI process, in an enterprise environment it is ideal to have a centrally managed image registry from which vulnerability scans, certifications, and backups can be performed. Some of the available options include:

In IBM Garage Method, one of the Develop practices is contract-driven testing. Pact automates contract testing and enables it to be added to a continuous integration pipeline. The environment’s CI pipeline (Jenkins, Tekton, etc.) includes a Pact stage. Simply by building your app using the CI pipeline, your code’s contract gets tested, just open the Pact UI to browse the results.

Contract testing is a testing discipline that ensures two applications (a consumer and a provider) have a shared understanding of the interactions or the contract between them.