We are currently using Jira 5.1.6 with GreenHopper 6.0.5. We have a lot of projects, probably about a dozen total but only a few that are actively worked on at a time, with the rest being there for occasional bugfixes or other tasks. The 4–5 developers in our company are likely to be working on a couple projects at once (some working on just one, some working on maintenance on several, and it somewhat varying who's working on what depending on the business priorities).
So, GreenHopper seems set up from a very project-centric view. I can set up a Rapid Scrum Board for a project, and make Sprints within it of work to do for that project. This can give the business a good view of work into that project. Potentially, one can also make a Board for all of the projects (since GreenHopper 6 added that), and make a kind of "global sprint" across everything. If we were to have this kind of global sprint, all of the project owners would need to work at once on figuring out what should get done over the next couple weeks, which might be workable, but seems a bit tricky and would require a lot of coordination.
What I think we want is some kind of "resource view" or something, so that project owners could set up their tasks in their sprints, but there's some sort of view for each developer to tell them what task they should be working on next no matter which project's sprint it's in, and some way for our manager to allocate our time across the projects. So, I might be scheduled to work, for example, 20 hours a week on project A, 10 on project B, and 10 on maintenance of other projects, and then project owners making sprints could see how much time they had allocated, and I as a developer would see some kind of unified view of my upcoming tasks, so that I would know what I should be working on next and what's coming soon. I don't know if that description is exactly what we want, but I think we want something along those lines, and it seems like we can't be the only place that wants some sort of project-based view as well as a resource-based view.
The thoughts I've had of how we might approach this from my exploration of GreenHopper so far are:
Create those "global" sprints I mentioned, and work as a department at the beginning of each sprint to try to schedule what we'll all be doing. Projects can get a look at their particular piece of the sprint using a Quick Filter or somesuch, and we just have to deal with coordinating those sprints.
Use the "Parallel Sprints" feature on an all-projects Board, and have each developer create their own sprints of the tasks they have coming up. This helps with getting a resource-based view, but is probably tough for projects to figure out status of things, and definitely feels like squeezing GreenHopper into a space that it really doesn't want to go.
Create a board for each project of the things to be coming up for each project, so each project gets its own Sprints and we get the project-based view of things, and just have each developer track themselves which projects' sprints they should be getting tasks from. Basically, just GreenHopper isn't the tool for a resource-based view, so don't even bother, and trust our developers and our manager to look across all these projects for what tasks to work from rather than trying to do it all in one place.
None of those seem great, though I'm sure we could make do with any of them. But I keep on coming back to that it doesn't feel like we're doing something bizarre or unique to us, and we would have thought that since Jira/GreenHopper was an industry-standard agile tool that it'd be easier to use it for what we're trying to do. Are we doing something crazy? I think we'd be fine with changing our process to use standard practices if there's a standard way of doing Agile across multiple projects out there. Is there some GreenHopper setting or report or something somewhere I've missed? Is there some other Jira plugin that we should be using instead of or in addition to GreenHopper? Do other teams out there use one of the above approaches and can give advice on whether or not it's a good idea?
Any help would be appreciated. Thank you.
"... seems a bit tricky and would require a lot of coordination." Yup, sounds like project management to me.
I'd create boards for each product that gets released on its own schedule. I'd also create a query to show each user the issues assigned to them sorted by Sprint so they can see what work is on their plate. The issues will be across multiple boards and sprints.
I do wish that GH helped with resource allocation more, including totaling up the time allocated in the filter in the previous paragraph. At the moment I end up exporting the results of the filter to Excel and using that to sum up totals by resource.
I asked this question in perhaps the more appropriate place, on the Atlassian forum:
https://answers.atlassian.com/questions/99020/how-do-i-use-greenhopper-to-manage-developers-across-multiple-projects
And I think the answer there from them was very good. I created a board for each project, limited to its project and used for creating that project's sprints, and the developers use an "All Projects" board to see all of the sprints that they're a part of.
Doesn't handle resource allocation wonderfully, as mdoar states, but it does seem to be using the tool the best way that it can be for this for now.
Related
I was reading this answer in trying to understand how to work with multiple developers working on multiple branches of a project. My first reflex was to want Jenkins to run a separate build for each branch, but as I understand it, this is a bad way to approach the problem.
Now, I see how having very small features or parts of features which get merged back into the main branch often is the preferred way to go, but I can't quite wrap my head around what happens when a project goes through a very large architectural change.
Say I have a web project written in AngularJS and the team decides that for the future of the project, it needs to be moved over to using ReactJS instead. Said current project would have a reasonable number of features already implemented and tested. At this point, I can't imagine any smaller increment for the new "feature" of using ReactJS other than having it be on part with the current state of the project, meaning every test currently passing should still pass once it's done. Anything else would mean a regression for the project and I know of very few clients who would be ok with this.However, that's hardly going to be the case until the switch is almost 100% done, which will not be a small amount of work.
I might not understand the concept perfectly, but I don't see feature toggles working here (especially if the move to ReactJS requires we modify, say, the Gruntfile since that will inevitably break things a lot). Does the team doing the migration simply needs to tell the rest of the team not to touch the project until they say it's ok? That seems like a weird solution to me.
So I'll admit, I'm at a loss as to what the proper workflow would be here. Any input would be appreciated as our development process is something I constantly try and make better, even with my limited experience in the field.
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 3 years ago.
Improve this question
I hope that somebody with more experience (bad or good) can help me out here: I am setting up a project tracked in JIRA. The whole process with user stories, documentation, sprints, workflows, bamboo and fisheye integration, etc. is set up. But now I have a rather administrative question:
Where should developers log their work in meetings, such as stand-ups and retrospectives and for writing specifications (detailed descriptions of user stories to come)? I really cannot see what makes sense here, as I need the developers (obviously) to track this work, too. As far as I can see, the possibilities are:
Separate PROJECT-ADMIN JIRA project with simple, non-agile issues
Separate and parallel sprint with admin tasks
Administrative tasks for each sprint
Other versions??
Option 2 seems very hackish, as parallel sprints are just in a beta-stage for the JIRA agile (former Greenhopper) module. Option 3 seems a bit much work to setup for each sprint, and I am not sure, how this influences my velocity (ideally, I want to see the possible amount of story points that can be achieved in a sprint). Option 1 seems the most reasonable to me, but others have advised against it, unfortunately, without offering a solution. I haven't really looked into option 4, as IMHO this is very similar to option 2.
I couldn't see any best practices anywhere, so I would very much welcome any advice from more experienced people. Thank you very much.
We use Tempo to log our billable work against JIRA issues, whether a single Epic for a small project or individual tasks for a larger project. For non-billable work we have a single project where people can optional log work, and we also use it for planning our time. So option 1 is the closest there. We could also have categories for different work logged in Tempo and handle this case that way.
So I face this exact issue with my team and this is what is working for us (for now) YMMV.
Our current structure is that we have a Roadmap type project (call this Planning) where all issues come into at first. Thereafter we create issues in related product projects (call this Product).
In the beginning of the lifecycle, any meetings, scoping, etc will have sub-tasks created and the time will be tracked on Planning. Once scoped and scheduled for work a new issue is created on Product and linked to this original issue.
Once the Product issue is assigned and the dev is called to any meetings whilst this issue is in a sprint we will create a sub-task on Product and assign the time. If the issue is not in a sprint we go ahead and create a new sub-task in Planning and assign the time there.
When then also have a project where we do Housekeeping type work. So if we need changes to JIRA, Stash, Confluence we will create the issues here. We will then create a new issue on Planning, link the issue and schedule that accordingly.
We have a meta project that acts as a bucket for anything that doesn't fall into the other categories which we sift through every now and again to identify if we need to create separate projects.
I have created a custom field that rolls up all the times of any linked issues found on the Planning board
Have a look at the Twitter blog Visualizing Epics and Dependencies in JIRA by Nicholas Muldoon maybe this can help you in some way too.
One caveat we are still exploring the best way to do this. Each environment is different and what works for us might not work for you.
I have faced the same issue trying to track team member hours that are unrelated to the project or related to the project but not to a specific story or task.
Initially we went with option 3 & had several administration tasks that persisted across sprints. While this was relatively easy to implement it failed for us as we had team members that sat across multiple projects & as a result these administrative tasks that resided in each project were impossible to manage / report on for these team members.
In the end we went with what you have described as option 1. By creating a separate project with "non task related" issues such as Planning Meetings, Technical Issues & Client work then installing the JIRA Misc Time Log & Report Extensions plugin we could provide users with an easy means of logging times without having to change projects or boards (since the plugin adds a dropdown menu to the top navigation).
The plugin then allowed us to get reports on where team members we logging time off project regardless of how many projects they worked on concurrently.
I was having the same issue, and I know some time has passed since the moment this question was posted but maybe this is useful for a lot of people:
Tempo has a dedicated feature for that thing you want to achieve and is called Internal Issues. not to be confused with Internal activities.
You can go there by navigating to Config>System and then click on the add-ons tab. Then scroll down to the Tempo section in the menu on the left bar and there you'll find a link that reads Internal Issues. There you can create the issues. Please keep in mind that before creating internal issues you have to create the tasks, for instance "Sprint Planning" or "Retrospective" in the project without assigning to anyone, just to the project.
When your users go to log their time for those "Internal Issues" they go to Tempo > Timesheets and then click in the upper right button that reads log work. There, in the right menu they'll see the "internal issue" option where they can pick those internal issues you previously created and log the time that the team spend on SCRUM Ceremonies.
I am looking for some advice on how to allow easy customisation and extension of a core product on a per client basis. I know it is probably too big a question. However we really need to get some ideas as if we get the setup of this wrong it could cause us problems for years. I don't have a lot of experience in customising and extending existing products.
We have a core product that we usually bespoke on a per client basis. We have recently rewritten the the product in C# 4 with an MVC3 frontend. We have refactored and now have 3 projects that compose the solution:
Core domain project (namespace - projectname.domain.*) - consisting of domain models (for use by EF), domain service interfaces etc (repository interfaces)
Domain infrastructure project (namespace -projectname.infrastructure.*) - that implements the domain service-EF Context, Repository implementation, File upload/download interface implementations etc.
MVC3 (namespace - projectname.web.*)-project that consists of controllers, viewmodels, CSS, content,scripts etc. It also has IOC (Ninject) handling DI for the project.
This solution works fine as a standalone product. Our problem is extending and customising the product on a per client basis. Our clients usually want the core product version given to them very quickly (usually within a couple of days of signing a contract) with branded CSS and styling. However 70% of the clients then want customisations to change the way it functions. Some customisations are small such as additional properties on domain model, viewmodel and view etc. Others are more significant and require entirely new domain models and controllers etc.
Some customisations appear to be useful to all clients, so periodically we would like to change them from being customisations and add them to the core.
We are presently storing the source code in TFS. To start a project we usually manually copy the source into a new Team Project. Change the namespace to reflect the clients name and start customising the basic parts and then deploy to Azure. This obviously results in an entirely duplicated code base and I’m sure isn’t the right way to go about it. I think we probably should be having something that provides the core features and extends/overrides where required. However I am really not sure how to go about this.
So I am looking for any advice on the best project configuration that would allow:
Rapid deployment of the code – so easy to start off a new client to
allow for branding/minor changes
Prevent the need for copying and pasting of code
Use of as much DI as possible to keep it loosely coupled
Allow for bespoking of the code on a
per client basis
The ability to extend the core product in a single
place and have all clients gain that functionality if we get the
latest version of the core and re-deploy
Any help/advice is greatly appreciated. Happy to add more information that anyone thinks will help.
I may not answer to this completly, but here some advices:
Don't copy your code, ever, whatever the reason is.
Don't rename the namespace to identify a given client version. Use the branches and continuous integration for that.
Choose a branching model like the following: a root branch called "Main", then create one branch from Main per major version of your product, then one branch per client. When you develop something, target from the start in which branch you'll develop depending on what you're doing (a client specific feature will go in the client branch, a global version in the version branch or client branch if you want to prototype it at first, etc.)
Try the best to rely on Work Item to track features you develop to know in which branch it's implemented to ease merge across branches.
Targeting the right branch for you dev is the most crucial thing, you don't have to necessary define some hard rules of "what to do in which occasion", but try to be consistant.
I've worked on a big 10 years project with more than 75 versions and what we usually did was:
Next major version: create a new branch from Main, dev Inside
Next minor version: dev in the current major branch, use Labels to mark each minor versions Inside your branch.
Some complex functionnal features was developped in the branch of the client that asked for it, then reversed integrated in the version branch when we succeeded in "unbranded" it.
Bug fixes in client branch, then reported in other branches when needed. (you have to use the Work Item for that or you'll get easily lost).
It's my take on that, other may have different point of view, I relied a lot on the Work Item for traceability of the code, which helped a lot for the delivery and reporting of code.
EDIT
Ok, I add some thought/feedback about branches:
In Software Configuration Management (SCM) you have two features to help you for versionning: branches and labels. Each one is not better nor worst than the other, it depends on what you need:
A Label is used to mark a point in time, using a label, for you to later be able to go back to that point if needed.
A Branch is used to "duplicate" your code to be able to work on two versions at the same time.
So using branches only depends on what you want to be able to do. If you have to work one many different versions (say one per client) at the same time: there's no other way to deal with it than using branches.
To limit the number of branches you have to decide what will be a new branch or what will be marked by a label for: Client Specific Versions, Major Version, Minor Version, Service Pack, etc.
Using branches for Client versions looks to be a no brainer.
Using one branch for each Major version may be the toughest choice for you to make. If you choose to use only one branch for all major versions, then you won't have the flexibility to work on different major versions at the same time, but your number of branches will be the lowest possible.
Finally, Jemery Thompson has a good point when he says that not all your code should be client dependent, there are some libraries (typically the lowest level ones) that shouldn't be customized per client. What we do usually is using a separated branch tree (which is not per client) for Framework, cross-cutting, low level services libraries. Then reference these projects in the per client version projects.
My advice for you is using Nuget for these libraries and create nuget package for them, as it's the best way to define versionned dependencies. Defining a Nuget package is really easy, as well as setting up a local Nuget server.
I just worried that with 30 or 40 versions (most of which aren't that different) branching was adding complexity.
+1 Great question, its more of a business decision you'll have to make:
Do I want a neat code-base where maintenance is easy and features and fixes get rolled out quickly to all our customers
or do I want a plethora of instances of one codebase split up, each with tiny tweaks that is hard (EDIT: unless your a ALM MVP who can "unbrand" things) to merged into a trunk.
I agree with almost everthing #Nockawa mentioned except IMHO dont substitute extending your code architecture with branches.
Definitely use a branch/trunk strategy but as you mentioned too many branches makes it harder to quickly roll-out site wide features and hinder project-wide continuous integration. If you wish to prevent copy/pasting limit the number of branches.
In terms of a coding solution here is what I believe you are looking for:
Modules/Plug-ins, Interfaces and DI is right on target!
Deriving custom classes off base ones (extending the DSL per customer, Assembly.Load())
Custom reporting solution (instead of new pages a lot of custom requests could be reports)
Pages with spreadsheets (hehe I know - but funnily enough it works!)
Great examples of the module/plugin point are CMS's such as DotNetNuke or Kentico. Other idea's could be gained by looking at Facebook's add-in architecture, plugin's for audio and video editing, 3D modeling apps (like 3DMax) and games that let you build your own levels.
The ideal solution would be a admin app that you can choose your
modules (DLL's), tailor the CSS (skin), script the dB, and auto-deploy
the solution upto Azure. To acheive this goal plugin's would make so
much more sense, the codebase wont be split up. Also when an
enhancement is done to a module - you can roll it out to all your
clients.
You could easily do small customisations such as additional properties on domain model, viewmodel and view etc with user controls, derived classes and function overrides.
Do it really generically, say a customer says I want to a label that tally's everyone's age in the system, make a function called int SumOfField(string dBFieldName, string whereClause) and then for that customers site have a label that binds to the function. Then say another customer wants a function to count the number of product purchases by customer, you can re-use it: SumOfField("product.itemCount","CustomerID=1").
More significant changes that require entirely new domain models and controllers etc would fit the plug-in architecture. An example might be a customer needs a second address field, you would tweak your current Address user-control to be a plug-in to any page, it would have settings to know which dB table and fields it can implement its interface to CRUD operations.
If the functionality is customised per client in 30-40 branches
maintainability will become so hard as I get the feeling you wont be
able to merge them together (easily). If there is a chance this will
get really big you dont want to manage 275 branches. However, if its
that specialised you have to go down to the User-Control level for
each client and "users cant design their own pages" then having
Nockawa 's branching strategy for the front-end is perfectly
reasonable.
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
Do you need a project management system if you work alone? I mean a project management system that includes issue tracking, wiki, etc.
Currently I keep my issues in a very good organizer software and I keep project documentation in Word files (and of course I have a version control system), so I am not really sure if I need a project management software, because I work alone.
One useful thing, I can think of, that project management system can additionally give me is linking issues with commits (UPDATE: I've found this feature useful enough: for example, right now I am creating documentation for the new release of my project and I consequently open every issue with "Pending for release" status, then I read the issue's description and then I can quickly view the diff of the commit for this issue - this helps me to see details and write better documentation).
Another one - sharing issues so your users or your employer can view or manage them.
What am I missing? Is project management software necessary when working as the only programmer?
UPDATE: I've thought up another useful thing: In comments we can give a link to an issue or a wiki article with detailed information about the code being commented.
You say you use some organizer software that helps you managing issues. So you already have your custom project management system. Just keep it.
Project management systems does not have to be big, support sharing data or other kinds of documentation. As a programmer you are supposed to use one to make your work organized, but it doesn't matter which one. You can happily use plain text files if they work for you.
Still, if there is even a slight chance that you'll be cooperating with someone, you should try something that allows cooperation... just to know how they work.
Do you need a project management system if you work alone?
Yes.
Currently I keep my issues in a very good organizer software and I keep project documentation in Word files (and of course I have a version control system).
See. You have a project management system. Why ask?
project management system can additionally give me is linking issues with commits.
That's not necessarily project management. You can easily do that with you version control software.
Read this: http://tortoisesvn.tigris.org/issuetrackers.html
sharing issues so your users or your employer can view or manage them.
That means you're not working alone, if you're sharing something. What are you asking for here? How to share?
When working alone is the key thought to pursue here. When you are alone, you don't have the luxury of having someone else to keep you on your toes. A good "system" is essential therefore in order to help you manage your projects. As to which system to employ, that all comes down to your individual needs, and how much time you want to spend maintaining such a system.
If there is any possibility that you will need to involve someone else, then you need to decide if the system you use will scale to meet your changing requirements. This is also true if you continue to work alone and your workload changes.
As for software, that is almost another question entirely. I personally prefer to use a software tool to track all of my tasks, and to help me to collate data that helps me to determine priorities and task scheduling. That is in a nutshell what project management is all about. When working at home on my own projects, I use a simple Redmine configuration to manage different types of projects. Planning for programming projects, working out the logistics for my wedding, even managing my house renovations. All have been added to my private Redmine setup because I'm too lazy to try and keep paper-diary styled systems updated. At work, I have a more complex configuration to manage the myriad of programming projects we have here, and to manage the dependencies between them.
I've found though, that the most important thing is to ensure that the processes are streamlined, and that the supporting tool can be configured to match the processes. You don't want to have to change your processes because the tool isn't up to par. Also, the tool should not become the sole focus of all of your efforts, therefore it should be configured to reduce the "red-tape" side of things. You only want to capture enough information to describe your tasks, and to determine when they need to be done, who will do them, and when they are completed. Yes, your needs may require more information to be captured, but always try to minimise this, as you don't want to feel like you are always updating your project management tool when you'd rather be working on that latest killer algorithm you've been looking forward to doing! ;-)
I would not want to work without a system like trac anymore, even if I'm the only one working on the project. You should use a version control system of course, no question about that. Then there are two or three things coming up, you also mentioned.
First is documentation. There are lots of different possibilities and a wiki is just one of it. I personally use the wiki mostly for ideas, thoughts and notes. It's easy to put drawings in it, link to ressources in the web and really quickly edit. This can not replace in code documentation you do with source comments or tools like doxygen. And this can also not replace a manual, if the project requires one.
The second thing you'll come across is some kind of todos, let it be bug reports (even from yourself), feature requests, things like that. You can put them as comments in your code or use a list in a text file or your PIM system, but you can also use a ticket system, just to keep track of what you want to or have to do in the project in the future. You can not do everything just now.
Third is the bigger plan, this is not just atomic todos but things trac calls milestones. This has to be written down somewhere.
The great thing about trac now is, you can integrate all these thing you have to do anyway in one tool and even cross link between all the parts. Link to code lines from a ticket, reference tickets in a commit message, use ressources from your repository in the wiki, automatically build doxygen and integrate it and so on. You must decide if you want to use trac for all the things around your project or something else, but you have these things anyway so why not use a system integrating it all? ;-)
I mean a project management system that includes issue tracking, wiki, etc.
I don't use an Issue Tracker, but I practice continuous (not "big bang") integration, and I test (look for bugs) early and often, and I fix any bugs as soon as I find them, so that list of known Issues remains small.
I also have a lot of structure in the source code (e.g. separate projects/assemblies for separate components), so I try to have "the code is the documentation".
The table at What Types of Documents Should You Create? implies that you may not need documentation (e.g. a wiki), unless you're working with other people: e.g. with a manager, testers, and/or end-users.
You may be the only programmer now but will it stay that way forever? I often work alone on development projects but I still track the "to do" list and issues in a simple Access database. Makes it much easier if you need to expand/hand over a project.
You absolutely do, at least for a bigger projects that take a few months. For the past years I tried :
eclipse notepad plugin - just text file - effective
eclipse mylyn tasks - better, enough for one-man-show, but I was still having issues with migration between eclipse instances
youtrack is free and it's like a JIRA but more simple and practical for an individualist
With notepad I was able to focus on current task, but I wasn't able to maintain long term iterations, because without issue tracker I was loosing discipline, dealing with 3 tasks at the same time, not finishing them, etc.
As a follow up to one of my previous posts 'Using Version Control for Home Development', I am now asking about opinions as regards using a Build Server for a pet project.
Lately I have been reading about this 'Build Servers' concept, and I have looked at applications such as Maven and CruiseControl.Net.
And thus I ask, how feasible is it to use something like CruiseControl.Net for my home pet projects?
Reason I ask is that I think that these Build Servers are mainly aimed for team projects...but then again, I'm still very new to this Automated Build process.
Keep in mind that most of the time, these pet projects are only handled by one man, not a team.
So should I look more into this concept for the sake of using at home, or should I just get some practice on it for experience's sake?
[EDIT]
Although I thank you all for your answers as regards alternatives to CC.Net and such, no one has yet really tackled the issue of whether it is feasible or not to implement a Build System for Home Development ?
It is completely feasible to implement a build server for your home projects. I've implemented CC.Net for my home projects myself and it is pretty easy to do so, even for the first time. I would say the learning curve (depending on your experience) is less than a day to get your first project up and building, though there is always the longer tail on that curve as you dig into some of the more interesting details.
The question to me is more one of the motivation for continuous integration on these projects. If you are using "Home Project" synonomous with "Throw-away Project", there probably isn't much point in going to the trouble of CI unless you are using it specifically as a CI learning excercise.
However, assuming these are not throw-away projects you are talking about, I've found (in addition to the more obvious benefits of automation) that implementing CI helps reduce the overhead involved in coming back to a project you've walked away from for some period of time. Of course, unit tests are the most valuable asset in this regard, but the combination of unit tests with an automated build/deployment process really allows you to focus on the new and changed requirements when you come back to a project after having set it down for a while.
Additionally, as mghie points out in the comments to this answer, "CI will give even greater benefit for home projects if they build upon each other, so changes in one project could cause the build to break in others."
My advice, just do it once so you have a clearer picture of what is involved and the benefits you might reap and drawbacks you might incur. Then make the decision for yourself as to whether or not it is worth continuing to do. Like I said, the learning curve is reasonably low so the investment you will have to make in just giving it a try shouldn't be the reason not to.
Nutshell: Feasible - Yes, Desirable for home projects - Quite Possibly, Worth further investigation - Definitely, Investment - Relatively low
As an alternative to CC.Net, I recommend you to give a look to TeamCity, is really easy to setup and get it up and running.
Related question:
Best Continuous Integration Setup for a solo developer (.NET)
i installed CC.net months ago it took me a whole night to configure it and create the xml configurations and i have no regrets about it, it smoothly integrates with SVN, Nunit, Nant or Msbuild. you should try it only if it is to gain experience
Take a look at Hudson its very easy. You need to just deploy in Tomcat or any other servlet you use container. Once up every configuration can be done using browser. Hudson supports maven, ant etc and supports all the major SCMs. I have been using hudson for the past one year and not faced any trouble.
CC.NET is very feasible, in fact with the free cost and wide ranging supported actions. Not to mention the fact that since you can get the source code you can modify it to you needs I could not imagine anything better. I read the other compliants about how difficult it is to set up, but to be honest I had my first simple TFS/VS2005 project up within an hour. Just remember if you run into any issues or snags CC.NET has a pretty active google groups for Users and Devs who would be willing to help you through any gotchas.
I love CC.NET and I'm a big fan of CI, but I have to ask: with only one developer on the project, what integration scenarios exist? Wouldn't you just build the entire project in Visual Studio, negating the need for CI?
I would agree that CC.NET is a great option for local/home development. I wanted to add that it does not require an SCM tool in order to make it work. There is a file system watcher plugin that will just monitor for a file change. That way you don't have to have a check-in in order for it to execute. Also you don't have to wait for the CI cycle to complete, it's much like having F6 run everytime except for the IDE doesn't use all it's resources, you can keep coding away. If it breaks, you can choose to investigate or just ignore. There is no one way to do CI.
If you do create unit tests, having that constantly execute against your code on every save certainly has some advantages in early problems. Using CCTray allows you to see it, but not be intruded upon. My 2 cents.
Finally, setting it up the first time can be a little tough, but you can tweak out a Visual Studio C# template or whatever you desire to automatically configure your CI setup with the least amount of information required by the user.