If you used the following:
Continuous Integration using build scripts
IDE for code development
Do you run into problems of synchronizing your build scripts with the IDE build system? If so, how do you resolve this kind of issue? Using any environment (Java/.NET/etc) to explain the solution will do. I just want to get ideas on how people solve this problem.
In Java world you can have 2 kind of scripts - build scripts & scripts to generate project file for your favorite IDE (ipr for IDEA for example). Such that if you project's structure have changed just re-run the script that will update .ipr file, for example. Also, various people in the team can work with different IDEs.
In .NET world there are 2 options:
if you build with MSBuild then you don't need to synchronize anything - .csproj files from VS are valid MSBuild files as well.
if you build with NAnt you can run devenv task that will go to .sln file and still call .csproj files that are always up to date.
Related
I have a complex project that uses a Ruby::Rake system to generate java (and other) code and do a bunch of other complex things. But I also really like the intellij-idea editor debugger for java etc.
I would want to use my existing scripts I have for various build stages and even dependency checking, code generation before compile, (maybe even the compiling too) generating and deploying data for tests, deploying output to embedded devices, packaging etc etc.
This would be like custom build steps in VisualStudio or "makefile build".
and if one compiles the java with the script, can it's output be directed to play nicely with the IDE for navigating errors and the like.
Ant doesn't do it for me :)
IntelliJ IDEA build system can be integrated with Ant or Maven in the way that it can execute targets automatically before compilation and upon other events. It doesn't work for Rake, but you can wrap rake call into a simple Ant target with exec task.
This way Ant will run rake that will generate java code that will be compiled by IntelliJ IDEA if source root is set to the location where sources are generated.
Do you have some opinion for code coverage in Hudson.. Now i have build with Msbuild and MSTest and that's work.
But for code coverage, i think i need some help. I have searched that somebody use nCover another with Emma. Which one is better and more easier ? And maybe reference to help me.
Best regard,
Are you .NET (NCover) or Java (Emma) or both?
NCover should work with Hudson but costs
Open Source projects exist look for PartCover and more recently OpenCover.
All three .NET tools support command-line and as such they should integrate with Hudson.
We are currently using dotCover by JetBrains. It's cheaper than NCover and it integrates well with Visual Studio. You don't have to use a separate application (NCover Explorer) to view your code with the covered/uncovered highlighting, which is great.
The command line version of dotCover allows you to create XML files of the analysis and you can parse the XML via <XmlRead> (in the MSBuild Community Tasks library) to parse the output.
It takes a while to get set up properly, but it works.
I have written several scripts for my hudson builds. I have place them in the workspace of the particular job i am working on.
I was hoping to know where the best place to put the scripts. Is somewhere in the file system then best place? What if we move build machines? Does hudson designate a place for scripts?
Please and thank you.
I would suggest putting them inside your project folder /hudson/jobs/MyProject instead of inside the workspace. The workspace could be overwritten.
Do you use source control? If so you can put them in there and get hudson to pull them from there...
If these scripts are related to a particular project, bundle them with the project. Don't put them somewhere else.
If these scripts are used for more then one project, put them in your source control as a a separate project. Than you can pull them down every time you pull your project. If your scm plugin for hudson does not support configuring two separate sources (like subversion does), then just pull the build script using a command line tool for your scm as your first build step.
Build scripts need to be versioned the same way as you code is versioned.
We have a code base composed of many projects. Currently each time we add a project on SVN we must reconfigure CruiseControl to start build and test on such project.
I'm looking for a tool (better if open source) able to scan the SVN repository and find new projects by itself.
A project can be "a SVN folder containing trunk, tags, branches subfolders".
Even better if the tool supports multistaged continous integration and build on demand.
Thanks
In general, projects tend to be just different enough to require the build system to be set-up manually. However, you could probably use something like Jenkins with some bash scripts to achieve what you're looking for; eg. if your SVN server has an HTML index of all the projects, you could set up a bash script to poll that page for changes then tell Jenkins to add a new project from a template.
This is my second question on Bamboo (My First One). My understanding after reading suggested info, I need a build tool, like nAnt or MSbuild to write a script that gets the source code and builds it (I am working on a .net 3.5 with silverlight project). After, when deploying, I need to write scripts to move my files to the diff servers. Please tell me whether I am going in the right direction or not. Can I use ant, maven, bash scripts to do the same with a .net project?
Yes, that is true:
Bamboo is the central management server which coordinates all work
Bamboo itself has interfaces and plugins for lots of types of work
Bamboo basically needs to first get your source from a source repository (lots of plugins here for a variety of systems)
Then it needs to do the build - that can be done by using MSBuild to build your Visual Studio solution, or it could be a batch file to call your XYZ compiler and linker to create your app - whatever it is you have and use
Once your solution or project is built, you have "artifacts" (build results, e.g. executable app, config files, etc.) lying around
with those results, you can do additional things:
zip them up into a ZIP file and copy them somewhere
run a install builder on them and create an MSI
install them on a test server to make sure everything installs just fine
The sky's the limit! :-)
But in general: Bamboo is just the "orchestrator" - the coordinator. The actual work is done by either direct Bamboo plugins (of which there are plenty), or then you can call external command-line apps by means of a unix script or Windows batch file.
Marc