|
I'm looking for opinions and discussion. We're currently evaluating Continuous Integrations tools, and in particular Hudson and CruiseControl.NET. I have a lot of experience already with CCNet having used it for the past few years at my previous two jobs. However, Hudson seems to have really taken off and is getting great reviews.
We use TFS for our source control and build process, so we need to easily integrate with those.
What are people's thoughts? What CI tool do you use and why? All feedback welcome.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I started with Hudson, and later changed to Jenkins (which is actually a fork of Hudson; my impression is that more development happens on Jenkins nowadays than on Hudson). They are easy to configure, it has a web interface, there is no need to work with the configuration files directly.
I don't use TFS, hence the process is different. Jenkins polls the subversion repository, checks out new sources, build the products, tests them. I do not know how to integrate that with TFS.
By the way, can't TFS do the UnitTests, copy the artifacts to some other place, etc?
|
|
|
|
|
My understanding was that Jenkins and Hudson were the same product, I didn't realise one was a fork from the other.
With CruiseControl.NET you manually edit the config files, which isn't difficult as there is loads of documentation on how you need to do this.
At this point in time we're simply evaluating if the CI tools that are currently out there. Although we use TFS for our version control, we're still looking at other options. We're re-evaluating our entire build process, and that includes TFS. Moving over to Github is also being considered. At this point in time nothing is being ruled out.
We want to evaluate and consider all the options so we choose the best process and tools that fit the business going forwards.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
TFS gives you the ability continuously integrate your code. Also, with MS Release Management, you can achieve continuous deployments with TFS. TFS & RM work seamlessly with Visual Studio.
What are your major points of concern / consideration & evaluation?
|
|
|
|
|
One of our major concerns with TFS is that it isn't easy to work with it in a remote deployment where you have remote workers. Some of our development team are co-located and we would prefer to use a version control / build process management system that offers distributed deployment. Hence why we are looking at replacing TFS with Github / Github.
As part of evaluating our toolchain we're also looking into what continuous integration tools fit our requirements. The main contenders are
- CruiseControl.NET
- Jenkins
- TeamCity
Each has its merits. I have personal experience of CruiseControl.NET, whilst one of the other devs has used Jenkins. TeamCity is from the same company that makes Resharper and looks very professional with some excellent features.
Just looking for suggestions, advice etc to help make a decision.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
TFS has a web interface too. You can check-in your code, create build definitions, trigger your build on check-ins, create custom alerts & notifications, use MS Build or customize your Build process entirely using build process templates, Add unit testing, code coverage, automated testing (Coded UI, etc.) & Kick off a build with Release Management or Octopus Deploy or Jenkins or really any other.
Regards,
Ajay Bhosle
+919920966336
|
|
|
|
|
Rather certain that I have done all of that and did it definitely more than 5 years ago without TFS and using Jenkins I believe. So if those are new features in TFS then maybe it is playing catch up.
Might note that it was done with C# too so that isn't a limitation.
|
|
|
|
|
You can change any TFS query using the Query Editor, and add further details like the parent PBI, which should give more information, or assigned to etc.
When you click on MyTasks query, Default is "Results", which the result of your query, and the below window shows details of the work items. To edit the query, navigate to the "Editor" link. Here, you can change the Type of Query to use Tree of work items, which gives you nested results. OR work items & direct links, which helps you present all the links to your work item.
Thanks,
Ajay Bhosle
http://dralm.blogspot.in
|
|
|
|
|
It should not take longer than 5 minutes and does not require from you any demographic data other than stating whether youre developer or agile coach.
The link to survey is: http://educ.sphinxonline.net/v4/s/cribkm[^]
Thank you for your help!!!
|
|
|
|
|
Your link does not work.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
I'm wondering how other people manage common, utility or shared code?
Say some extension method's etc.
Do you just add a file with this code and share it amongst your projects?
Do you have a snippet type program and just copy/paste into/out of that?
Or do you build up a separate library and reference that?
If you do the latter how much do you put in, i.e. do you think there's an issue with that library containing much more code than you need?
|
|
|
|
|
By definition common code can not be snippet - snippet is for repeated code structures not for repeated code!
IMHO the best way is a separate library. I'm also do such utility methods stateless an static.
I'm also think that there is no such a thing too large library - it only a matter of code organization. There is nothing wrong with a single library with thousands of methods (if the project requests it) as long as the methods are organized...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
Thanks for that, I went down that route, and created a set of libraries by function (IO/data/etc) rather than one large single library.
|
|
|
|
|
You may consider an other addition to that...
I'm creating my libraries in a totally different solution (no as part of my main development solution) than create a local nuget package from the outcome and add it as reference - that handles me all the necessary dependencies an updates every time I update the util libraries...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
Similar to Eliyahu, I prefer a Utility library for such code. I'd write one file for each type which gets extended by an extension method (my way of code organisation). Similarly, other utility methods get grouped into files by their underlying business object.
|
|
|
|
|
Depends.
First, one be sure that the shared code really should be shared. The fact that it seems like it is common functionality doesn't necessarily mean that it will remain that way. (Really a bad idea to start adding conditional logic to control different logic flows due to different applications.)
Second, how is the rest of the business applications structured. Primary if you have two applications X and Y that you want to use your common code M, do X and Y have their own delivery schedules or are they always delivered together. If they have their own deliver schedules then a common library MUST have its own delivery schedule as well. That is the only way to insure that X is using the version of M that it was developed with and Y is doing the same.
Third if different deliver schedules are needed then one must deal with different versioned apps, and if one must deal with git as the source control system then one has a problem since git only deals with that via different repositories.
There are additional issues depending on what language is being used and how applications are delivered.
|
|
|
|
|
I have a separate project in my solution that contains such code i.e. code that is shared across other parts of the application. This can then be distributed as a self contained assembly. If using .NET then you have the option of placing this assembly in the GAC where other applications can also use the same functionality.
|
|
|
|
|
We have probably all developed those Visual Studio applications which rely on additional DLLs and static libraries containing our favorite snippets of code. My question is how best to manage this kind of project which is not all neatly contained in the project folder. If we add our library paths (elsewhere on the disk) to the project then we can be sure that we are linking with the latest versions of the libraries but archiving this arrangement is a nightmare. Another alternative might be to copy all the libs to a 'lib' folder within the application that we are developing. This would provide a self-contained project which could easily be archived but we may not be using the latest version of our libs.
I would be very interested to hear what other developers do. Is there a better way! 
Thanks
Tony
|
|
|
|
|
|
softwaremonkey wrote: but we may not be using the latest version of our libs.
However you will in fact be using the same one in development, QA and production. And be more likely to label it in source control so you can keep track of it.
Thus if a problem occurs in QA or production then you are more likely to be able to reproduce it. And when you do update to new versions as part of a development and business decision then development and QA can more fully verity that it continues to work as expected.
|
|
|
|
|
Thanks, that is a very good point and a compelling reason to 'ring fence' every file needed to build a particular version of an application including the libraries.
|
|
|
|
|
Try setting up your own nuget repository, especially if you share components across projects
|
|
|
|
|
Can anyone share me information about ALM tool users and their usage level ?
Its urgent   i tried my best in researching it....looking up for someone to help me with this
|
|
|
|
|
oberon29 wrote: Its urgent
We're volunteers. You can't hurry volunteers, it's not urgent here.
I don't think anyone measured the usage-level of various application lifecycle management tools. You could consult Google to find out what's most used.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Quote:
Source Error:
Line 948: <panelcollection>
Line 949:<dx:panelcontent id="PanelContent1" runat="server" supportsdisabledattribute="True">
Line 950: <dx:aspxpagecontrol id="ASPxPageControl3" runat="server" activetabindex="1"
line="" 951:="" width="100%" cssfilepath="~/App_Themes/Glass/{0}/styles.css" 952:="" csspostfix="Glass" spritecssfilepath="~/App_Themes/Glass/{0}/sprite.css" <="" blockquote="">
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
