1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...

Posts tagged ‘TeamCity’

Dealing with Version Branches

At Delver, like many other places, we use version branches to maintain releases. We have one trunk where everything gets integrated, and when we want to stabalize a release version, we create a version branch and do a ‘code freeze’ on this branch. On the version branch, only bug fixes are committed, and no new features are developed.

This process helps us stabilize versions within a matter of days and proceed quickly from trunk to QA to Production.

A problem we experienced with this process was it was hard to make sure all bugfixes were properly merged to trunk. The commonplace practice is to merge all changes from the version branch to trunk at the end of the release cycle (when the version is “frozen”).

There are at least two problems with this approach:

  • First, it is usually one person who is left the ugly task of doing the merge of all these bugfixes that weren’t previously merged, usually in files he didn’t touch and knows nothing about.
  • Second, if there are bugfixes on the version branch after the version is frozen, what is to guarantee they will reach trunk? The sad answer  is “nothing” – we had several regression bugs because people forgot to merge their bugfixes).

Here is our NewAndImprovedProcess™ (as implemented by our very own Sergey Goncharov):

We setup a TeamCity build that monitors all version branches. It runs nightly, and examines the mergeinfo SVN property on all modified files. If it detects files that were committed to the version branch but weren’t merged to trunk, it fails and send an email to the responsible developer. A little convenience feature we sprinkled in was that if you have a change set that you really don’t want to merge to trunk, you can write in the commit note “[NO MERGE]” and the build will ignore this commit (you can also do a ‘recorded merge’, which is the proper SVN way of doing it, although  adding the commit note is faster in a quick-and-dirty way).

Requiring a minimum CPU benchmark in TeamCity

I wrote before on how to setup TeamCity to require an environment variable on agents.
It appears you can also specify the minimum CPU benchmark for an agent. The CPU benchmark is the number that appears in the Agents tab, and it represents “how powerful the CPU is”.

You can add a requirement for a system property “system.teamcity.agent.cpuBenchmark” to be high enough, in order to avoid builds running on weaker computers.

Watch out for old Subversion clients

I had an old SVN command line client, but was not using it directly.
New (1.6.3) clients should not be mixed with older clients, because the way they handle the merge-info property.

All my other clients (Visual Studio, IntelliJ, Tortoise) were up to date, but it appears that TeamCity’s remote run used the old command-line client.

Resolution: Install newest version of SlikSVN, make sure it’s in the path.

Keep fighting the voodoo

Good developers dislike voodoo, but sometimes all the good will can’t stop a dark spawn of evil. For example, one of our build machines always bluescreens when running a certain system test. Why? Probably some hardware/driver failure, we’ll look into that.

In the meantime, let’s just ensure the build agent doesn’t get these nasty builds, shall we?

  1. Build Configuration –> Agent Requirementse –> Add requirements for environment variable –> SHITTY_AGENT (condition = “does not exist”)
  2. Go to the shitty agent and add a system variable named SHITTY_AGENT
  3. Restart the build service:
    1. net stop “TeamCity Build Agent Service”
    2. net start “TeamCity Build Agent Service”

MSBuild FxCopSolution Task

Objective – Automatically run FxCop on our solution

Possible solution – existing FxCop Community Task

Problems with solution:

  1. Only compatible with FxCop 1.32 (hard coded folder path!!!)
  2. Accepts only DLLs as input, not a solution (our solution doesn’t have a single output directory, so the DLLs are scattered)

Solution – writing a custom task called FxCopSolution and tweaking the FxCop task.

For now, I couldn’t get a hold of the lead developer, this is not checked in to the main repository in Tigris. The source code and binaries should be in this zip file.

This zip contains:

  1. Source – The source for the FxCopSolution task
    1. Unfortunately the unit tests are not very useful, beacuse it’s currently impossible to actually run the task from inside the tes.
    2. I included some 3rd party libraries not included in the original MSBuild release, that were needed to compile it (before my changes).
    3. I had to comment out the Source Safe tasks – they required a lib I didn’t find.
  2. Bin – Everything needed to deploy the task
    1. Sample.MSBuild.proj – a sample MSBuild project that uses the task
    2. Build/MSBuildCommunityTasks – a folder containing the binaries
    3. Build/fxcop-summary.xsl – an XSL I found somewhere that translates the output from FxCop to a displayable HTML. It’s not that pretty (suggestions are welcome), but it does the job.

We integrated the task with TeamCity (simply adding another MSBuild build and specifying as artifact Build/Output.html), and now our build displays a huge number of FxCop errors we’ll fix in the following weeks.

If you have any errors using the zip (there are bound to be a few silly ones) and/or questions, feel free to contact me at ron.gross@gmail.com.

11 Tips for Beginner C# Developers

Today I sat with a friend (let’s call him Joe), who just switched from a job in QA to programming, and passed on to him some of the little tips and tricks I learned over the years. I’m sharing it here because I thought it could be useful to other people that are new to programming. The focus of this post is C#, but analogous tools and methods exist for other languages of course.

Refactorings (A.K.A Resharper)

(This is just a short introduction. I recommend the book Refactoring: Improving the Design of Existing Code as further reading)

As I’ve written here before, I just love Resharper. It is the best refactoring tool for C# I know of (even though it’s a bit heavy sometimes – make sure to get enough RAM and a strong CPU). Joe asked me about a C# feature called partial classes. He said his class was just too big (4000 lines) and becoming unmanageable, and he wanted some way to break it to smaller pieces. He also said that at his workplace, they lock the file whenever anyone edits it, because it’s very hard to avoid merge conflicts on such huge files.

I was happy he wanted to simplify and clarify his code by splitting the file, but the way he thought of doing this was the wrong way.

Tip I: Single Responsibility and Information Hiding

You should strive to minimize the information you require at place in your program. Joe had dozens of unit tests, which all derived from a single base class that contain methods required for all the tests. In a second look, we saw that some of the methods were in fact only needed by some subset of the tests, that were actually logically close.

To solve Joe’s problem, we created an intermediate class, which inherited from the common test base class, and changed these classes to inherit from the intermediate class. We then used Resharper’s Push Down Member refactoring, which removed the methods from the test base class into the intermediate class. No functionality was changed, but we removed code from the huge 4000 lines class! By continuing this process, we can break down the huge class into separate related classes with Single Responsibilities, and no class would have access to uneeded information (like methods it doesn’t care about).

Tip II – Duplicate Code Elimination

I believe the world of software would be a better place if people were not allowed to Copy-Paste code more than a few times a day. Many coders abuse this convenient shortcut and thus create unmaintainable code. The effective counter-measure to the Copy-Paste plague is elimination of duplicate code.

I saw in Joe’s long file code that looked similar to this:

alice = Configuration.Instance.GetUsers(“alice”);
bob = Configuration.Instance.GetUsers(“bob”);
charlie = Configuration.Instance.GetUsers(“charlie”);
diedre = Configuration.Instance.GetUsers(“diedre”);

Even though this is a rather simple example of code duplication, I strongly believe even such minor infractions should be dealt with. Every line of the above code snippet knows how to obtain users from the configuration. This knowledge has to be read and maintained by developers. Instead, why not get all the “user getting” code into one place and let us simply write what we want to do, instead of how?

To solve this, I use one of these two techniques:

Extract Method, Tiger Style

  1. Choose a single instance of duplication, and locate any parameters or code that is not the same among all the instances of the duplicated code. In our examples, the username (and the assignment variable) are the only two different things between the four lines of code.
  2. For every such parameter, use Introduce Variable. The end result of this phase should look something like this:
    string username = “alice”;
    alice = Configuration.Instance.GetUsers(username);
    bob = Configuration.Instance.GetUsers(“bob”);
    charlie = Configuration.Instance.GetUsers(“charlie”);
    diedre = Configuration.Instance.GetUsers(“diedre”);

  3. Now, use Extract Method on this code (the first line in our example). This creates a new method that I would call GetUsers, that simply gets a string argument username and reads it from the configuration.
  4. Perform Inline Variable on the variable you created in step 1.
  5. Now, change all the other instances to use this new method and delete the redundant code.

The end result looks like this:

alice = GetUsers(“alice”);
bob = GetUsers(“bob”);
charlie = GetUsers(“charlie”);
diedre = GetUsers(“diedre”);

Another way to achieve the same refactoring is Crane Style (I’m just enjoying using kung-fu styles here because I saw Kung-Fu Panda not too long ago :). You can use immediately without creating the temporary user, but then you get a method that specifically returns the username for “alice”, which is not what you wanted. Nevertheless, this method can be refactoring by applying Extract Parameter on “alice”, netting us the same result.

Of course these two examples do not begin to cover the myriad of ways you can and should refactor the code. What’s important is that you always keep an eye out on how you can make your code more concise, which in turns leads to readability and maintainability.

Tip III: Code Cleanup

Resharper sprinkles colors to the right of your currently open file. Every such colored line is either a compilation error (for red lines), or a cleanup suggestion. Go over such suggestions and hear what Resharper has to say (in the example below it seems nobody is using the var xasdf, so a quick alt-Enter while standing on it will remove it).

Another thing which you should do is define and run FXCop
rules to perform a deeper analysis on your entire project/solution and spot potential problems.

Source Control

Tip IV – Use Source Control

I almost left this out as this goes without saying, but properly using source control can probably save you more time and money than all the other tips (or cost you if you don’t use it). The best source control tool I know of for Visual Studio is of course Team Foundation Server, as it has the best integration with the IDE. Other tools are possible, but you have to have a good reason for choosing something other than TFS (One good reason might be cross-platform development and the desire to keep all your code base in a single repository).

Automatic Unit Tests

At Delver, we use NUnit to write unit tests. In past projects I’ve used Visual Studio’s built in test tool, but I found NUn
it to be slightly better, mainly due to the integration with Resharper. Resharper adds a small green button next to every test, and allows you to run your test directly from there instead of looking for the “Test View” window. Tomer told me just last week that he uses a keyboard shortcut for running tests, but for me, this is one shortcut I don’t think I’ll bother learning (the brain can only hole so much).
Another benefit of NUnit is that it runs the test suite in place in your current source folder, instead of copying everything aside to a separate folder like Visual Studio’s tool (this used to takes me gigs of space of old unit test sessions which were rarely if ever used).

Tip V – Write Autonomous Unit Tests

Back to Joe, he has a few tests that don’t work right out of the box. Before running tests, he has to manually run a separate application used by his test suite. As his project contains hundreds of tests, I would love seeing this added as an automatic procedure in his TestInit() method. Automating a manual operation, besides saving time for developers, enables you to:

Tip VI – Use Continuous Integration

Tests that nobody runs are no good. Tests that are run once when written and then forgotten are only slightly better. By the same logic, tests that run all the time are the best. Pick and use a Build Automation System. I wrote before about our chosen solution, TeamCity, and to sum it up – we’re extremely happy about it. TeamCity runs our tests on every commit, on multiple configurations and build agents, and helps us detect bugs faster.

Know thy IDE

Visual Studio is one powerful tool (not belittling java IDEs like IntelliJ and eclipse which in many cases are better). Learn how to use it’s features to your advantage:

Tip VII – Edit And Continue

Suppose that while debugging, you found a bug. You can edit the code, save, and continue the debug session without losing the precious time you took getting to this point.

Tip VIII – Move Execution Location

See the little yellow marker that signifies the current location inside the program being debugged? This arrow can be moved! It took me quite a while to discover this (actually heard about it from Sagie), but if you take and drag this arrow, Visual Studio will rewind or “fast forward” your execution to the desired point. None of the code gets executed, you just skip to where you want to go. Excellent for going back after executing a critical method, and rerunning it as many times as you wish.

Tip IX- Use Conditional Breakpoints

Don’t waste your time waiting for some specific value to appear in the watch for an interesting variable – set your breakpoints to stop only when the desired conditions are met (right-click on the red breakpoint circle and choose “Condition”).

Tip X – Attach to Process

Got a bug that only happens on production machines? You can attach your IDE to any running process (preferably one that is compiled in debug mode), and debug away. You can also programmatically cause a debugger to attach using System.Diagnostics.Debugger.Lau

Tip XI – Use The Immediate Window

The Immediate window is a great tool for executing short code snippets solely for debugging. You can place a breakpoint inside a method you wish to debug, and then call the method directly from the immediate window (saves you from doing this through Edit And Continue)

Some More on TeamCity

After having used it for a few weeks, I have this to say following my last post:

  1. Great Support! We’ve had a couple of issues with Teamcity, some because our owns unit tests "maliciously" killed all java processes as a form of cleanup, and this killed the TeamCity Build Agents, and some other problems related to which version of the JVM was to be used. The TeamCity support staff and developers were extremely helpful and responsive, and aided us to get a stable Continuous Integration system up and running.
  2. Enjoyable UI – the AJAX UI is usually very responsive, and rather feature-complete. It gives easy access to builds, projects, a sane way to manage settings and source control bindings, and a quick way to access the full log for every individual build (can be quite a few megs!) What I am missing is the one specific feature – I want the UI to clearly spell out the name of the person who broke the build (and speak it very loudly using text-to-speech, but that could be considered too esoteric to be included in the main build but rather implemented as a plugin).
  3. Impressive code duplication finder – buggy at first, it now semi-stabilized. While we haven’t had the time yet to actually work with it and remove duplications from our code base, it’s just a matter of internal priorities at Delver. The power this gives a developer that wishes to improve his code base is huge.
  4. VC integration – a bit less smooth than the other features. It’s mostly worked for me, but sometimes it didn’t. The Personal Build feature is very attractive, but I found one major problem using it: I ran a personal build that succeeded, but then it failed to automatically merge the code. I don’t know if anything can be done about this – I can GetLatest before running the build, but the content of the branch may still change, and unless the merge is automatic human will be needed to solve it. However, I think it’s a powerful tool that should work most of the time.

 

That’s it for now. All in all, great product – keep it up JetBrains.

Knuth and The City (TeamCity!)

Funny – just today I read that the great Donald Knuth, in a recent interview, dissed unit-testing:

“As to your real question, the idea of immediate compilation and “unit tests” appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be “mocked up.”

(In this interview he also talked against multi-core paradigm (which may be the only way to keep up with Moor’s law due to our CPUs getting hotter and hotter), but that’s a different story).

Why is this funny? Because just today at work I installed JetBrains’ TeamCity – a very fine unit test and automated build suite. Sadly I didn’t have time to finish configuring it today, but I already see the great benefit this will bring to all our development team. It goes beyond a simple automated build system (which is important enough, making sure no member of the team messes something up by accident, opening up new venues for brave code refactoring).

TeamCity aims to take all resource-intensive activities off the developer’s computer. Just some of its features are (I didn’t have the chance to test them, but I believe JetBrains – these are the guys that make Resharper after all):

  • Code Analysis (finding code and style errors)
  • Code Duplication – automatically find the copy-pastes I hate so much, with configurable granularity (java only, coming soon for .NET)
  • Pre-commit Build – Suppose it is now 8PM, you’re about to leave for home, and unfortunately you have a rather large piece of uncommited (checked out) code. What do you do? You do not commit the code. Why? Because there’s a good chance it will screw up the build and you don’t want to leave the common integration area messy. To the rescue comes the Pre-commit Build feature – you can commit the code, have TeamCity catch your commit before it actually happens, test it automatically on a build agent (dedicated build machine), and then only if the code compiles and all tests pass it will check in the code for you. You do not have to wait for tests anymore! This frees up developer’s time for actual development, while preserving the high benefits of unit-testing (that Knuth doesn’t see, for some reason).
  • I’m sure it has load of other features I haven’t dug up yet – among them the ability to run tests without any commit process “just for fun”, it’s ability to smoothly handle multiple Agents (each running a configurable number of builds concurrently), supporting multiple source controls, IDEs and development languages, ICQ/RSS/Jabber support, and last but not least a button “Run this test on the fastest available test machine”.

So far the systems I’ve used for unit-testing were:

  1. Manually running unit-tests a couple of times, then forgetting about them :)
  2. A patched-up system that automatically runs tests for you on checkin, with a build status indicator that Gal Golan in my development crew in the army wrote himself
  3. CruiseControl.NET – an open source project that does something similar to the above, only slightly more configurable

As you can see by the length of this post, I’m excited to try on a professional solution to this problem for once :) And for those of you that got this far, let me add that it’s free or charge – for up to 3 Build Agents and 20 developers. Huzza!