GitHub for CI – CD (DevOps)

GitHub Branching Strategies

We can have different branching strategies for our GitHub Repos.

One of such strategy we should have 4 kinds of branches.
1. Master Branch:
This is the ultimate top-level branch where we can merge your
versioned code. Whenever a release happed and stable
version of it is made and that piece of code is passing every
stage in pipeline as well all the security check we can keep
that in Master branch.

2. Dev Branch:
This branch will be current code line for project. We will get
developers code get merged in this branch for every Pull
Request raised. Once all the needed checks are done and
code is ready for release we will merge it will master.

3. Release Branch:
Whenever a release is happening, we can merge code with
release branch. Code from release branch is the merged into
master branch after all necessary changes done after release.
This will be the stable version of the release.
Ex: a. release/v0.1
b. release_v0.1

4. Feature Branch:
This branch will be current code line for developer. Developer
will commit and push all his/her code into this branch. Once
all the coding part is done he will raise a Pull Request to Dev
branch. In this way code from all the developers will get
integrated in Dev Branch.
Ex: a. feature/name-developer
b. feature/feature-name etc.
Pipeline Strategies

A Pipeline is addition of several Jenkins jobs.

1. Pipeline for Branch
• When ever a commit or push happened to a feature/branch
this will be triggered. The branch should contain needed
Jenkins config files and necessary webhooks linked to
Jenkins or any other CI tools.
• Note: As this pipeline gets triggered more actively, its
better to add only needed stages into pipelines, like unit
test, SonarQube etc.
• This should be minimal.

2. Pipeline for PR
• When ever pull request happened from any feature/branch
to Dev branch this will be triggered. The branch should
contain needed Jenkins config files and necessary
webhooks linked to Jenkins or any other CI tools.
• Note: As this pipeline gets triggered now and then its better
not to add more time taking stages like CheckMarx, Vulas
etc.
• This should be moderate.

3. Pipeline for Nightly Build

• This nightly build is like cronjob. We need to set a time for
the pipeline to get triggered.
• As this gets triggered once in a day we can add all the
needed stages to run every night.
• This should be configured with all the stages.
Trigger Jenkins builds or Pipelines by pushing to GitHub

In GitHub

Create Webhooks:
Webhooks help us trigger our pipelines whenever an event is occurred like push, commit, pull
request etc. And they can send Payload data with respect the event occurred.

If user want to trigger only particular event he can declare only need events like:

• Commit
• Push
• PR
• Branch Creation etc.
In Jenkins

• Under ‘Manage Jenkins’ -> ‘Manage Plugins’, select and install both Github and Git
plugins. Restart to finish the installation.
• Configure your github repo HTTPS link or SSH link in jenlins

• Project repo details