Answers: <blockquote>
    <p>We are planning to create new branch for each sprint.</p>
  </blockquote>
  
  <p>It should be noted that this doesn't mean Continuous Integration, but rather just waterfall masquerading as CI, also known as <a href="https://www.gocd.org/2017/05/16/its-not-CI-its-CI-theatre.html" rel="nofollow noreferrer">CI Theatre</a>. </p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-12-06T17:46:42.500Z
Answers: Do you mean push to master directly instead of creating pull requests?
Answers: 030
Answers: CC BY-SA 3.0
Answers: 2017-12-06T18:18:38.577Z
Answers: Push to master is truly CI. PRs may be acceptable, if they're done for every developer commit (or at least daily), not at the end of the sprint.
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2017-12-06T18:35:10.530Z
Answers: If code is broken in a branch, it should be prevented that this is merged into master, i.e. production.
Answers: 030
Answers: CC BY-SA 3.0
Answers: 2017-12-06T18:46:46.850Z
Answers: @030 Code working in a branch doesn't offer any guarantees it'll still be working after merging into master. It has to be re-qualified. But then, again, that's not CI.
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2017-12-07T01:28:54.603Z
Answers: I agree with @Dan. CI dictates that every change must be Continuously Integrated with the main "branch" which ever it is. A feature branch is not continuous as it allow a team to create a parallel zone where none of the commits are integrated and validated with the main "branch". And the longer you wait, the further you distance yourself from reality.
Answers: gmolaire
Answers: CC BY-SA 3.0
Answers: 2017-12-08T19:03:09.730Z
Answers: Testing code in a branch _does_ guarantee it will be working after merging to master if your tests merge the code with master before running tests.  AFAIK this is the default for most popular CI implementations.
Answers: jayhendren
Answers: CC BY-SA 3.0
Answers: 2017-12-09T03:01:36.100Z
Answers: @jayhendren: so you're testing twice: once to integrate the change into the branch and then again after merging the branch with master. What I meant was that a pass in the 1st test doesn't guarantee a pass in the 2nd. And the 2nd time if the tests fail you don't have any hint about the culprit: is it a change in master or a change in the branch? Which one? And you can't even commit the merge to master (i.e. NONE of the changes integrated into the branch can be integrated into master) until you find and fix all the problem(s) found in testing. Yes, I recognize that: waterfall :)
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2017-12-11T18:15:47.510Z
Answers: No, I only test once. "What I meant was that a pass in the 1st test doesn't guarantee a pass in the 2nd." Yes it does if, in your test suite, you do a merge against master first and then test. If master is updated before the PR is closed/merged, re run tests. This is definitely CI: code is constantly merged (integrated).
Answers: jayhendren
Answers: CC BY-SA 3.0
Answers: 2017-12-06T15:46:26.953Z
Answers: 2017-12-06T15:46:26.953Z
Answers: Dan Cornilescu
Answers: <p>Continuous <em>integration</em> 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.</p>
  
  <p>Continuous <em>deployment</em> takes this a step further and whenever a green light turns up, automatically deploys that.</p>
  
  <p>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.</p>
  
  <p>To your questions:</p>
  
  <blockquote>
    <p>But in my organization there is no expertise who clearly tell us about how CI tool actually used in real time.</p>
  </blockquote>
  
  <p>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.</p>
  
  <blockquote>
    <p>So we are not aware of the scope and expansions of the Automation project in terms of CI tool.</p>
  </blockquote>
  
  <p>The more automation, the merrier. Automation not only means shaving off a few minutes here and there (but this factor also pays of <em>hugely</em> 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.</p>
  
  <blockquote>
    <p>manage the release using Jenkins ?</p>
  </blockquote>
  
  <p>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).</p>
  
  <blockquote>
    <p>the terms Jenkins pipeline confused me what it is and why it used for?</p>
  </blockquote>
  
  <p>"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.</p>
  
  <blockquote>
    <p>So after committing the new branch Jenkins will trigger the build for that branch. It is the right approach ?</p>
  </blockquote>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>(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.)</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-12-06T07:40:29.593Z
Answers: 2017-12-06T12:23:45.940Z
Answers: 2017-12-06T12:23:45.940Z
Answers: AnoE
Body: <p>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.</p>
  
  <p>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?</p>
  
  <p>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 ?</p>
  
Tags: <jenkins><continuous-integration><jenkins-pipeline>
Title: How to perform continuous Integration using Jenkins?
UserDisplayName: NarendraR
ThreadText: # How to perform continuous Integration using Jenkins?
  
  (Asked by: username_0 on 2017-12-06)
  
  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 ?
  
  **Tags:** jenkins, continuous-integration, jenkins-pipeline
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_5 on 2017-12-06. Score: 6 | Accepted answer
  
  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 by username_1 on 2017-12-06. Score: 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](https://www.gocd.org/2017/05/16/its-not-CI-its-CI-theatre.html).
  
  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.
  
  > **Comments:**
  > **username_2**: Do you mean push to master directly instead of creating pull requests?  
  > **username_1**: Push to master is truly CI. PRs may be acceptable, if they're done for every developer commit (or at least daily), not at the end of the sprint.  
  > **username_2**: If code is broken in a branch, it should be prevented that this is merged into master, i.e. production.  
  > **username_1**: @username_2 Code working in a branch doesn't offer any guarantees it'll still be working after merging into master. It has to be re-qualified. But then, again, that's not CI.  
  > **username_3**: I agree with @Dan. CI dictates that every change must be Continuously Integrated with the main "branch" which ever it is. A feature branch is not continuous as it allow a team to create a parallel zone where none of the commits are integrated and validated with the main "branch". And the longer you wait, the further you distance yourself from reality.  
  > **username_4**: Testing code in a branch _does_ guarantee it will be working after merging to master if your tests merge the code with master before running tests.  AFAIK this is the default for most popular CI implementations.  
  > **username_1**: @username_4: so you're testing twice: once to integrate the change into the branch and then again after merging the branch with master. What I meant was that a pass in the 1st test doesn't guarantee a pass in the 2nd. And the 2nd time if the tests fail you don't have any hint about the culprit: is it a change in master or a change in the branch? Which one? And you can't even commit the merge to master (i.e. NONE of the changes integrated into the branch can be integrated into master) until you find and fix all the problem(s) found in testing. Yes, I recognize that: waterfall :)  
  > **username_4**: No, I only test once. "What I meant was that a pass in the 1st test doesn't guarantee a pass in the 2nd." Yes it does if, in your test suite, you do a merge against master first and then test. If master is updated before the PR is closed/merged, re run tests. This is definitely CI: code is constantly merged (integrated).  
  
  ---
  
  