1

I'm in charge to implement CI in my company. But now I have a doubt. Which one is the best?

Should I create 3 distinguished job for every system/software as

  1. Build and quality test for the code
  2. Build, quality test and deployment on test enviromment
  3. Build, quality test and deployment on production

Or is better create downstream conditional jobs, like here: How to conditionally build other projects?

The trunk always will have the last version in production.

For every change, the developer has to make a copy from trunk to branch, work on the code then call jenkins to run in the branch to homologate the changes. Once the homologation has done and it's ok, the developer will call jenkins again to deploy that code from branch to production.

As @michaelbahr said [this post is edited] I can just get the last homologation version from a artifact repository, but how can I copy/merge the code from branch to trunk automatically with jenkins after it gets the package from homologation(test) environment and move it to production?

Improve this question

2 Answers 2

Reset to default
1

As you say that you are in charge to implement CI, I assume that your company does not have a lot of CI experience. Thus I recommend two seperate jobs instead of a downstream pipeline.

The first job should automatically be triggered upon changes in your code repository through a post-commit hook. It builds, tests and deploys the package to a testing environment. It should also deploy the snapshot package to an artifact repository like Nexus.

If you are all happy with the results you can then manually trigger the second job that grabs the package from the artifact repository and deploys it to production (and verifies that the deployment was successful). There is no need in building a package again that you are already confident in.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Thanks for the answer michael, but in this model how can I put the code of what is in production back to trunk in subversion, once the test will came from branch?
Could you clarify that question? You deliver a complete and fully tested package to production. Tests are run in testing/development environment, NOT in production. I see no need to put something from production back to subversion.
1

Which approach is best depends on the quality of your engineering, tests, and processes. One approach - is to do all three in one job (which may chain other jobs as needed).

For example:

Using the MultiJob Plugin, and Validated Merge Plugin the workflow is like this:

  1. Developer pushes code to JENKINS (git push) rather than the SCM repo.
  2. Jenkins builds the code, runs unit tests and makes the results available locally - or better in a repository.
  3. Additional job(s) are invoked (in order) to Install and run built code and integration tests in an integration environment. Note that with the Multi Job plugin tests can be run in parallel across many environments at once. Upon success of ALL test jobs validated merge accepts the changes into the repository. (If failure, the developer changes are not added to the repository).
  4. Another subsequent job takes the successful results and deploys to production.
  5. An integration clean up job may be used to reset the integration environment.

Note that having a separate job to do the deployment to production also allows for redeploy at any given time. The production deployment can also be severed from the automation if deemed suspect.

Finally, note that an insufficient level of testing accuracy or completeness makes for a dangerously unstable system!

Improve this answer

2 Comments

Validated Merge Plugin is available to CloudBees Jenkins only. But thanks for your answer
You can implement something similar (but more primitive) by having a job or script in Step 3 above that merges and pushes to the "source of truth" repo. The push to git can be handled with a webhook that starts the process, or more primitively, by doing scm polling.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.