How to perform continuous Integration using Jenkins?

Question

I've the basic idea about the Continuous Integration using Jenkins like- basic project setup, setting up source code management bit-bucket and build the project. I have done this so far and following the same approach, whenever any commit done in bit-bucket, Jenkins trigger the build and i get the build status But in my organization there is no expertise who clearly tell us about how CI tool actually used in real time. So we are not aware of the scope and expansions of the Automation project in terms of CI tool.

Can some one guide us about this and guide us to manage the release using Jenkins ? also somewhere the terms Jenkins pipeline confused me what it is and why it used for?

I'm working on Agile, So after completion on each sprint we have to commit out code in master branch only. We are planning to create new branch for each sprint. The vague in my is, we can create the new branch, sprint wise and also create the Jenkins job as per branch, So after committing the new branch Jenkins will trigger the build for that branch. It is the right approach ?

Answer 1

Continuous integration means roughly what you said. Whenever something is committed, it is automatically built and tested, with a red/green light showing up at the end.

Continuous deployment takes this a step further and whenever a green light turns up, automatically deploys that.

Note that "tested" above can mean several steps: smoke tests (does it crash and burn right away), automated unit/feature/integration tests, and then, if you are not superbly confident, also maybe some final manual tests. Also, obviously, for CD, your test setup needs to be sufficiently conclusive so you can deploy with good confidence. You can also do the fully automatic deploy to internal testing/staging areas first, and then only do a production deploy at a later date.

To your questions:

But in my organization there is no expertise who clearly tell us about how CI tool actually used in real time.

You need to figure that out for yourself as it depends very much on the persons, processes and software you are building/deploying. At first, just build the tools, work with them, and see what happens. If everything works splendidly, continue along the path you laid out yourself; if you hit problems, solve them as they come up.

So we are not aware of the scope and expansions of the Automation project in terms of CI tool.

The more automation, the merrier. Automation not only means shaving off a few minutes here and there (but this factor also pays of hugely surprisingly fast), but also that everything that is automated, is codified in some script or tool; which means you are much less dependent on individual persons (who may become ill, overloaded, or leave the company) and scale much better if your team grows.

manage the release using Jenkins ?

I view Jenkins one step "lower" than managing releases. In "pure" CI/CD, the final stage, there would be no releases anymore as every commit would directly and in real-time end up on production anyways. At the other end of the spectrum, you have something like 3 releases per year, each one of them late by 2 months ;). Every project will be somewhere along that spectrum, as dictated by circumstances (not the least of which are your stakeholders and the available money - running a very fast CI/CD is not free).

the terms Jenkins pipeline confused me what it is and why it used for?

"Pipeline" is just a fancy word for saying that you commit - build - test - deploy. It's just figuratively speaking. The imagery is that you drop your commit into the pipe at the one end, and on the other end you get a running production server.

So after committing the new branch Jenkins will trigger the build for that branch. It is the right approach ?

Sure, it's worthwhile to have every commit on every branch tested, by the default, if you have the resources for that. It lets you know exactly which build broke everything. Coupled with very small commits, this is a quite powerful tool.

Another useful trigger is to not build every commit, but have Jenkins look at the repository every 15 minutes or so, and build if there is one more more new commits. This may be more realistic when your test suites take longer to run, and if you do not have unlimited amounts of test environments that you can spin up and down regularly.

(By the way, if you are completely new to all of this, including "agile" and branching, then maybe it would be good for you to pick up an existing branching strategy, for example Gitflow, so you don't complicate things too much by (re-)inventing too much stuff at the same time.)

Answer 2

We are planning to create new branch for each sprint.

It should be noted that this doesn't mean Continuous Integration, but rather just waterfall masquerading as CI, also known as CI Theatre.

Every branch you mention is nothing but a silo and merging it into the master branch can invalidate both the results obtained in the silo as well as those obtained so far in the master branch.

From the agile prospective you'd be constantly creating technical debt - the need to merge the silo branches into master, re-validating the merged result, identifying and fixing any problems that would appear after such merges. Never a known, quantifiable effort since you can't know right away which of the branch commit(s) is/are responsible.

The right approach would be to not pull such branches, instead every commit should be done on the master branch. You'd only have one Jenkins setup - on this master branch, executing verifications after every commit. No branch merges necessary, every commit is potentially ready for delivery/deployment once the CI execution is successfully completed.