What best practices and methods would you enforce on a new .NET development team?
Cheers
Use only Visual Studio
If you need a database, use a server (reduces SQL issues early on)
Use Version Control
Good question. I've had to deal with this very recently with my team. Here's a couple quick points:
Come up with coding and documentation standards. A search for C# style guidelines will yield some good results. StyleCop and FxCop might be useful for enforcing your standards.
Source control. SVN is popular, but I prefer Mercurial.
Depending upon what type of projects you are working on, you might want to decide on a standard architecture. Typically, we use a UI - Application - Business Logic - Infrastructure architecture.
Put your database in version control.
Update
MSDN - Design Guidelines for Class Library Developers - All Versions
I had also assumed the OP was referencing coding standards. As for the more general practices.
Unified Development Environment (Visual Studio will probably net the best results)
Version Control (Team Foundation Server is great if you can afford it, if not SVN)
Team Collaboration (Trac if you go with SVN, TFS has some stuff as well)
You are asking for a shelf of books. I don't think you'd want to read an answer long enough to actually cover what you asked.
Microsoft's Patterns & Practices group may have some suggestions that could be useful as a resource of where are some good practices.
Continuous Integration would be another practice I'd introduce along with Technical Debt.
I'd review various Agile practices and see what the team thinks are worth adopting and what isn't. Tribal Leadership would also be something I'd examine to see what stage is the tribe and try to bring it to stage 4 if possible.
If I could put some values into the team it would be to have some pride in our work, respect one another, and think of things in terms of good for the team rather than individual gain. Granted that culture wasn't part of the question it is a natural follow-up to my mind.
You need to use version control (svn is great), but at the same time you shouldn't check everything into the sourcecontrol. skip checking in compilation output and configuration files, instead check in the config files as app.config.template files and have each dev make his own copy of the config files called app.config. check in new changes to the .template file and have all devs regularly check and update their local version if it changes.
If possible, pair up junior members with more senior members. Either way, definitely have code reviews. I'd also encourage them to have scheduled workshops or discussions so that they can get more well-rounded skills and to increase their exposure to different areas that they might not currently be aware of.
I'd also encourage them to go to user group meetings.
I would start by looking through the MSDN Developer Centers site:
http://msdn.microsoft.com/en-us/aa937802.aspx
Since you are using C# I would recommend using StyleCop to maintain consistency in code layout. Since you've stated it's a new team, I'm assuming that the code base is new as well. Starting fresh with StyleCop is far easier than trying to get rid of warnings in an existing code base.
most people would agree that having automated unit tests is a very good thing. you may want to go the tdd route and never code anything that doesn't already have a test, or you may want to write tests after the code and just focus on the key areas of concern rather than striving for 100% coverage. either way, decide what you want to achieve with testing and make sure that it is adhered to. without a strict law on getting unit tests you may well find that some if not all of your code has no automated tests and the only way that code gets tested is when someone goes into the UI and actually uses it.
In no particular order,
Agile / Scrum
A nice suite of tools -Resharper, Redgate SQL Tools, FXCop,etc.
Test Driven Development
Continuous Integration
Related
Are there any best practices for enforcing a TFS check-in policy? Are there any good guides on how to implement various types of policies as well as their pros and cons?
Things I'd particularly like to do are ensure that code compiles (note that compilation can take up to five minutes) and that obvious bits of the coding standards are followed (summary tags must exist, naming conventions are followed, etc).
TFS 2010 (and 2008 but I have not used 2008) allows a gated checkin - which forces a build prior to the build being checked in.
Activating this is a (reasonably) straightforward process, see for example these guides:
http://blogs.msdn.com/b/patcarna/archive/2009/06/29/an-introduction-to-gated-check-in.aspx
http://intovsts.net/2010/04/18/the-gated-check-in-build-in-tfs2010/
There is a step before all this which is required to make all this happen. That is a TFS build server setup. That can be a complex process depending on infrastructure etc. Here is an MSDN guide:
http://msdn.microsoft.com/en-us/library/ms181712.aspx
The pros are that the code in the repository can be reasonably stable. For a large team this can save a LOT of time.
There are a lot of cons worth considering for this benefit. Firstly, the installation and maintenance of an extra build server. This include disk space allocation, patches etc.
Secondly is the extra time required for each person to check in a file. Waiting for a build to succeed before the code is checked in (and available for others to get) can be a while.
Thirdly, when (not if) the build server is not available, a contingency plan needs to be in place to allow developers to continue their work.
There is a lot of extra process required to reap the rewards of gated checkins. However is this process is governed properly it can lead to a much smoother development cycle.
Although we do not use gated checkins, we do use a TFS build server for continuous integration to do scheduled builds. This minimises the dependency minute-to-minute on the build server while ensuring (with reasonably effectiveness) that after a build has broken, we are notified and can rectify it ASAP. This method empowers the developers to have an understanding of integrating code, and how to avoid breaking the code in the repository.
I think the premise of this question is somewhat wrong. I think a good question of this nature should be something along the lines of; my team is having a problem with code stability, conflicting change-sets, developers not running tests, poor coverage, or other metric reporting to management and we'd like to use TFS to help solve that(those) issue(s). Yes, I do realize that the OP stated that ensuring compilation is considered a goal, but that comes part and parcel with having an automated build server.
I would question any feature that adds friction to a developer's work cycle without a clearly articulated purpose. Although I've never used them, gated check-ins sound like a feature in search of a problem. If the stability of your codebase is impacting developer productivity and you can't fix it by changing the componetization of your software, dev team structure, or a better branching strategy, then I guess it's a solution. I've worked in a large shop on a global project where ClearCase was the mandated tool and I've encountered that kind of corporate induced fail, but the team I worked on didn't go there quietly or willingly.
The ideal policy is not to have one. Let developers work uninhibited and with as little friction as possible. Code reviews do much more than a set of rules enforced by a soul-less server will ever do. A team that supports testing, and is properly structured will do more for stability than a gated check-in will ever achieve. Tools that support branching and local check-ins make it easier for developers to try new things without fear of breaking the build will help mitigate the kind of technical debt that kills large projects.
You should look at chapter 8 of "Patterns & practices: Team Development with Visual Studio Team Foundation Server"
http://tfsguide.codeplex.com/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Based upon your experience
If you was given the opportunity to set up the development processes for a small development team.
Please detail
The things you would implement, tools, documents, methodology.
And how you would implement these?
I wish to implement the following:
Source Control
Bug tracking database
Formal Spec templates
Code Reviews
Coffee cup meeting (simple quick informal meetings over coffee :) )
Strict Coding convention
Please keep in mind this would be for a C# .NET focused environment.
If you plan on purchasing, or already have purchased, MSDN subscriptions, there is a major change in licensing that plays out in your favor for Team Foundation Server 2010. Server licensing is now included with MSDN, and you are provided with one CAL per subscription. More licensing details are available here.
Team Foundation Server will cover almost all of your needs in one package. I am very preferential to using as few tools to complete a job as possible, which is one of the reasons I recommend that you look into using Team Foundation Server, as well.
Some notes into your specific requirements:
Source Control - One of the primary functions of Team Foundation Server. It works well and easily integrates with AD Groups. We have security groups set up by roles per project and also for roles across projects. A company developer will be a part of the "Developer" SG and the specific SGs that he/she are involved in. This allows us to give them full access to the projects that they are working on and read access to all projects. The system has the benefit of contractors not belonging to a generalist development group - effectively bucketing them into projects.
Bug Tracking Database - Integration with source control is a definite advantage. By using one package, you have an built in relationship between work items and changesets (which you can further enforce by requiring changesets are only created in the context of work items). Work item relationships are very nice - and vary, depending on your template choice. Both Microsoft's SCRUM and Agile templates are well thought out, and have served our needs quite well, to date.
Formal Specification Templates - There are a couple of ways to approach this. You could create a specific work item type for each template and prepopulate some of the content, or if you wanted a more traditional approach, you could store document templates within the project's Document tree (which is, effectively, a document library on the Team Project Portal site).
Code Reviews - Basic functionality like Annotate (or Blame, if you prefer) are built in. Diff Tools are provided, as well - plus you can switch out the diff tools for others if you do not like what ships with it. (Personally, I use DevArt's CodeCompare .) As for the actual review process, I am a fan of TeamReview.
Strict Coding Conventions - StyleCop is a must, in my opinion. As such, I also believe that ReSharper is a must, as well. Providing conventions is one thing, but being able to visibly put them in front of the user is another. Using something like StyleCop for ReSharper will provide real-time feedback on violations of policies. Anything that you want to add that isn't a part of StyeCop can be created via custom rules, and you can actually put the ReSharper configuration for SCFR in TFS, so that it is shared by the team.
Bonus items that you get that you did not explicitly mention:
Build Management - The build tools in Team Foundation Server 2010 are completely overhauled. Now, builds are defined as workflows using Workflow Foundation, but still can be manually manipulated for more complex build scenarios Gated check-ins, often referred to as "buddy builds" help keep bad code out of the trunk.
Test Management - Testers can benefit from the streamlined testing tools in Visual Studio 2010. Automation of CodedUI tests, and the Test Lab Management tools are major strides in the evolution of Visual Studio. Having a tester be able to capture the state of the machine and automatically insert it into a work item is brilliant, and long overdue. Plus, if you end up using the Test Lab tools, actually being able to capture a snapshot of the VM at the moment of the crash is just pure gravy.
Collaboration - Even if you don't plan on using it at first, the Team Project Portals that are created for each Team Project are ripe with opportunity for collaboration. Just for document management and project wikis alone, it is worth its weight in gold.
Reporting - The reports vary with the templates that you use, but most templates have the type of reports that management care about ready to go. Adding new reports is fairly simple, due to the way that the TFS team has presented data in the cube, as well. A little SSRS knowledge will have you creating detailed custom reports in no time, at all.
Planning - You do not mention what type of methodology you are using - but the Agile template has some really nice sprint planning tools built in. You literally launch a sprint planning worksheet from Visual Studio, which opens in Excel, and any changes you make are reflected in TFS. Really works great for a group planning session.
Support - This is one of the most important factors to me. Having all of the above in a single package also means that I only need to go to one vendor for support. It is invaluable to me to be able to have one phone number to call in the rare occasion that something does go wrong, and know that I have the support incidents to cover it already paid for, thanks to my MSDN subscription.
All that being said, TFS does have a bit of a learning curve. Installation and setup are actually quite simple, assuming that you follow the documentation. The learning curve comes from the fact that there is so much to do with TFS. You might not use all of the features, so the amount of time you actually need to spend learning might vary. The native integration with Visual Studio (and Office) do provide a seamless feel, though, that should translate well to the developers using the system.
Source Control: For a .NET environment, Team Server is good stuff. If you want a free solution, I like Mercurial.
Bug Tracking: FogBugz (of course :)
Spec Templates: I think defining these should be a collaborative process between the development team and business units. Start with a very light framework and let them evolve, don't prescribe a massive document that includes information no one ever uses.
Code Reviews: Peer programming time offers this in abundance. Call out good practices to the team- don't use it as a way to humiliate developers in public.
Meetings: I'm an Agile kind of guy, so meetings (standups) should be brief, to the point, and happen every day at the same time.
Coding Conventions: Again, if you have capable developers you shouldn't have to prescribe strict conventions. Agree as a team on basic conventions and address friction points as necessary.
If your team can foot the bill for Team Foundation Server, you'll have most of what you want in one convenient package.
Source Control: Changeset-based configuration control system with full branching support.
Bug tracking database: Work items - configurable, including bug tracking and reports.
Formal Spec templates: Work items - configurable, including requirements (CMMI), scenarios (Agile), custom types, etc.
Code reviews: Work items - track your reviews just like any other TFS piece of work. A review work item ships with the CMMI process template.
Strict coding convention - I've heard of people integrating StyleCop with their check-in policy.
As for coffee cup meetings, you won't need a tool for that. :)
How do I set some group policy rule or mechanism to make sure that every developer commits their code to the source control?
I use visualsvn server with Ankhsvn client btw.
Thanks
Our basic policy is "If it's not in the source code repository it doesn't exist."
Developers only get to mark tasks as "development completed" when they check in the code.
Build your deliverable(s) only from a tagged set of source code (not some joker's workstation copy.)
NOTHING that's not in source control goes into QA or Production.
Checking in broken code is considered bad form but is not punished (outside a little ribbing from those inconvenienced.)
I'd like to use continuous integration and configure broken builds to automatically back out the broken changes but I don't expect to be able to any time soon where I'm at.
Edit: We also require artifact numbers in the comment for each checkin. This prevents gratuitous changes that are unassociated with a requirement.
These sort of policies are best enforced using peer pressure. Create an environment where it is the accepted practice to commit the code. Otherwise, it will become a drudgery and developers will find ways around it.
I think that the best way to enforce source control is to build a well formed "Software Development Culture" on your team.
Developers that well know the benefits of source control, won't hesitate about using it.
Recommended article:
Check In Early, Check In Often
A continuous integration server might help encourage people to check in their code. If everyone gets on board with checking in code for nightly builds/unit test runs, I think everyone will start to see the benefits. I agree with previous answers that forcing people to check in might not be the best approach - it's probably better to encourage that behavior using something that will benefit the group.
Email everyone and tell them to use Source Control or be fired! I'm not one to tell people to give out threats or even to have many policies, but using source control is just one those things that people should just be on board with without question.
If people are not serious about source control, then there are two possibilities. 1) The setup is too hard, and you should simplify the process to make it a one step process to check in. 2) They are bad developers and need to go. Period!
This really seems like a bad idea. Could you explain why you want to force check-ins?
Forcing check-ins will lead to broken builds and propagation of bad code. Check-ins should only be done when the code is in a running state and the user has time to review all their changes. Developers should be free to check something out, experiment with it, and throw away their changes. I do this all the time when I check out older revisions.
If what you're looking for is a forced backup, I would consider some other solution besides source control.
If you meet regularly with the team (like daily SCRUMs) and use some sort of tool such us Jira or Mantis or Rally, and you set up a trigger in your SVN system to link each commit to a task (or even better, a branch with a task, but unfortunately this is not that good with SVN) you can easily check if developers have checked in code to this task. Most of the integrations with issue/bug tracking system create an attach with the files modified in the commit, so it will be really easy to check.
This is not forcing, but it will help you enforce that all team follows the rule mentioned before: checkin early, checkin often.
Having written a small article on BDD, I got questions from people asking whether there are any cases of large-scale use of BDD (and specifically NBehave).
So my question goes to the community: do you have a project that used BDD successfully? If so, what benefits did you get, and what could have been better? Would you do BDD again? Would you recommend it to other people?
We've used somewhat of BDD at the code level in different scenarios (open source and ND projects).
Telling the view in MVC scenario, what kind of input to accept from user (DDD and Rule driven UI Validation in .NET)
result = view.GetData(
CustomerIs.Valid,
CustomerIs.From(AddressIs.Valid, AddressIs.In(Country.Russia)));
Telling the service layer, about the exception handling behavior (ActionPolicy is injected into the decorators):
var policy = ActionPolicy
.Handle<WebException>()
.Retry(3);
Using these approaches has immensely reduced code duplication, made the codebase more stable and flexible. Additionally, it made everything more simple, due to the logical encapsulation of complex details.
I was on a small team that used BDD on a website.
The way we used it was essentially TDD, but the tests are simply written as behaviors using a DSL. We did not get into large upfront design of behaviors, but we did create a large number of them, and used them exactly as you would tests.
As you might expect, it worked much as TDD, generally good. Phrasing the tests as behaviors was nice when interacting with the customers and made for a pretty decent document, but I kind of wish the behaviors were written in English and the tests programmed instead of trying to come up with some difficult intermediate language that doesn't fit either purpose perfectly.
It would still be BDD, just without this cute trick of trying to twist the language into a language delineated by a random_looking.set of_Punctuation rather_than simple.spaces, but that was only my grumpy-old-programmer attitude, everyone else was 100% happy with it.
The site is available and fully operational, so I'd call it a success: Have a look
I recently used the BDD style of GWT in a high-level requirements document. I didn't get any feedback about the GWT from the customer buy my boss said he liked it as it was very clear and easy to understand. Note he has no knowledge of BDD that I know of. I didn't put in user stories as this would probably have been a bit too airy fairy for people with a traditional waterfall background. Maybe I'll try putting in user stories next time.
By the way this was not a eye ball UI project. It was an integration project syncing data from a web service into a database. So it shows that GWT works even for non-"eye ball" UIs.
I've been using Context-Specification style on several projects (using MSpec) with great success. I am still trying to understand the real benefits of the Scenario style. The more I use the context-specification style, the more I like it, and the tighter my applications feel.
I am re-building our poorly designed web application from scratch, and wanted to get into TDD and basically "do things right" as kind of a learning project. What tools, processes, and resources are recommended to do it "right" from the start? I will be working alone as the architect and developer, with the backup of a business analyst and business owners for usability testing and use cases.
EDIT:
Right now we use SourceSafe for source control, is there any reason technologically that I'd want to try to get us to switch to subversion?
EDIT #2:
Looks like the consensus is:
Cruise Control.NET
Subversion(if I want to stop using SourceSafe)
ASP.NET MVC
NUnit for unit testing
Resharper
I highly recommend that you take a look at MVC for ASP.NET if you want to make unit testing a high priority in your development process. It sounds like it is perfect for what you are trying to do.
I would also recommend CruiseControl.NET for continuous integration (this is important if your team is going to grow).
Subversion is my favorite source control system when I am working on small teams. Use Tortoise SVN for Windows Explorer integration.
An answer to your source control question...
Redesigning an app from the ground up will probably be a time-consuming project, I wouldn't waste time changing source control unless you already know exactly which one you will use and have experience setting it up.
Visual SourceSafe gets the job done, especially in a 1 person effort, and its already in place so run with it.
We are using a setup with Visual Studio 2008, Resharper 4.1, Subversion for sourcecontrol, Cruise control for automated builds and the build in unit testing for all our automated tests. and Linq2Sql for or mapping. You could swap out anything but VS (obviously) and resharper (it's so cool) but you could easily use another sourcecontrol, or mapper or unit testing tool.
Here are some tools that can make it easier and safer to work (Googling the names will bring up the relevant pages):
Subversion - Source control
NUnit - Testing framework
CruiseControl.Net - Automated builds
Visual Source safe has a strict locking policy so that only one person can work on a file at a time....CVS or subversion allows multiple users to work on the same file at the same time.
All of the suggestions here are good, but there is no magic bullet. You'll have to look at how big your app is, how many users, how is it deployed, etc. to make your architectural, process, tool set, and other decisions. TDD, for instance, is a good methodology, but not the only good methodology for "doing things right". Another one, CruiseControl is awesome, but in a single developer project, it is probably overkill.
Be consistent in whatever you do is my best suggestion - if you go with TDD, GO WITH TDD if you know what I mean.
We re-wrote our website like you're doing and we are using C# with MVC. Its great. We use Microsoft's SourceSafe to control our code and it works awesome. Since you are the only developer it will depend on what you like.
Microsoft's sourcesafe allows us to create a branch that we can work off can keep under source control, and we can switch between both easily. (I really haven't used subversion to much so I can't comment on it.)
We use NUnit to test/ mock out our code. It super easy to mock them out. We created a class that will save and read the objects.
The save function:
Stream stream = File.Open(simplePath, FileMode.OpenOrCreate);
BinaryFormatter bwriter = new BinaryFormatter();
bwriter.Serialize(stream, actual);
The read function:
Stream stream = File.Open(simplePath, FileMode.Open, FileAccess.Read, FileShare.Read);
BinaryFormatter bwriter = new BinaryFormatter();
object returnObject = bwriter.Deserialize(stream);
We've used NUnit to mock out xml and SQL.
Good luck
If you're about to set up a fresh instance of subversion and continuous integration, starting green from a VSS background, these two free packages will likely save you days (or weeks) of time:
Visual SVN Server
Sets up everything needed for a subversion server, including Windows AD auth and an admin GUI. Free, you may consider supporting their excellent VisualSVN VS addin for source control integration in Visual Studio. Alternatively, can look at AnkhSVN
TeamCity
A Continuous Integration package (alternative to CruiseControl.NET) from JetBrains (makers of ReSharper, a fantastic tool, as mentioned) which is free for the professional version (up to 20 users and 3 build servers).
These two packages are some of the easiest installs around, challenging VSS itself :-)
Using SVN may take a little adjustment; but with the excellent doco for whichever client you pick (AnkSVN, VisualSVN, TortoiseSVN, or some combination), you'll be fine.
Besides, you know where to find people eager to answer any questions you might have in exchange for Rep ;-)
Check out TypeMock or Rhino Mocks. Mocking can save you so much time and pain when you're unit testing a web application.
If you are just starting out then I would change as little as possible (especially since you are the only developer), so stick with Sourcesafe. There is absolutely nothing wrong with it in your situation.
Later down the line, you might look towards the MS Team System, or perhaps go for other 3rd Party tools.
Personally I'm not a fan of Subversion, but I recognise that it's a popular tool across the industry.
As for TDD-specific software, I can't offer any advice. Do you have preferred tools for UML or whatever formal methods you are using?
One thing to mention: Be a 100% sure that you understand what the program's doing and what's it supposed to do, before doing any changes. A 'bad' softwer often turns out to be 'not that bad' after understanding the whole situation.
Sourcesafe can be ok, especially for one person, but when there'll be more and more ppl on the team, the lock model can get annoying, but for the time of being: stick with it