SE465

A6 Release Pipeline

In this assignment, you will learn about release pipelines and the continuous integration and continuous deployment (CI/CD) practices, and finally how to set up a simple release pipeline, incorporating some of the tools and skills you have picked up in this class up until now. Additionally, you will learn about a technique called git bisect which allows you to efficiently determine a bug-inducing commit among a batch of commits. Finally, we will integrate these together to show an application of an automation server for testing.

Tools

There are several tools that you may use to help you with creating a simple release pipeline.

  • Jenkins: Open source automation server that can be used for CI/CD and release pipelines
  • Git Bisect: Git command that can be used to perform a binary search between provided stable and unstable commits to locate bug inducing commit

Requirements

Please make sure that you have Maven and Java installed on your computer. If you have a Windows laptop, I recommend downloading WSL (Windows subsystem for Linux) or WSL2. You should be able to get this free in the Windows store and will let you emulate a Linux environment. Also if you can set up an Oracle account, that will save some time.

Definitions

A release pipeline assists in the continuous integration and continuous delivery process. This process can include fully automating features such as testing and static analysis into the software development process, ensuring that changes that are committed to the code do not break the build or violate code conventions and other policies adopted by the development team. The fundamental aspects of a release pipeline are some type of trigger, build, test, and other stages such as package, release, deploy, or deliver. Stages can be sequential or parallel, and be fully automated or await user input. Ideally, you will have your release pipeline running on a remote server that is up at all times and can listen for changes to your repository and build accordingly. An example of a basic pipeline can be seen below where most stages are linear with the deploy stage skipped in this case due to conditional logic.

Git Bisect is a technique that utilizes binary search in order to efficiently determine bug-inducing commits among a batch of commits. In the event that multiple commits have been made but the code has not been built and tested in between each commit when building and testing finally take place, it can be difficult to determine which commit introduced the bug. Rather than revert all changes, including potentially a group of commits that did not break the build, we can find the commit that introduced the bug and correct the build from this point without reverting any unnecessary changes. This technique relies on knowing when the last stable build occurred in order to perform an optimal search. The process can be seen depicted below:

There are two ways to perform git bisect. There is a manual and an automated. We will see both in Part E.

Experiments

Part A

  • Install the latest LTS version: brew install jenkins-lts
    • To start jenkins-lts now and restart at login: brew services start jenkins-lts
  • browse https://localhost:8080 and setup my account, follow instruction in https://www.macminivault.com/installing-jenkins-on-macos/ to complete setup.
    • on the guide, it says to download a specific java. Do we need to do that? (I’ll skip it for now)
    • after starting jenkins and heading to localhost:

Part B

Need to install java package in jenkins.

Part C

Create a freestyle job. A jenkins job that can give you basic configurations to compare or run your project automatically.

admin, hello: http://localhost:8080/

Make sure to tell which Maven to use. Then my build succeeded.

Part D

Need to learn how to use Blue Ocean (in the first experiment). Help you visualize your release pipeline. Need to install Blue Ocean on your computer.

Part E

Learn how to use git bisect and find that commit that fucked your code.