CODEWITHSUNDEEP
svnjenkinscontinuous-integration
Joao Vitorino
Joao Vitorino

Reputation: 3256

Workflow to jenkins

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?

Upvotes: 1

Views: 184

Answers (2)

Steven the Easily Amused
Steven the Easily Amused

Reputation: 795

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!

Upvotes: 1

michaelbahr
michaelbahr

Reputation: 4953

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.

Upvotes: 1

Related Questions