My environment: Rally CA Agile Central, Jenkins, Bitbucket
Below is the project page that I have in Jenkins.
Code Coverage report done with Gocvr
Cppcheck
Unit Test with GoogleTest
I have a project that is divided among several Bitbucket repositories. Each of those repositories are a Jenkins Freestyle project. Each Jenkins Freestyle project will then have its own CPPCheck, Unit Test and code coverage report.
My question is if there is a way to summarize all those metrics together so it is easier during our meeting to have 1 place to go where to see all those Jenkins jobs in our project. Even see a general trend for the whole project (code coverage is going up / down, etc) and not just for each Jenkins Freestyle project individually.
I'm quite open to where these metrics can live. But, since we already are using CA-Rally and Jenkins and a lot of plugins/hooks are already developed, there is maybe something that already exists that could fulfill my needs.
Related
I've been asked to create a CI pipeline for a project at my work, I'm creating a load test with JMeter and Taurus so I plan to integrate it with Jenkins to build all the pipeline. I'm just starting on this field and a question that came to my mind is:
What happens to all the data created by the Load Test? does it goes to the deploy phase or it gets deleted once the test is done, should I clean after the tests end?
The data is being kept in the Jenkins workspace and by default it will be kept in the file system forever.
If you decide to publish the artifacts they will be available at Jenkins build dashboard via the web interface.
You might also be interested in Jenkins Performance Plugin which allows plotting performance trend charts and conditionally marking builds as unstable or failed depending on pass/fail thresholds
Example configuration can be found in the How to Run a Taurus Test through Jenkins Pipelines article
I am not completely familiar with your setup but as far as I can see from a quick research, JMeter does the same as every other testing framework and generates HTML reports. Jenkins wont delete them, unless you explicitly delete them (rm file.html) or call cleanWs (clean workspace). If the job is deleted so are the files.
So the test result file should still be present in the deploy phase. You can use a plugin to collect the result. Or just archive it. Or do whatever fits your workflow.
There is generally no need to clean it up (you usually configure Jenkins to delete old builds which takes care of that)
I'm using Jenkins and in particular pipelines. What's the difference between pipelines and Hudson jobs with multiple build steps?
When Kohsuke forked Jenkins from Hudson the entire developer community went with him. Oracle's grab for Hudson and attempt to make it proprietary killed Hudson overnight. This is well documented elsewhere. No one in their right mind should be using Hudson over Jenkins.
Hudson jobs are just freestyle jobs with a lot less functionality because Jenkins has, since forking, greatly increased the number of plugins as it had the developer community. Oracle had one guy sitting in a corner hacking on Hudson.
For one thing, Pipeline jobs allow you to version your job definitions in source control. Old school Freestyle jobs do not. To list all the other ways Jenkins is better than Hudson would require a million monkeys writing the works of Shakespeare!
I don't know where could I fit the jenkins tool in the following devops pipeline:
code -> integrate -> test -> release -> deploy -> operate
Maybe it can be in every steps ?
Jenkins is a build factory. In other words, its primary use is to run tasks that dedicated to build, integrate and deliver applications. It's a typical DEVOPS tool.
Jenkins can be used to build pipelines (sequences of tasks) or to be called from a pipeline (to execute one of the pipeline's tasks).
The great thing about Jenkins is that it integrates nicely with other devops tools:
SCM: SVN, Github, Gitlab
Build: maven, gradle
Test: Cucumber reports
Quality: SonarQube
Deployment: Octopus Deploy, XL Deploy, Run Deck...
You name it!
However, Jenkins is generally not used to "code" and "operated" applications.
A typical pipeline would be:
Try Pull Request => Build Release Candidate => Deploy RC on Integration => Deploy on Production
This is a over simplified pipeline, just to give an idea of the scope of this tool. A production grade piepline should include security checks, and integrate nicely with human validation when needed.
Jenkins is use for the Build, Test, and Deploy stages of the continuous delivery pipeline.
You can have "n" number of stages in a pipeline that can be configured using Jenkins.
Stages as follows (example) :-
code -> integrate -> test -> release -> deploy -> operate
Currently in the business sector Jenkins is used as follows:
If you are a software developer you need Jenkins for two reasons:
To build your project and check that it completes all the requirements concerning the pmd rules, checkstyles, findbugs, etc.
To deploy a new environment so to evaluate yourself. You need to see that the changes you made are the proper one and as you wanted them to be.
If you are a tester or a test automation engineer you want it two three reasons:
To build your code and check for findbugs, pmds and qaplugs generally
To test the software product, of the client or of your company's product
To create dynamic environments so to test the changes of the developers (mostly as a regression testing and not as an individual)
If you are a business related, project manager or supervisor you can do the next two actions:
Execute the tests so that you can see yourself if the product is working properly
Check the reports that Jenkins can give you every after test execution
Jenkins is an opensource automation server. Earlier it used to be a CI server only but after Jenkins 2.0, Pipeline as Code has made it popular for CI/CD both. It can manage all application lifecycle phases.
We work on .NET project, using TFS for:
source control
builds: gated check-ins that produce MSI files
deployments to Labs
We want to create a proper Continuous Delivery pipeline, that is a Dashboard with pipelines for each check-in with traffic lights.
Pipeline should show all the stages like TFS build > Deploy to Lab > Smoke test > Integration Tests > Acceptance Tests > Deploy to PreProd > ...
So it has to be tightly integrated with TFS.
We are assessing 2 options:
use TFS-based tool\plugin\dashboard if there are any that can show pipelines?
use CI tool for example Jenkins, TeamCity, Bamboo to build this pipeline - ideally with support to fetch built code from TFS drop folder, not just the source code
What would you recommend?
If you are using TFS why don't you leverage the built in Release Management tooling? You can create a release pipeline that is automted and even include approvals I necessary.
http://nakedalm.com/building-release-pipeline-release-management-visual-studio-2013/
If you want to integrate the lab tools for collecting test results as part of your pipeline this works as well.
http://nakedalm.com/execute-tests-release-management-visual-studio-2013/
This works pretty well and the new features anounced at Connect() will make it even better.
I would like to be able to configure centrally something like "build profiles" which I can apply to multiple projects in Jenkins.
For instance, I want to setup a compile, email, deploy chain to be used by several projects. When I change something in this chain, I want to automatically apply the changes to all linked projects.
Is there a convenient way to do this? I am also open to suggestions for other build systems, as long as they can deal with sbt projects.
I see there is a SBT plugin for Jenkins which looks popular-I haven't used it
I have used the jenkins job-dsl which covers sbt out the box. This works by a build step in a job to create/regenerate other jobs (with an optional template)
The problem with having a generic job building separate projects is that all the job history gets merged together. I think it is better to use stand-alone jobs for each task and the job-dsl will allow you to do that
TeamCity supports build configuration templates out of the box and recently added basic sbt support.