We have a Jenkins server running on a Linux box and we are using it for Java projects (Maven builds).
We shall have a couple of .NET applications coming up. Shall I be able to build them on the Linux box? Do I need to add a windows box? Any help will be appreciated.
If these are .NET Framework (and not .NET Core) applications, the easiest way to go about it is to add a Windows box with everything you need for building your .NET apps (e.g. install .NET Build tools), etc. and then setup a Jenkins slave on that box.
Then on your builds for .NET, you specify a requirement to use the slave on the Windows box to build it.
N.B. Keep the Windows build node as clean as possible - i.e. Resist the temptation and do not install the full Visual Studio on it (!). Only install the SDKs you need.
Related
I am developing a Sitecore solution locally using TDS. Our source control and build server is Visual Studio Team Services (in the cloud). I would like to figure out a way to implement Continuous Integration and get builds to be automatically installed on an Integration server that is an Amazon VM (or it could be some other externally located server). I have the TDS build configuration set up to create a Sitecore Update Package. The build process works great. At the end of the build process I have the Sitecore Update Package sitting in a Drops folder in source control (TFS in the cloud). Now I can't figure out how to automate the process of getting that update package out of source control and downloading it to the Integration server and running the Sitecore command to install it.
In a perfect world you would use something along the lines of a fancy Microsoft Release Management to deploy it to the environment of choice. However, if you are like the majority of us mere mortals without the fancy tools - this should help: https://github.com/adoprog/Sitecore-Deployment-Helpers
With these pages you could just send a get request from TFS or use the logic to write a custom PowerShell post-build script. Hope this helps!
As you are using TFS you get to use Release Management for Visual Studio out of the box. This is a simple install but at this time is separate. I have an instance of RM running in a VM and attached to my VSO instance for running deployments.
I would expect this tool, which was bought by MS last year, would become more integrated in vNext.
We're deploying a set of Build Controllers and Agents throughout our infrastructure to build Web/MVC applications and deploy them using Release Management through TFS 2013.
I read that we need to have Visual Studio installed on the build machines to compile properly, and would like to know if we are able to use Visual Studio Shell (Integrated? Isolated?) or if we need to dedicate a full (Ultimate or Professional) Visual Studio to it.
Thanks in advance--
==Update 10:33 5/5/2014==
Due to the security restrictions placed on our development group, we are unable to use off-premise resources.
==Update 12:47 5/5/2014==
Installing the MSBuild Redistributable (via Erik Funkenbusch) was a good start, and following Jimmy's advice sealed it. Thanks!
The components needed to build Web Applications (of which MVC is a subtype) are in \Program Files (x86)\msbuild\Microsoft\VisualStudio\v12.0\WebApplications (or whichever version of VS you're building against). While these are installed by VS, you can just xcopy them to your build servers without the rest of the VS installation.
No, you don't need Visual Studio installed on the build machine, and wherever you read that... run far away, because they don't know what they're talking about.
In fact, it's explicitly recommended to NOT install Visual Studio on the build machine.
Microsoft has a full MSBuild redistributable with 2013 components. MVC is installed as part of the build via Nuget (along with other components).
http://www.microsoft.com/en-us/download/details.aspx?id=40760
In past years, you had to install the Windows SDK, and do a lot of manual configuration, and that was a pain. With 2013, they've made this much simpler.
I believe the Release Management should also have an installation setup file to install components for build servers....
You don't need Visual Studio for just doing compilation as part of the build process. If you have unit test cases which needs to be run then you need Visual Studio.
I want to create MSI build package as part of a TFS build.
What options there are?
i know about:
install VS on TFS server (http://geekswithblogs.net/jakob/archive/2010/05/14/building-visual-studio-setup-projects-with-tfs-2010-team-build.aspx)
Use 3rd party software on tfs
I do not wish to rely on 3rd party software or install vs 2010 on server as i have no licence to spare
Wix: http://wix.sourceforge.net/
It can be invoked using MsBuild.
I am using it quite successfully in one of my projects
This page gives some info on what is needed http://wix.sourceforge.net/manual-wix3/authoring_first_msbuild_project.htm
You should create the MSI Build package on TFS Build the same way you do it locally.
If you don't have anything yet, I strongly encourage you to look at Wix and use it. However Wix is mainly lowlevel package generation for MSI.
If you have complex needs for installation wizard you may rely on InstallShield to get the job done.
By using InstallShield (IS) you have two options:
Create a deployment project that will be 100% compatible with Windows Installer (the technology that builds .msi), no more no less. By doing that you can build your IS project pretty easily with Team Build.
Create a deployment project with the IS flavor (with a installation bootstrap) and you'll have to deploy the needed runtimes of IS in order to successfully build.
However I strongly encourage you to not choose the way you'll create your deployment package based on the Continous Integration constraints, if you have to install 3rd parties on your build agent, so be it, it won't be the toughest thing to do. (especially if those are VM you can clone)
I am setting up the build system for a team that produces APIs used on several platforms and architectures. There has been a lot of work already spent on setting up Ant to build all of the Java code, so I would prefer to stick with Ant if possible.
Where I am stumped is how to build the C++ software. Here are the platforms and languages I need to support:
Java - Linux - 32bit & 64bit: Ant
Java - Windows - 32bit & 64bit: Ant
C++ - Linux - 32bit & 64bit: Ant w/CppTasks (question #1)
C++ - Windows - 32bit: (question #2)
Note: C++ on Windows is MS Visual Studio C++ projects.
I think the answer to question #1 is CppTasks because that seems to be the standard way to build C++ from Ant.
For question #2, I could also use CppTasks, but the developers will be compiling in Visual Studio, so it seems beneficial to use their Visual Studio project for building, which means calling MSBuild from Ant.
Has anyone tried this before and has a good solution for building Java & C++ on both Linux and Windows?
Do you use a Continuous Build System like Jenkins?
With Jenkins, your builds can be automatically triggered by check in/commit, time of day, and/or on command. The great thing about Jenkins is that you can have it automatically build all of the various versions of your software.
For example, you'll probably need to run make on Linux C++ but use msbuild on Windows systems, and you'll need to trigger a build on a Linux machine and one for a Windows machine. Jenkins can be setup to do this automatically. When a commit happens, all your various builds on all of your systems can be triggered at once. Then, you can store the builds you need on Jenkins and have your users actually pull the type they need off the project they need.
There are so many ways this could be setup, but the easiest is to simply create four separate jobs (One for Java 32bit, Java 64bit, C++ Linux, and C++ Microsoft). You don't necessarily need a separate Microsoft Java build (at least in theory), but there's nothing stopping you.
You can have a single Jenkins server run "slave" jobs on other build systems, so you could have Jenkins live on the 64Bit Linux system, but use a 32bit Linux system as a slave to do the 32bit build, and call a Windows slave to do the Visual Basic build. That way, all of your jobs are located in a central place, but you can use the environments you want.
If you've never used a Continuous Build system, download Jenkins and play around with it. It's free and open source, and very, very easy to use. You can run it on any machine that has a JDK or JRE 1.6. If you download the Windows version, it even comes with the JRE already built in.
Your best bet is to use a continuous build system and allow it to handle the mess. By the way, there's also Bamboo, CruiseControl, and Hudson (which was split from Jenkins a few months ago)
TeamCity should fit the bill very well. It supports Ant and MSBuild natively and has a pretty good cross plartform story (written in Java but excellent integration with e.g. Win).
Dont see any benefit in wrapping you Win MSBuild-based builds in yet another build system.
The list for this looks a little bit different (in my opinion)
Java -Maven for all platforms
C++ - Maybe Maven as well (Check http://duns.github.com/maven-nar-plugin/).
We recently moved to Team Foundation Server 2008 from Source Safe. We are setting up some automated builds and have run into some issues with the publish of click once apps that seem to require additional installs on the build server.
I've seen posts that indicate that the Visual Studio IDE needs to be installed. I've also seen posts that say that installing the .Net Framework SDK would fix the issue. We don't want to install more than we need on the build server, but we also don't want to have to make multiple requests to our server team to install different pieces at different times. So, I'd like to know what most teams end up installing.
If it's important, we don't have a dedicated build server at this point. We are a small team (6 devs, all local). Builds are happening on our main TFS box, the SQL Server piece is the only part that is on a separate server.
If you are just compiling applications in with Team Foundation Build, then the .NET Framework will do - however as soon as you start wanting to do anything more advanced (such as running unit tests and having their results published into TFS) then you will need to bite the bullet and install a Visual Studio Team Edition on your build server. I usually just install a copy of Team Suite on the build server so that people who are licensed to use the various features can have those features run as part of any automated build.
Having to have it installed on your server is not ideal, but gives you the best experience at the present time.
Regarding using your TFS server as your build server, this is not recommended for larger teams because builds tend to be pretty CPU and IO intensive beasts - however for a small team such as yours and assuming that you don't have too many build definitions that could run at once you should be able to get away with it.
According to this, Visual Studio shouldn't be required--just the .NET Framework. One other note to consider from the link is that they recommend against builds happening on the TFS box.
Yes, I installed VS on the build server. I followed their manual for setting up TFS.