I'm trying to create a CI process for SQL Server Reporting Services.
I am fairly new to TFS but quite experienced with MSBuild. In the past I've used a combination of MSBuild with Team City so the whole build process is more or less custom.
Here lies the start of my problems, as the solution I am deploying only contains Report Server projects (rds), no compilation is required. I thought that I would override the the first default task that TFS runs (EndToEndIteration) to override the default TFS build sequence and inject my own.
The first snag that I have come across is that the build always fails, how can I set the status of the build to success? Currently the EndToEndIteration task is very light and only has a message.
Is this the best method to create a custom build process in TFS where compilation is not required? Or should I use the default sequence and override one of the hook tasks mentioned in
http://msdn.microsoft.com/en-us/library/aa337604%28VS.80%29.aspx
(ie: AfterCompile)
The core steps that I'd like to achieve are:
Bundle the RDL and datasource files
Connect to the host server to
register/deploy the reports
Re-apply any subscriptions that
previously existed
Run tests to verify the deployment
succeeded and is returning results
as expected
I have found another article on Report services deployment:
Reporting Services Deployment
But it doesn't mention the best practice for customizing the standard build process.
Any help would be appreciated.
For anyone interested I've just stumbled apon an answer to the first question I asked:
The first snag that I have come across is that the build always fails, how can I set the status of the build to success?
You can find a solution to this at
Link
The options available for this property are:
Unknown
Failed
Succeeded
Don't forget to also set the TestStatus else the build will only partially succeed
Still looking for the best practice for creating a custom build sequence.
Related
We've recently downloaded and are hosting an on-premises Visual Studio Team Services build agent for our source code and have noticed that it's doing an extra step in the build process compared to our hosted agent. This extra step is the 'Post Job Cleanup' as seen below:
When setting up this agent locally there was no options for setting this, and looking at our build steps this extra job isn't listed there:
I've checked online guides but there's been no hint as to where this extra step is coming from. Does anyone know where the option is to include/exclude this for builds is?
Setting process.clean to false in the variables of the release pipeline stops the "finalize job" step from killing all processes.
Setting variables in the release pipeline
https://developercommunity.visualstudio.com/solutions/498153/view.html
Gradle Daemon being killed in "Finalize Job" step
They are the built-in steps and there isn’t the way to remove them (Get source, Post Job Cleanup) in VSTS, you don’t need to worry it, it won’t affect your project or build.
This is an extension of an earlier issue I had, which I posted about here: VB.Net Method appears to be called multiple times when it actually isn't, and returns inconsistent results
At that time I had thought the issue was fully resolved, but I've since learned that there were multiple issues. I have worked out all the kinks with the code and logic, and now I've narrowed down the last remaining issue.
Builds will run perfectly fine until one legitimately fails. After that point, all the builds on that specific agent will fail, even if there were no actual errors with the subsequent builds. When they fail, I see the exact same symptoms as I did in the other thread, which I will summarize here:
A method that is only called once appears to be called multiple times as evidenced by the build messages
The build messages will show there is 1 error, but there are no errors in the logs generated by that method (The line to write the error to the log comes immediately after the line where the error is added to the result log, in the same if statement)
Restarting the build service on the build server "fixes" the problem until the next time a build legitimately fails, at which point the cycle starts again
Build server setup:
Windows Server 2008 R2
VS 2010 Premium
Build uses a custom library
There are 4 build agents, one for each environment (Dev, QA, UAT, Prod)
The build and deploy custom library is written in VB using .Net Framework 4.5, and it calls on another library that is written using .Net Framework 4.5 as well.
The build template doesn't use msbuild. It's strictly WF that's been stripped down to the bare minimum and only calls commandline programs (Like robocopy) or custom .net classes.
I have verified that if a build fails for one agent (such as Dev), then all builds using that agent will fail. When it happens, ONLY builds that run on that particular agent will fail, other agents run just fine. I have not had a chance to test yet if just restarting the agent will "fix" it, or if I have to restart the entire service.
I have tried clearing the Visual Studio cache for the user account running the builds, but that didn't help at all. I also have a GUI interface that I designed that does all the same things as the build, and uses all the same code, and I am not able to get it to repeat the behavior.
I've enabled logs on the build controller per these steps: How to enable build agent or build controller’s logs? however they were no help when this problem occurred (There were no errors logged, nothing was different in the logs for builds that were fine vs. ones that bugged out)
I'm not sure what my next troubleshooting steps should be, I know the problem isn't with my code, and I'm having no luck searching the internet via Google, MSDN, StackOverflow, or picking the brains of my peers at other organizations.
I'm wondering if this could be a bug due to running code that requires .Net Framework 4.5 in TFS 2010 build, since it only officially supports up to 4.0.
My advice would be to change the build logger to diagnostic and look at the output, there must be some rubbish being added to the environment.
You can do this with a switch like
/l:FileLogger,Microsoft.Build.Engine;logfile=c:\build.log;Verbosity=Diagnostic
you might want to take a look here
Has anyone solved the problem of automatically building publisher policy assemblies as part of an automated build? I've trawled the web and there are plenty of people asking about this but no solutions.
Constructing policy assemblies is hugely error prone when done manually and in any case needs to be part of the continuous integration build that we run in TeamCity.
I'm hoping specifically for a solution that uses MSBuild and can run on TeamCity, but I can interpolate from other solutions if necessary. Surely, someone MUST have done this?
We have our source code stored in Kiln/Mercurial repositories; we use MSBuild to build our product and we have Unit Tests that utilize MSTest (Visual Studio Unit Tests).
What solutions exist to implement a continuous integration machine (i.e. Build machine).
The requirements for this are:
A build should be kicked of when necessary (i.e. code has changed in the Repositories we care about)
Before the actual build, the latest version of the source code must be acquired from the repository we are building from
The build must build the entire product
The build must build all Unit Tests
The build must execute all unit tests
A summary of success/failure must be sent out after the build has finished; this must include information about the build itself but also about which Unit Tests failed and which ones succeeded.
The summary must contain which changesets were in this build that were not yet in the previous successful (!) build
The system must be configurable so that it can build from multiple branches(/Repositories).
Ideally, this system would run on a single box (our product isn't that big) without any server components.
What solutions are currently available? What are their pros/cons? From the list above, what can be done and what cannot be done?
Thanks
TeamCity, from JetBrains, the makers of ReSharp, will do all of that. You will have to configure it for what specifically it means to "build your product", but you can configure up everything you specified with it.
The software can alert you to failed builds, even down to alerting only the person responsible for checking in code that broke the build. It even comes with handy web pages you can view to see only your own changes, which builds they've been through successfully, which ones are pending, and which ones are currently being executed.
Since it is a distributed product, you can make it grow with your organization and product. If at some point you discover that you're waiting for the build to complete too much, because a lot of builds are being queued up, you can add more build agents. The build agents are basically separate client programs you install on additional machines, that execute the actual build configurations.
It comes in two flavors, the professional version and the enterprise version. The professional version is free, can contain up to 20 build configurations, 20 users, and 3 build agents. The enterprise version has unlimited users and build configurations, and you can also use LDAP based security (think domain verified users.) There's also some other bonuses from the enterprise version. You can also buy licenses for more build agents if you need more than the initial 3.
Now, if "no server components" means you don't want it to act like a web server, you're going to be hard pressed to find something that will react to your commits.
However, if you mean that you don't want to have to install a server OS, then TeamCity can work on workstation versions of Windows as well. That isn't to say that you shouldn't consider setting up a proper server for it, but it will run on a workstation if that is what you require.
Our product BuildMaster does all of the things you listed by design and there is a free, somewhat limited edition (e.g. you can only have a limited number of issue tracking providers integrate with it, the database change script packaging tool isn't included in the free version, etc.) for 5 users or fewer.
What you've described is the basics of a CI Tool, so every CI Tool should be OK.
I use Cruise Control.NET but it is bugged with Mercurial and is not very straightforward at first glance. I am nevertheless happy with it. Other tools that come in my mind are Hudson, Team Build (from TFS) and TeamCity.
I have not tried other tools but you can see pros/cons here :
TeamCity vs CC.net
Hudson vs CC.net, Link 1 and Link 2
CC.net vs TFS
EDIT : I forgot to mention that Hudson and Cruise Control.net are Open Source project, you can easily write plugins and patches to your install.
EDIT² : Mercurial bugs seem to be fixed in the upcoming 1.6 version of ccnet (changes commited to the trunk this week).
There's always BuildBot which I like (and have contributed some code to ). It's fairly easy to set-up and run on any OS, and to do simple tasks like that you say, and remarkably flexible if you need it.
What you might find missing is batteries-included log-scrapers and/or report generators that other more commercial CI-servers comes with, especially for Enterprise-y frameworks.
It scales pretty well too, Mozilla and Chromium use it, amongst others.
I am trying to create a custom task for MSBuild so that it will send an email to the users that sais that a new version is up on the test server.
I go the email part done, what i would like to do is add the work items that are included in this build.
I tried the MSBuild extention (used to send the email) but the feature to get that info is not supporte don TFS 2005 wich is what i am using and cannot upgrade.
I was trying to use BuildStore.GetWorkItemsForBuild but i need a builduri which i cannot find a way to get.
The setup is like this, the steps to compile, build and deploy are called from a batch file as diffrent options. At the end of the deploy option, the email is sent.
Anyone can help me on this?
It's feasible but it seems your'e trying to stretch MSBuild functionality for tasks that related to build management.
Consider a solution like TeamCity that wraps for you all the build processes and manage notifications (i.e. when build has succeed or failed). It has out-of-the-box support for MSBuild.