I have just started a new job and their code management is an undisciplined mess. Normally that's ok and I can cope with it but in this place it's ridiculously bad.
They use TFS...there is nothing I can do about this. There is no chance of introducing git but I have been reading about git-flow and I wondered if there is a set of tools the can manage branching and hotfixing like git-flow with the out of the box TFS tools.
At the very least I would appreciate being directed to any documentation, practices, cheat-sheets etc that make the task of teaching a team of programmers to use source control properly easier. This is more than just a software problem its a hearts and mind thing too.
You should start with the ALM rangers branching guidance this will give you a starting point for defining a sane branching strategy. As for tooling, the out of the box tools aren't that bad in TFS 2012, what are the specific problems?
Related
From my perspective, we're constructing our own 'flavour' of NAnt/Ivy/CruiseControl.Net in-house and can't help but get the feeling that other dev shops are doing exactly the same work, but then everybody is finding out the same problems and pitfalls with it.
I'm not complaining about NAnt, Ivy or CruiseControl at all, as they've been brilliant in helping our team of developers become more sure of the quality of their code, but it just seems strange that these tools are very popular, yet we're all re-inventing the CI-wheel.
Is there a pre-made solution for building .Net applications, using the tools mentioned above?
Continuous integration tools are usually focussed purely on the monitoring / running aspect of continuous integration - i.e. they monitor the repository and kick of a build when something is checked in. The trick to making this successful is to create automated builds that are easy to maintain and extend - rake is probably a better choice for this than nant due to the expressiveness of ruby, but you can achieve the same with nant if you take care.
TeamCity is probably the simplest and fastest CI server to set up and get running and definitely beats the pants of CC.
Hudson was another product that came up a lot when I was researching which CI server to use, but as I chose TeamCity and have never used Hudson I can't really compare the 2.
Have a look at Hudson
There's CI Factory, but it's always been a single developer pulling pieces together into a whole, and it looks like it has taken a side jog out of .NET-land into Java-land.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I work on a team with three other developers and one business analyst writing internal business applications. We're primarily building apps in ASP.Net, and do so in a very 2003-ish way. It's like going back in a time machine. Although two of the other developers are amenable to learning new things, one of the developers is not. He's the type who thinks he's the strongest developer in town, and that if he doesn't understand a new tool within 5 minutes then he just needs to build his own. He also doesn't recognize agile development, TDD, or basically any non-Microsoft-blessed tool or method. He even considers source control from anything other than SourceSafe to be dangerous. To his credit, he's a brilliant programmer, just not someone interested in software development.
So the only way I can get consensus is if a tool is really easy to use. Once we hit a single snag, he'll lose faith in a "I told you so" sort of way.
So what set of tools should I use to get us into a modern source control system, TDD, and CI? The obvious choice in my situation seems like it would be Microsoft's TFS, but I doubt I could get our thrifty and apathetic management team to spend the extra money (they already think MSDN Pro is too much).
Basically, what is the easiest set of tools to get going with Source Control, TDD, and CI for a .Net 2008/2010 environment?
I wouldn't recommend dumping all these tools and methodologies on your team at once, take baby steps. Introduce one at a time. Some will come naturally.
There are many good choices, but I can personally recommend these:
Source control: Subversion with TortoiseSVN and Ankh or VisualSVN
Continuous Integration: CruiseControl.NET
TDD tools: NUnit + your mocking framework of choice (I use NMock, though it's a bit old-school). I agree with commenter Eric that TestDriven.NET is a must-have, particularly if you want to make this easy!
These are easy to get started with because they're all good products, reasonably to very well-documented, and widely-used (so it's easy to get help).
It's always going to be difficult to introduce new tools if you can't build a consensus. Focus on building the consensus, rather than on the tools.
SVN is very good (with Ankh and TSVN), but it can be a bit surprising to people used to SourceSafe.
TDD is a technique, rather than a toolset, so you need books, blogs, etc. For tools to support it, NUnit or MSTest. Continuous Integration is a must-have. CruiseControl.Net is pretty good (though a bit difficult to configure initially). Consider also TeamCity.
Do you have a bug-tracking system?
Oh, and if your management team is that apathetic, consider quitting.
Update: you've said that they're not so much "apathetic" as "hands-off". Question: are they really hands-off, and will they let you move things along? Or are they "status quo" -- "it ain't broke, so don't fix it, and don't rock the boat"?
I think you can make a really really good case that within the last two years Agile has become completely and totally embraced by Microsoft. I know for a fact that the Codeplex, MEF, and ASP.NET MVC teams are quite steeped in it. I also think that visual studio and parts of the windows 7 team are Agile. Also consider that Visual Studio 2010 includes out-of-the-box refactorings that don't really make much sense outside the context of TDD and that Agile is the default project management template for TFS and a picture of a corporate culture that is quite different from the one of years past starts to emerge.
As for specific tools. TFS is OK for source control but I find it very heavyweight and finicky. Others have mentioned Subversion but if you're worried about MS blessings you might have better luck jumping straight to Mercurial. Its a more advanced SCM but it is now supported natively by Codeplex and has excellent windows integration. I've never used it but I am in deep tool-love with it's cousin git.
Test driven development: Start with MSTest, its not as slick as anyone would like but its not the worst thing in the world. I would also recommend MbUnit which has all of NUnit's features along with some good support for the integration tests that you will probably be writing by accident as you are starting out with testing. Oh, and if you have customization freak I would urge him to look at XUnit.Net.
Mocking: The choice is basically Rhino Mocks or MoQ. Here's a quick intro I wrote for Rhino Mocks that goes over all the basics. That being said, the trade off seems to be more documentation for RM versus a very mildly less error prone syntax for MoQ.
Test Runners: If you start out with MSTest you'll notice that you can get a significant speed boost in your test runs by using TestDriven.Net, resharper or coderush rather than the built in test runner. That being said, don't underestimate the standalone test-runners. They can be quite good every once in a while. I heavily recommend Gallio Icarus runner which comes with MbUnit.
I want to echo what George Mauer has said and suggest starting with MSTest for your unit testing. It's right there in the box to begin with Visual Studio, this will help in your cause as it's "MS blessed".
I would start with unit testing and take it from there, after a few months of "look how easier our life is now we have these tests automated" I'd take it up a notch. Consider adding something like Selenium or WatiN to the mix. Once you're rolling with that, get your CI server up. "Wouldn't it be great if we didn't have to start off all these tests manually?..."
I guess a decent SCM might be a sticking point. SourceSafe is better than nothing. Perhaps start using Mercurial or Git yourself? Show those open to the change the benefits, eventually your stubborn dev will come around when others around him are wanting to switch. Hopefully, he'll find it harder to shout if he's in the minority.
Check out http://www.viget.com/extend/effectively-using-git-with-subversion/ for ideas with mixing up different SCMs.
I also want to +1 mxmissile for saying to take things slowly. I think you'll find it very difficult to introduce all these changes in one go. It's a lot to take in at first if you're not used to it. Try to pick the part you're weakest on, or will add the most value and build up from there.
Good luck!
One tool that got me hocked on TDD is TestDriven.Net which puts the test results in the Output window. I mapped this to the F8 key and the productivity gain is superb; write a test, press F8 and see this results in the output window.
One suggestion I also have to differentiate between having Unit Tests and doing TDD. I have found that TDD can be hard to push on to a team, while; unit, integration or functional tests are an easier sell. Having a bunch of tests that saves an hour going through a manual test day after day is a big win.
After a while people will start to appreciate some new ideas if it is helping them in their daily life. Then you'll be able to introduce a build server, and move away from SourceSafe.
In .NET environments, Microsoft Visual SourceSafe is most frequently used. (but it costs). Next to that you can opt for SVN or GIT. Git is more recent (and gaining popularity). It's easier to work with than SVN once you get it.
http://git.wiki.kernel.org/index.php/GitSvnComparison might help with your decision.
95% of my time I program ASP.NET (MVC) web sites.
Should I care about MSBuild?
We use MSBuild with CruiseControl.Net to manage the builds of most of our big ASP.NET projects. For every commit of one member of the team, a build is launched. It helps us detect
quickely incompatibilities before moving a feature to "staging" or "production".
I think it is really usefull when working with a team on the same ASP.NET project or if you are working alone on a big project.
That depends on your development environment.
If you have other folks that do deployment of your systems, and they take care of the build and deployment environment, then MSBuild probably won't be necessary for your work.
On the other hand, if you need to configure the build script to understand special situations that your code comes up with, then you will definitely need to understand MSBuild scripts.
Even for a one-man shop, it's a useful tool to know, especially if you are configuring a continuous integration server like Hudson.
No. Until you have to.
Its not absolutely necessary to know MS Build, but it is useful to know.
It might not be needed for all kind of projects, but it is extremely useful when you are working on a huge code base with automated custom build solution/ nightly build/developer builds so on and so forth.
It's unlikely, unless you choose to use it, or you start to make use of Team Foundation Server's Team Build.
Your development processes need to get to a certain complexity before automated builds really deliver their true value and/or if you find need for automatic deployment (including database changes if applicable).
The coming Visual Studio 2010 is going to make it far easier to use, but for now it retains a fairly steep learning curve which you can avoid by using alternatives, or commercial products (e.g. Visual Build Pro, Final Builder etc).
The nice thing is that it is part of the .Net framework, so it's already available as long as you have the framework installed (which it probably is).
So, in short, not really. It's something very useful and powerful though, setting up deployments using MSBuild can be very, very useful.
What should a developer know about MsBuild?
Every developer should know it exists and it's basic capabilities. If know it exists you won't duplicate its features and will know what it can do for you, when you need it.
Minimum:
As an exercise, build your project through the command line: msbuild myproj.sln
Know the role of continuous integration
A little more than minimum:
Hack your csproj (or vbproj) with a message task, so it outputs something during clean.
All done. When you need to know more, you'll figure it out.
I work in Visual Studio working on sites mostly myself and occasionally I start on new features for a site and bam a bug pops up on the live site and now I am in the middle of changes and can't post a fix to the bug until everything I started to change is complete.
So I am looking for a nice an simple way to work with this type of situation - any suggestions?
Are you asking for a recommendation of a source control system? SourceGear Vault is free for single users.
I am big fan of subversion. There also plugins for VS to work with subversion repository.
http://subversion.tigris.org/
http://ankhsvn.open.collab.net/
I am in a similar situation and I use Perforce. It is free for up to two users and integrates well with Visual Studio.
Subversion is well supported and has tools for most any environment. It's also mostly straightforward to use, so you should be able to get up and running quickly.
If you need to work on a lot of separate features and bugs at the same time, you might try Mercurial instead. The tooling support is a lot less mature but I find the distributed design to do a better job of merging and facilitating work on separate issues concurrently.
But really, if you aren't using anything currently and aren't sure what your needs are, just choose one that has support in the IDE/tools you use. It will probably be Subversion.
My company (a large organization) is developing a "road-map" for evolving their rather old, tangled confederation of systems to an SOA model. A few people are pushing hard for using Websphere Integration Developer and Websphere Process Server as the defacto platform for developing future applications...because they feel IBM is a stable vendor, the tools are made for the enterprise, they drank the "business agility" BPEL kool-aid, etc.
Does anyone have positive or negative thoughts on this platform? Do the GUI tools help eliminate monotonous/redundant coding...or just obscure things and make things harder to maintain? Basically, do the benefits justify the complexity?
My experience with the IBM Java tool set is pure pain. Days to install lots of different versions of different components all incompatible with each other, discover a bug in component A get told to update to see if it fixes, updating component A breaks component B and C, get told to update these etc.
I find Eclipse with out the IBM extensions far more stable and quicker and provides more features (as its stable versions are a couple releases ahead of WID/RAD).
I would advise against going the IBM way for development tools. As for process server I have less experience but the people in my team using it seemed to enjoy it as much as I enjoyed WID. not a lot.
So far I havent been impressed by any tools with the "SOA" and/or "BPM" labels on them. My "roadmap" would be very very iterative to see some results with the archetecture as fast as possible while trying to grab some of the easy fruits. That way you gain your feel for what works for you and your people.
I would never let any vendor push me anywhere in the "scuplturing" of the architecture.
I agree with other users complaining about WID. The only reason we are using WID is that a decision was made a while back to use IBM products across the board by our sales department.
That's right, our sales department made the decision to use IBM products.
Development has been painful and frustrating. We have lots of stability problems with Process Server, sometimes it doesn't want to start or shutdown properly. Yeah you can easily draw processes in the IDE, but most any toolset provides that functionality these days. It is nothing special or unique to WID or IBM. IBM is a few iterations behind mainstream.
There are plenty of open source implementations out there that offer great support. Checkout JBoss or RedHat, they are pretty good. If that doesn't float your boat, you can always use Apache tools.
Walter
Developers don't choose WID, WMB, or WPS. Managers do, because IBM is a "stable vendor".
Look at JBoss, or K.I.S.S.
WID/WPS is actually pretty simple. The original intention was for analysts and business people to "compose" services (DO NOT LET THEM DO THIS!) so the UI is simple and easy.
Most of the work will be in defineing and implementing the back end services which depending on the platform will mostly involve wrapping existing code in SOA service.
The most important thing to bear in mind is that SOAP is technoligy and SOA is an architecture and a state of mind.
There is a zen to a succesful SOA implementation. Its all about "business services", if you have a service that you cannot describe to a business user in less than six words you have done it wrong! Ideally the service name alone should be enough to describe the functionality of the service.
If you end up with a service called "MyApp.GetContactData" described as "get name, addresses tel fax etc." then you are there. If You have a service called MyAppGetFaxNoFromOldSys" described as "Retrieve current-fax-nmbr from telephony table in legacy system" you are doomed!
Incidently most of the Websphere tooling for WS* is pretty nice. But I would recommend the very wonderful SAOPUI tool from http://www.eviware.com which is very good for compsing/reading WSDL based messages and also function as a useful test client or server.
Do the GUI tools help eliminate monotonous/redundant coding...or just obscure things and make things harder to maintain? Basically, do the benefits justify the complexity?
As a Developer, I find the tools at varying levels of being bug free. 6.0.1 was a pain, 6.2 is so much better. But once you develop with the tool, there is minimal effort to maintain it. I develop in hours what java developers take days to do. It is also easy to maintain as changes can be made very quickly. I cannot answer your question from the perspective of an architect or a Manager but i would agree with comments of some others here.