Improved my development workflow

For some time now I slightly modified my development workflow and I have seen a great improvement in my developers life:

• it started by using Git Svn in front of our central Svn

• then I introduced NCrunch in my TDD/BDD

NCrunch is an automated parallel continuous testing tool for Visual Studio .NET. It intelligently takes responsibility for running automated tests so that you don't have to, and it gives you a huge amount of useful information about your tests (such as code coverage) inline in your IDE while you work.

 I am a fan of Test Driven Development and Behavior Driven Development, I think there are great tools in a developer toolset in quite some circumstances.

I am also a great fan of JetBrains ReSharper which I use every development day and I couldn’t work as efficiently without it. But…

So what’s the point? NCrunch propose only an automated parallel continuous run of your test. Big deal, it saves you only some keystrokes! Yeah I believed that too, but the difference was quite impacting.

I don’t need to think anymore about running the tests I just run through my TDD thinking only of my tests and code, no distraction just seeing the result of my changes directly aligned with my code.

What I really liked about NCrunch is:

• the possibility to run only a part of the tests
• the feedback given in the code window
• let me focus on the code
• the risk/progress bar
• the impact it had on my productivity

I really encourage you to try NCrunch which is free during the beta period.

Supported testing frameworks are:

• NUnit
• MS Test
• Xunit
• MbUnit
• MSpec

The Xunit and MbUnit test runners are provided with thanks to The Gallio Project.

Supported languages and .NET versions are:

• C#
• VB.NET
• F#
• .NET Framework v2.0 and above
• Visual Studio 2008
• Visual Studio 2010
• Visual Studio 11 Developer Preview

Continue Reading »

An article by Laurent Kempé No Comments

DVCS and my usage of Git Svn

Sometime ago I moved “away” from subversion has my Version Control System (VCS) because I felt not free of my way of working with it. I found a great was to improve my work experience by using Git Svn in front of our central Subversion repository.

I started my experimentation with Mercurial and Hg Svn because I was already using Mercurial for my personal projects. I hit some much the wall with Hg Svn that I decided quite quickly to go and try Git Svn. I had no experience with Git at that time and I had the feeling that it was more complex to handle than Mercurial (which I still think).

So currently I use Git Svn to work on one of our product at Innoveo Solutions. I also made a presentation to the team during our techno pizza lunch about DVCS, Git, Git Flow and Git Svn.

And here is the list of what I personally gained as a developer:

1. 2 steps commit
   1. Stage/commit, Push
2. Local history / branching
   1. No connection to central repository needed to branch/to look at history
3. Experiment / Refactoring / Spikes
   1. Commit changes on one path, if wrong rollback
4. Smarter Merging
   1. Git’s focus on content rather file location
   2. Better at resolving merge conflicts for you (e.g. renames)
   3. Branching/Merging is daily workflow not anymore an ‘exceptional case’
5. Stash changes
6. Rebase / Rewriting history
   1. Until push you can use interactive rebase

Due to my 4h daily commute (more than 2h in the train), I very much appreciate the offline capabilities of DVCS. It lets me branch, watch the history without having a connection to the central repository. So that a really convenience thing in my day to day job.

But what I even prefer is working in local branches for experiment, refactoring. With that capability I am able again to commit small steps of code change. I particularly appreciate the possibility to experiment some refactoring and to rollback wrong changes when I feel that I went the wrong way with the change. In the past this was not possible and often you would not commit to SVN because that code would be shared with the others or t would break the build. Ok, I know I could do that with Svn working in a feature branch, but we all know the pain it is with the merging back, especially when you refactor and rename files. During refactoring it is important to be able to save/commit small chunk of code change and even more important is to be able to rollback those changes. So in that case DVCS is a perfect match to that problem.

What I currently don’t like in my current way of working with Git in front of Svn is that I have local branches which I don’t sync back to the central server. I don’t like it because if I have an issue with my local machine then those changes might be lost. I will investigate in the coming weeks about possible solutions even if the best one would be a migration of the central repository to Git. But his is another story because it means a wider change in the team.

Continue Reading »

An article by Laurent Kempé 2 Comments