I need to set up a continuous integration system. We use ClearCase version control and only snapshot views due to platform restrictions. I have tried setting up Hudson and Luntbuild. They both show the same behaviour. In a view, we have lots of libraries that are used for build but are strictly read-only. The CI system executes cleartool lshistory and finds a change in the VCS. After that, it executes cleartool setcs, which causes update of the view. This can take about half an hour, which is very undesirable for CI. Why wouldn't it update only the changed elements, which were previously obtained by cleartool lshistory? Is there a CI system that can do this?
The update of a snapshot view with a lots of elements can takes time.
That is why we are using several view in our Hudson CI.
One with the minimum amount of elements, view which is monitored by Hudson and updated if a VCS change is detected.
One with the common stuff which does not change that often (if it changes, we will declenche the Hudson Job manually)
Other solution is, especially for the first view, to use a dynamic view (and skip the update loading times)
Yulia,
You may check out our Parabuild - it may work better for you. If not, we will be happy to work with you to resolve any performance issues.
Related
For some projects I use the CI service drone.io. Currently every time I make a commit to any of my branches, drone.io launches a build process. In some situations I consider this a waste of energy and resources and thus want to prevent unnecessary builds. Such situations are e.g.: Changed typos in README.md, working on a new feature and thereby committing some immature code
As far as I know there is no branch-wise configuration. However, this thread in the support forum indicates that via the .drone.yml some fine tuning seems possible. But still I do not know how to enable/disable builds on branch-level.
Alternatively, using some special tag in the commit message would also work for me.
You can use the where trigger to target a particular branch only, see where for the documentation.
Using where & branch you can trigger drone builds for changes to e.g. master only to cut down on unwanted builds. Try adding a block like this:
trigger:
branch:
- master
We recently adopted the concept of feature branches in one of our bigger projects, to segregate work on different aspects of the product that can be completed independently of each other.
For each so-called feature, we are creating the following:
a branch from 'main', aptly named after what the feature is supposed to be
a new team in the project portal, containing the people that will work on the feature
a build definition to validate check-ins against the source on the branch
The main point I would like to see discussed here is about the build definition. Currently, each one of them is set to gated checkins.
The question then, is: what is the best practice on associating work items to a build?
In our case, these feature branches are supposed to be disposable: we would like to be able to delete these builds/branches/teams later on when the feature is complete, but still be able to track them throughout the product lifecycle.
If I associate work items with these temporary builds, I'll lose tracking capability later on when the feature implementation ends. At the same time, I just found out that gated checkins always associate work items, regardless of what is configured in the build definition.
Would it be feasible to disable work item integration with the feature branches (in this case also converting them from gated to continuous integration) and enable it in the main build, so that these features can be tracked in the main product line? Or maybe this should be only enabled for Release build definitions, so that we can find out what was integrated on a certain release? For those of you who follow the sprint/feature concept, how do you handle this situation? Do you also have a build for each branch?
Update:
I just found something similar (but not exactly like what I wanted) in this question. The answer there lead me to a plugin that automatically associates work items on merge checkins. This should offer great traceability on it's own, so I think I'll give it a shot.
Would still like to hear what your thoughts are in regards to the builds in this scenario.
You're approaching this wrong IMO. You shouldn't be worrying about associating Builds and WI's, but rather associating Changesets and WI's. When your developers check-in changes in the feature branch you should ensure that they are linking them to the relevant WI(s). You can even enforce this via a Check-In Policy.
Now if you ever want to inspect that feature in the future to see all the changes associated with it, you can by inspecting the Feature WI, and looking at all linked Changesets. Even if you delete the branch all the Changesets are still available.
In order to achieve continuous integration , i thought of writing Clearcase triggers.
I came to know post operation trigger [after delivered to integration stream] will be useful for me.
I just seek an advice from my architect regarding implementation of trigger.
He told me not to use as triggers are troublesome in multisite environment.
Is this myth or true? Has any one faced problems which made their builds more annoying due to triggers?
Please suggest me is it safe to use triggers in multisite environment or not?
Your architect may have refered to this technote, which ponts out the fact that:
By design, trigger types must be created locally in each VOB.
Trigger types, unlike other metadata types (labels, attributes, branches, elements, hyperlink), cannot be created as global resources in an Administrative VOB because they cannot properly traverse hyperlinks; which is how the Administrative VOBs connect to their client VOBs.
You can try and copy a trigger:
The cptype (copy type) command creates a new type object that is a copy of an existing type object. The existing and new objects can be in the same VOB, or in different VOBs. The copy can have the same name as the original only if you are making the copy in a different VOB.
But:
The two objects, original and copy, do not retain any connection after you execute this command.
They are merely two objects with the same properties, and perhaps even the same name. If there are any changes made to the trigger, such as by using cleartool mktrtype -replace, then those changes must be made manually to each copy of the trigger, or you must perform the copy again using the -replace switch; see the cptype reference page for more information.
I would recommend using an external system to monitor, trigger and report on your continuous integration.
You can either:
simplify your ClearCase setup by using CCRC instead of the multi-site workflow.
In which case, the article "Continuous integration with IBM Rational ClearCase Remote Client" can help (you don't have to use CruiseControl: Jenkins or Hudson or TeamCity are equally good in this case)
more generally letting a CI tools (again: CruiseControl: Jenkins or Hudson or TeamCity) monitor a specific view which said CI tool updates regularely, detect any changes and trigger the build. See "Realizing continuous integration".
I decided to use the following pattern after reading semantic versioning at http://semver.org/. However, I have some unsolved issues in my mind in terms of automaticng and integrating SDLC tools.
Version Pattern:
major.minor.revision.build
Such that;
Major: major changes, should be increamented manually.
Minor: minor changes, should be increamented automatically, whenever a new feature or an enhancement to existing feature is solved in issue tracking system.
Revision: changes not affecting the minor changes, should be increamented automatically, whenever a bug is solved in issue tracking system.
Assume that developers never commit the source unless an issue has been solved in issue tracking system, and the issue tracking system is JIRA in this configuration. This means that there are bugs, improvements, and new features as issue types by default, apart from the tasks.
Furthermore, I am adding a continous integration tool in this configuration, and assume that it is bamboo (by the way, I never used bamboo before, I used Hudson), and I am using Eclipse IDE with mylyn plugin and plus the project is a Maven project (web).
Now, I want to elucidate what I want to do by illustrating following scenario. Analyst (A) opens an issue (I), which is a new feature, related to Maven project (P). As a developer (D), I receive an email about the issue, and I open the task via Mylyn interface in Eclipse. I understand and develop the new feature related to issue (I). Consider, I am a Test Driven Development oriented developer, thus I wrote the Unit, DBUnit, and User-Acceptance (for example using Selenium) tests correspondingly. Finally, I commit the changes to the source control. I think the rest should be cycled automatically but I don't know how can I achieve this? The auto-cycled part is the following:
The Source Control System should have a post-hook script that triggers the Continous integration tool to build the project (P). While building, in the proper phase the test code should be run, and their reports generated. The user-acceptance test should be performed in a dedicated server (For example, jboss, or Tomcat). The order of this acceptance test should be, up the server, run the UA test, then generate the UA test reports and down the server. If all these steps have been successfuly completed, the versioning should be performed. In versioning part, the Maven plugin, or what so ever, should take the number of issues solved from the Issue Tracking System, and increment the related version fragments (minor and revision), at last appends the build number. The fragments of the version may be saved in manifest file in order to show it in User Interface. Last but not the least, the CI tool should deploy it in Test environment. That's all auto-cycled processes I want.
The deployment of the artifact to the production environment should be done automatically or manually?
Let's start with the side question: On the automatic deployment to production, this requires the sign off of "the business" whomever that is. How good do your tests need to be to automatically push to production? Are they good enough that you trust things to just go live? What's your downtime? Is that acceptable? If your tests miss something, can you rollback? Are you monitoring production so you know if you've introduced problems? Generally, the answers to enough of these questions is negative enough that you can't auto-deploy there as the result of a build / autotest event.
As for the tracking, you'll need a few things. You'll need all your assumptions to be true (which I doubt they are, but if you get there that's awesome). You'll also need a build number that can be incremented after build time based on test results. You'll need source changes to be annotated with bug ids. You'll need the build system to parse the source changes and make associations with issues. You'll need an API into the build system so you can get the count of issues associated with the build. Finally you'll need your own bit of scripting to do the query and update the build number accordingly.
That's totally doable, but is it really worth having? What's the value you attach to the numbering scheme?
I've been dealing with the problem of scaling CI at my company and at the same time trying to figure out which approach to take when it comes to CI and multiple branches. There is a similar question at stackoverflow, Multiple feature branches and continuous integration. I've started a new one because I'd like to get more of discussion and provide some analysis in the question.
So far I've found that there are 2 main approaches that I can take (or maybe some others???).
Multiple set of jobs (talking about Jenkins/Hudson here) per branch
Write tooling to manage the extra jobs
Create/modify/delete Jobs in bulk
Custom settings for each job per branch (SCM url, dep management repos duplications)
Some examples of people tackling this problem with shell tools, ant scripts and Jenkins CLI. See:
http://jenkins.361315.n4.nabble.com/Multiple-branches-best-practice-td2306578.html
http://jenkins.361315.n4.nabble.com/Is-it-possible-to-handle-multiple-branches-where-some-jobs-should-run-on-each-one-without-duplicatin-td954729.html
http://jenkins.361315.n4.nabble.com/Parallel-development-with-branches-td1013013.html
Configure or Create hudson job automatically
Will cause more load on your CI cluster
Feedback cycle for devs slows down (if the infrastructure cannot handle the new load)
Multiple set of jobs per 2 branches (dev & stable)
Manage the two sets manually (if you change the conf of a job then be sure to change in the other branch)
PITA but at least so few to manage
Other extra branches won't get a full test suite before they get pushed to dev
Unsatisfied devs. Why should a dev care about CI scaling problems. He has a simple request, when I branch I would like to test my code. Simple.
So it seems if I want to provide devs with CI for their own custom branches I need special tooling for Jenkins (API or shellscripts or something?) and handle scaling. Or I can tell them to merge more often to DEV and live without CI on custom branches. Which one would you take or are there other options?
When you talk about scaling CI you're really talking about scaling the use of your CI server to handle all your feature branches along with your mainline. Initially this looks like a good approach as the developers in a branch get all the advantages of the automated testing that the CI jobs include. However, you run into problems managing the CI server jobs (like you have discovered) and more importantly, you aren't really doing CI. Yes, you are using a CI server, but you aren't continuously integrating the code from all of your developers.
Performing real CI means that all of your developers are committing regularly to the mainline. Easy to say, but the hard part is doing it without breaking your application. I highly recommend you look at Continuous Delivery, especially the Keeping Your Application Releasable section in Chapter 13: Managing Components and Dependencies. The main points are:
Hide new functionality until it's finished (A.K.A Feature Toggles).
Make all changes incrementally as a series of small changes, each of which is releasable.
Use branch by abstraction to make large-scale changes to the codebase.
Use components to decouple parts of your application that change at different rates.
They are pretty self explanatory except branch by abstraction. This is just a fancy term for:
Create an abstraction over the part of the system that you need to change.
Refactor the rest of the system to use the abstraction layer.
Create a new implementation, which is not part of the production code path until complete.
Update your abstraction layer to delegate to your new implementation.
Remove the old implementation.
Remove the abstraction layer if it is no longer appropriate.
The following paragraph from the Branches, Streams, and Continuous Integration section in Chapter 14: Advanced Version Control summarises the impacts.
The incremental approach certainly requires more discipline and care - and indeed more creativity - than creating a branch and diving gung-ho into re-architecting and developing new functionality. But it significantly reduces the risk of your changes breaking the application, and will save your and your team a great deal of time merging, fixing breakages, and getting your application into a deployable state.
It takes quite a mind shift to give up feature branches and you will always get resistance. In my experience this resistance is based on developers not feeling safe committing code the the mainline and this is a reasonable concern. This in turn usually stems from a lack of knowledge, confidence or experience with the techniques listed above and possibly with the lack of confidence with your automated tests. The former can be solved with training and developer support. The latter is a far more difficult problem to deal with, however branching doesn't provide any extra real safety, it just defers the problem until the developers feel confident enough with their code.
I would set up separate jobs for each branch. I've done this before and it isn't hard to manage and set up if you've set up Hudson/Jenkins correctly. A quick way to create multiple jobs is to copy from an existing job that has similar requirements and modify them as needed. I'm not sure if you want to allow each developer to setup their own jobs for their own branches, but it isn't much work for one person (i.e. a build manager) to manage. Once the custom branches have been merged into stable branches, corresponding jobs can be removed when they are no longer necessary.
If you're worried about the load on the CI server, you could set up separate instances of the CI or even separate slaves to help balance the load across multiple servers. Make sure that the server you are running Hudson/Jenkins on is adequate. I've used Apache Tomcat and just had to ensure that it had enough memory and processing power to process the build queue.
It's important to be clear on what you want to achieve using CI and then figure out a way to implement it without much manual effort or duplication. There's nothing wrong with using other external tools or scripts that are executed by your CI server that help simplify your overall build management process.
I would choose dev+stable branches. And if you still want custom branches and afraid of the load, then why not move these custom ones to the cloud and let developers manage it themselves, e.g. http://cloudbees.com/dev.cb
This is the company where Kohsuke is now.
There is an Eclipse Tooling also, so if you are on Eclipse, you will have it tightly integrated right into dev env.
Actually what is really problematic is build isolation with feature branches. In our company we have a set of separate maven projects all be part of a larger distribution. These projects are maintained by different teams but for each distribution all projects need to be released. A featurebranch may now overlap from one project to another and thats when build isolation gets painfully. There are several solutions we've tried:
create separate snapshot repositories in nexus for each feature branch
share local repositories on dedicated slaves
use the repository-server-plugin with upstream repositories
build all within one job with one private repository
As a matter of fact, the last solution is the most promising. All other solutions lack in one or another way. Together with the job-dsl plugin it is easy to setup a new feature branch. simply copy and paste the groovy script, adapt branches and let the seed job create the new jobs. Make sure that the seed job removes nonmanaged jobs. Then you can easily scale with feature branches over different maven projects.
But as tom said well above, it would be nicer to overcome the necessity of feature branches and teach devs to integrate cleanly, but that is a longer process and the outcome is not clear with many legacy system parts you won't touch any more.
my 2 cents