What is Continuous Integration?
Organizations always need a repeatable and reliable method to create a regularly available public build. In my previous organizations, I used in-house tools.—I even used a continuous integration build type. I just did not know at that time that it had a name!
What is continuous integration? Continuous integration is the process of generating a build whenever a programmer checks code into the source control server. When you use this process, it is a good idea to have a dedicated build server where you can synchronize and compile the sources, and run unit tests.
Software development life cycle processes evolved over time. Development teams realized the importance of having periodic builds. It started with a weekly build. Then it grew tighter when "nightlies" began, and tighter still with "hourlies." As the benefits of frequent builds became more obvious, organizations wanted more builds. And now we have continuous integration. But nightlies still exist. Many organizations still count on them to get a formal, reliable build.
Reference MSDN http://msdn.microsoft.com/en-us/library/ms364045(v=vs.80).aspx
Since we are using TFS to manage development life cycle in my team we have decided to make use of continuous integration in terms of Team Builds with our SharePoint projects.
The steps to have build up and running is very straight forward you just need to follow the steps mentioned in this MSDN article
How to Build SharePoint Projects with TFS Team Build if you’re using TFS 2008/TFS 2010 you will find an appendix in the same document states the configuration according to the version of TFS you have.
After configuring the team build it works fine and produced the needed assemblies and build output but I faced the following error while building the solution with /p:IsPackaging=True to create the WSP files.
“error : The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.”
It turned out the TFS agent (build machine) is using a default path to build the project and since we usually using long names for SharePoint project (feature, templates, etc..) it fails to create the package.
To change the build directory of build agent:
- In your Team Explorer 2008 window, right click on the Builds folder
- Click on Manage Build Agents
- Make sure your build agent is highlighted and click the Edit button
- Change the default working directory from $(Temp)\$(BuildDefinitionPath) to C:\b\$(BuildDefinitionId)