Developing

How to work on code with git and CI/CD

Someone on your team has setup Jenkins X on a kubernetes cluster. So how do you use it?

Mostly you just use your IDE and git to change code in your usual way.

Though we do prefer you submit code changes via Pull Requests to then trigger CI and Preview Environment for each Pull Request.

Demo

To see how to create a Preview Environment on a Pull Request see this demo:

Creating a project

To see how to create a new project and get started developing with Jenkins X check out this demo:

Pull Requests

The pull request (PR) is the foundation of Jenkins X CI/CD pipeline execution.

Note that some git providers call these merge requests instead of pull requests.

Using Pull Requests allows developers, reviewers and Jenkins X to:

  • Verify changes are valid: unit tests still pass, code is linted and so forth
  • Review PR code changes and their effects
  • Approve or deny PRs or suggest changes
  • Approve PRs and trigger automatic merge and promotion
  • Manual promotion of PRs to production environments and software releases

Preview Environments

The other advantage of working with Pull Requests is the automated CI/CD in Jenkins X creates a Preview Environment for each Pull Request

Work in progress (WIP)

Pull requests can be marked as work in progress, blocking auto-merging, either via making the PR a draft on GitHub, or by adding WIP:, wip:, [wip]:, or similar at the beginning of the PR title. The PR will be moved out of work-in-progress when no longer in draft or when the WIP prefix in the PR title has been removed.

How Lighthouse merges a PR

There are some unique actions and behaviors when using lighthouse to implement ChatOps:

  • The PR must have its required test contexts pass (by default, just pr-build).
  • PRs must be set /lgtm and approved, or have the updatebot label on it.
  • The PR must not have any merge conflicts.
  • If multiple PRs are all in the merge pool at the same time, the lowest numbered PR will be merged first, then the next one will be rebuilt and then merged, etc.

After Pull Requests merge

Once your pull request merges a new release is created for your application, creating new artifacts, images, helm charts etc

Then automatic Promotion Pull Requests are triggered.

By default your new version is promoted to the Staging environment. Though you need to manually approve the Pull Request to promote to Production.

You can Configure promotion to behave differently if you need it

Using ChatOps

ChatOps lets you interact with the Pull Request via special comments on the Pull Request via your git providers website.

See the ChatOps Command Reference


Last modified June 9, 2021: fix: add better demos (db5332210e)