Tools and recommendations

[kadualon]

I know that we have alt.net tools for presenting tools but still...

I would like to change some of the tools my company uses.
What tools are you guys using in your work place for source control,
unit testing, continues integration and builds?
If you could select the tools at your work place, would keep the ones
you currently use or select different ones?
Do you use any special tools for scrum (e.g. versionone, agilezen)?

thanks,
Alon

[Avishay Lavie]

Here we use:

* SVN for source control - but I would rather (try to) use a DVCS like Git or Mercurial.
* NUnit for unit tests - no real issue here, maybe MbUnit is a little friendlier but all in all it's how you write your test, not the test framework that matters.
* TeamCity - very happy with this product, don't know many alternatives but it's definitely doing wonders here.
* A home-rolled agile planning/tracking tool that is expected to go open source eventually (looking for beta testers, actually), which is pretty good but I haven't tried alternatives and have a hunch they might be as good or better.
* A skilled, dedicated configuration manager dude who automates everything that needs automating. Amazing value in this.

Avish

--
You received this message because you are subscribed to the Google Groups "altnetisrael" group.
To post to this group, send email to altnet...@googlegroups.com.
To unsubscribe from this group, send email to altnetisrael...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/altnetisrael?hl=en.

[Igal Tabachnik]

Here at Typemock we're using the following:

• SVN (and recently Mercurial) as source control (using TortoiseSVN + VisualSVN($) and TortoiseHg + VisualHG)
• NUnit + MSTest and obviously Typemock Isolator for unit tests.
• Team City as CI/build server - an excellent solution, which is FREE for under 20 projects and up to 3 build agents (=machines).
• Visual Studio 2008/2010 with ReSharper - can't get anything done without it.
• FinalBuilder($) for automation - everything from build scripts (replaces msbuild) to scheduled tasks. Comes with hundreds built-in tasks.
• Whiteboard + postIt notes for iteration planning (would actually love to hear about any solutions that actually WORK)

Igal.

[Ohad Horesh]

Adding what Igal mentioned + TestDriven.NET

Ohad.

[Uri Goldstein]

Hi,

Where I work we take a more mainstream approach to things:

Source control - TFS 2008 and very pleased with it.
Builds - TFS 2008 and not so pleased. Setting up builds is an agony.
Running them is ok.
Bug Tracking - TFS 2008 and quite pleased. Work item lifecycle is
good. Good email alerts. Customizing things is a bit complex.
Unit Testing - MSTest + Moq for mocking. Does the trick for our
purposes. Haven't integrated tests into build process though :(
Requirements Tracking - TFS 2008 combining work items with the
document libraries (SharePoint essentially).
UI Mockups - The Product guys are trying out FlairBuilder and liking
it.

Team Foundation Power Tools are an essential companion to TFS. Highly
Recommended.
Team Foundation Sidekick is also occasionally useful.

I can also share that we use Log4Net + Log4View, Windsor Castle, EF4,
Prism on the WPF side.

Final point - I'm in the process of introducing PowerShell to my team.
I think everyone needs to know a good scripting environment to
automate deployments, testing etc. Not sure if PS the best choice but
I'm giving it a try.


Regards,
Uri

[Ori Peleg]

I'll add our list:

• git (moved from svn), very satisfied. lots of our own support scripts and hooks (for automerging between release branches, for example).
• I think hg would have been a better fit, but the svn->git transition was much smoother. The hg<->svn integration may have changed since we've done this.
• TeamCity for continuous integration, pretty satisfied. The build configurations are a little confusing, but less than the competition.
• One of our teams moved to Hudson to get more control and have as many agents as they want (they want a lot), but that required a lot of tweaking and manual configuration. They are extremely satisfied with the result, though.
• Trac for issue tracking and release planning, satisfied although the git integration could be better
• Trac + Basecamp + Google Docs for documenting (we tried Google Wave but it didn't catch on, I guess we were lucky)
• One very useful thing we do is open a Basecamp thread whenever we do something that can use logging and live updates, such as IT operations in production, and update it immediately with every step, e.g. "started deployment, db is down", "found problem syncing the disks, falling back to the backup disk", "installation done, starting sanity", etc.. This way everyone is always updated and we have useful information for post-mortems.
• msbuild with hooks for normal building, does the job
• NUnit + Moq for tests
• DB upgrade scripts with IronPython
• Automated web-ui testing with Watin (indispensable) - although if we'd have started now WebDriver/Selenium 2.0 seems even better (headless with JS + real browsers + C# bindings)
• ReSharper (of course)
• A ton of automation with Python, IronPython, and batch files, including the build and deployment scripts and stuff we do on dev boxes routinely.
• UI mockups with Balsamiq (awesome tool IMO)
• Beyond Compare for diffs and merging (love it, but the free alternatives like kdiff3 are nice too)
• XSLT generating the DB schema, NHib files, and C# domain classes (XSLT is hard, another tool may have been better here)

--
You received this message because you are subscribed to the Google Groups "altnetisrael" group.
To post to this group, send email to altnet...@googlegroups.com.
To unsubscribe from this group, send email to altnetisrael...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/altnetisrael?hl=en.

--
Check out my blog: http://orip.org

[Ayende Rahien]

Why do you think hg would be better than git here? I find git merging to be very good, but then I am comparing it to SVN.

The major problem with git is the bloody crlf issue, which always hit beginners.

[Ayende Rahien]

I would quibble with you, not mainstream, microsoft centric.

On Tue, Aug 31, 2010 at 11:14 AM, Uri Goldstein <uri.go...@gmail.com> wrote:

[Igal Tabachnik]

When we made the switch, I believe the crucial issue was the tooling - is there a VS support for Hg/Git, and how well does it work. TortoiseHg and VisualHg work great together, making the switch from SVN less painful.

I agree that mastering the command line has its benefits, but the GUI works, and works great.

[Ken Egozi]

hmm,  VisualHg is promising.

I personally find the default "GUI" that comes with git (git-gui and gitk) more than enough. However, I am having troubles introducing git at work as people just love their VCS<->VS integration. I guess I'll have to give mercurial a shot now ...

Ken Egozi.
http://www.kenegozi.com/blog
http://www.delver.com
http://www.musicglue.com
http://www.castleproject.org
http://www.idcc.co.il - הכנס הקהילתי הראשון למפתחי דוטנט - בואו בהמוניכם

[Igal Tabachnik]

@Ken

If you worked with VisualSVN, then VisualHg is a very easy adjustment. Overlay icons + operation icons are super awesome :)

[Dotan N.]

yep, i've also silently noticed that there are many hg users here. i've started re-evaluating the difference for windows dev, in the past hour since a considerable amount of time passed between my last research. On windows, it seems that git is having a problem with unicode, CRLF (which can be fixed i think) and a "tooling" issue (which personally i don't see as an issue).

disclaimer: i'm a git user :)

On Tue, Aug 31, 2010 at 4:05 PM, Ken Egozi <ego...@gmail.com> wrote:

[Ayende Rahien]

TortoiseGit is a much better tool, I agree.

I don't use VS integration, so I don't care for that

On Tue, Aug 31, 2010 at 4:05 PM, Ken Egozi <ego...@gmail.com> wrote:

[Ken Egozi]

I just dont trust these (VS integraion) tools.  the scope of the project is larger than that of the VS solution (docs, scripts, god-forbid-non-dotnet-code, etc.) thus the integration gives you a false feeling of "alles gut" when things are green, but actually things are not commited somewhere in the project tree outside of the SLN.  and maintaining "solution folders" with that stuff is painful at best, and slows down the already slow VS.

[Dotan N.]

totally agree!.
many times people gasp when i tell them "no, i did not install visualSVN, and i don't want to", "yes i do know we have a license for that" at work.

[Ayende Rahien]

Never run into a unicode problem.

CRLF is a big problem, not so much for a single person, but when you are working in a team, you have to make sure that everyone has the same settings.

Don't see the tooling problem, though. I think it is a legacy issue that remains as bad PR

[Igal Tabachnik]

We are using VisualSVN on a fairly large project and *rarely* had any problems using it. VS integration tools work, there's no reason they shouldn't. There might be bugs, but those get fixed.

[Lior Friedman]

Hi ken,

 

While I use SVN, the combination of TortoiseSvn (integration with window explorer) and AnkhSVN (integration with VS), does a very good job.

I don’t think I would give up on any side.

Integration into VS is good when working on source files, Tortoise covers other staff.

 

BTW I found out that since I’m not working on very big projects I tend to add all files into the solution, including docs, scripts, test data, build server configuration files,…)

 

Lior Friedman
Blog  - http://imistaken.blogspot.com

[Dotan N.]

i've never ran into it either, but its good to be aware:
http://code.google.com/p/msysgit/issues/detail?id=80

[Avi Pinto]

We also use Git, and vary happy with the git extensions UI,

(i had some troubles getting the command line to connect to gitHub, but till today never had to use it so didn't make the changes on the other dev machines)

heard about the CRLF issues so made sure all settings are the same on the machines.

i think that the obsession for VS integration comes from the need to checkout a file before working on it(TFS,VSS,SVN)

BUT in Git you just work on the file and commit(and push) when you finish.

The only problem we have with GIT is with files that can't be merged like office/media/.edmx/.dbml

now we just raise a flag(shout in the room) when starting to edit one of these(we don't have a lot of them)

as i understood there is no good solution for this, and will be happy if i'm wrong.. :)

about HG, read about it before choosing, and i think i even asked here, 

went on Git because it was more common in the community so was supposed to have better support.

 

My Portfolio http://www.avipinto.com/
Other contact options: http://www.avipinto.com/contact

[Dotan N.]

On Tue, Aug 31, 2010 at 8:45 PM, Avi Pinto <pint...@gmail.com> wrote:

We also use Git, and vary happy with the git extensions UI,

(i had some troubles getting the command line to connect to gitHub, but till today never had to use it so didn't make the changes on the other dev machines)

heard about the CRLF issues so made sure all settings are the same on the machines.

i think that the obsession for VS integration comes from the need to checkout a file before working on it(TFS,VSS,SVN)

BUT in Git you just work on the file and commit(and push) when you finish.

The only problem we have with GIT is with files that can't be merged like office/media/.edmx/.dbml

now we just raise a flag(shout in the room) when starting to edit one of these(we don't have a lot of them)

as i understood there is no good solution for this, and will be happy if i'm wrong.. :)

its not a git problem :)

 

[Avi Pinto]

of coarse it isn't :), but it is still a big pain, and i also forgot the ff .resx files that visual studio insists on reordering after each change which causes an irritating merge

[Ori Peleg]

Fair remark - git's merging is awesome (no comparison at all to svn), and I don't think hg does it better.

We ran into the CRLF issue and now make sure new installations have the right config (easy to do with a small enough group of people).

I'm much better at git than hg, and I use git a lot for real work, and it's great (no ifs or buts).

I also helped originate the move to git, because the transition plan was much better. I evaluated hg first and loved it, but the transition plan wouldn't have been half has smooth.

Still, here are - in order - the reasons I thing hg would fit better at my workplace (and had we found a good transition plan we'd probably be using hg instead of git):

(a) friendlier commands and interface, with git I feel like I need to research how to do straightforward things. Git is extremely powerful and I can do anything with it, and I'm strange so I like the arcane, but git requires more of an investment from people to use it effectively when they have other things to do. Some things are arguably easier to understand in git (rebasing, for example, vs. hg's patch queues - although that's debatable) but the whole package leans heavily to hg IMO. This is the least-loved aspect of git among the teams.

(b) in hg, commits remember the named branch they were committed to (see here). I would LOVE to have this in git, but no cigar - we're still playing with different schemes of approximating this.

With many people working at times on several branches, and with merging done between branches, then given commit XYZ it's nontrivial in git to figure out which branch it belongs to.

This is especially true in some scenarios we encountered - e.g. human error caused an older release branch to be fast-forwarded to the head of the latest devel branch - few traces are left in the repository itself of the previous state, and we had fun a few times fixing this (can take hours). Now we have a hook to prevent this

If we'd have cherry-picked between different branches instead of merged then this would be easy (and this is equivalent to svn's merging, only better), but we like git's merge and we want to use that.

(c) hg has less quirky Windows support. Points to consider:

  - msysgit gets sporadic releases and is usually months behind the stable git version, the latest hg versions just work.

    - This hit us a few times (bug has been fixed but not available in msysgit).

    - Current example: Git 1.7.2 has improved crlf handling but msysgit isn't there.

  - being able to "hg serve" your repository is incredibly cool, but "git daemon" doesn't work with msysgit

    - think continuous integration that watches your local repository and runs builds with your current code, giving up-to-date feedback

    - collaborating with someone without pushing a publicly-visible branch (I've actually wanted to do that a few times)

    - developing and testing on more than 1 machine simultaneously. There are workarounds, but "git daemon" would have been perfect.

  - automating hg, including hooks, run in a Windows environment (vs. git where it runs in mingw's MSYS environment)

What doesn't bother me much for the long run is tooling. Right now hg seems to have better tools for our scenarios (even including much better Trac support), but I think git's extreme popularity will cause better and better tools to be written. Some people were very sad to let go of their VisualSvn / Ankh plugins, but they manage with Git Extensions (mostly) and occasionally TortoiseGit. I was surprised at how few people use git from the command-line, I can't live without it.

On Tue, Aug 31, 2010 at 3:51 PM, Ayende Rahien <aye...@ayende.com> wrote:

[Ken Egozi]

hmmm - basic VS integration for git (mainly for showing file status in the solution explorer, actual actions span out git-extensions or the command line)

http://visualstudiogallery.msdn.microsoft.com/en-us/63a7e40d-4d71-4fbb-a23b-d262124b8f4c

[Uri Goldstein]

Bring it on! :)

I think Microsoft-centric is mainstream. I don't have the numbers but
I'm pretty sure. Do you really think that in the .net world the
alternatives are more popular than the mighty TFS?


Uri

On Aug 31, 3:51 pm, Ayende Rahien <aye...@ayende.com> wrote:
> I would quibble with you, not mainstream, microsoft centric.
>

> > altnetisrael...@googlegroups.com<altnetisrael%2Bunsu...@googlegroups.com>
> > .

[Ariel Raunstien]

I'm not sure popularity of a Microsoft-backed product is a true indication of quality.

(No, I'm not invoking the buzzingly popular, silly "Humus Manifesto")

Arielr

http://www.QuickUnit.com/blogs/ariel

To unsubscribe from this group, send email to altnetisrael...@googlegroups.com.

[Ori Peleg]

BTW my friend and colleague Ronnie (http://www.ronnie-midnight-oil.net/) gave me some good feedback:

I haven't used hg nearly as much as git, and we'd probably have had unexpected difficulties with hg just like we did with git.

And I love git and think it's awesome.

So while my gut feeling is that hg is more appropriate for our workplace, I don't know that for a fact.

Trying to spell out the reasons for my hunch was good exercise :)

On Wed, Sep 1, 2010 at 1:29 AM, Ori Peleg <ori...@gmail.com> wrote:

[Ori Peleg]

For some reason I felt like resurrecting this thread with the news that msysgit 1.7.2.3 is out :)

http://code.google.com/p/msysgit/downloads/list