Related
I'm looking for feedback from .Net developers who have experience with Aldon as a lifecycle management platform. We're seriously considering using Aldon for lifecycle management including source control, automated builds, etc. I know there are a lot of other options out there, but ours is primary an AS/400 shop (with AS/400 programmers outnumbering .Net developers 6 to 1), and Aldon is used already by our iSeries team. The benefit we're looking for is having one lifecycle management suite.
Basically, I'm looking for opinions from people who have used Aldon and another set of tools (perhaps TFS, or a combination of SVN, Cruise Control, etc). If you've worked with both, do you have a recommendation on whether this is a good idea, or a bad idea? It's obviously a big choice, so any feedback would be helpful.
Edit - Added
No answers or comments... AND my first Tumbleweed badge. I'm not sure if this is just a bad question, if nobody actually USES Aldon to manage their .NET work, or if there's just nobody using Aldon that used other products and can offer a comparison.
So, I'm offering a bounty to sweeten the deal, and broadening the scope of the question... If there are any people out there USING Aldon at all, can you provide any information on issues you have had, is it a good suite of tools, frustrations, or gotchas, things you love, etc?
Added -even more
Our primary goal is to have one product to manage both our .NET and our AS/400 (primarily RPG) development. If you have a suggestion for a different suite of tools, or have tried it and decided it isn't worth it, I'll take that answer as well.
I'm working in a shop similar to yours--in our case, there is a substantial legacy code base of iSeries COBOL code, and a growing number of .NET systems--and the .NET developers have successfully lobbied to use Subversion for source control. In my admittedly brief time evaluating the product, it seemed like Aldon was not very flexible at all in areas like branching and tagging, and has a very cumbersome and arcane interface. Since product lifecycles are (mis)managed separately in our shop anyway, limiting the .NET use of Aldon to source control only, it was a simple decision. In the .NET world, Aldon lags far behind the standard open source tools in features and usability, and has no hope of competing with TFS. In our case, managing .NET code outside of Aldon has definitely increased developer productivity and decreased frustration.
One example...coming from a Subversion shop, I was trying to find out how to create an experimental branch in Aldon. If it is possible at all, the documentation did a great job of obscuring the feature, and our Aldon admin had never come across the concept. Everything in our shop is locked down tight, with admin rights needed to create projects, versions, etc. This might be worthwhile from a lifecycle management standpoint, but from the perspective of a developer trying to get work done, it is a killer. I don't think lifecycle management and source control belong in the same software, and Aldon has done nothing to dissuade me from that opinion.
I think you will find nobody here uses it. .NET people fall into two categories - those that are "cheap" (i.e. trying to save costs) and then basically you look or something like open source. And those who pay a lot, and most of those go with Team System - because it is ingtegrated into Visual Studio from the bottom up. AS/400 is a pretty rare intermix for .NET developers, so, at the end - you possibly are just out of luck.
I Personally am not sure I would even bother with it. THere is a lot more to soemthing like Team System than tracking source etc. - lots of good testing features, build in continuous integration etc., and all that without running through hoods in order to - well - get then an inferior product.
We encountered the same problem at my workplace a few years back when we started up our first .NET project in the midst of a bunch of RPG developers. At the time, we chose to use a separate source control system (Subversion) for anything written in .NET (or for anything else that somebody wanted to use it for). We moved all of our projects (.NET and AS/400) into Gemini for time and defect tracking purposes. Basically, we chose a single product to manage our .NET and AS/400 projects at a high level but different tools for version control, automated builds, automated testing, etc.
Years later I can happily say that this has worked out quite well for us. I really can't think of any issues this has caused - but can attest to the fact that it has avoided some potential headaches and butting of heads. I do think that you will have an easier time finding (good) .NET developers by choosing a widely used version control system. I can't speak for anyone else, but for me the use of a version control system I have never even heard of would be a bit of a red flag in an interview situation.
I work in a Visual Studio/.NET shop which is still using VSS 2005 for source control. We are looking to upgrade to VS Team Foundation Server and use it's source control system, but I'm curious if that's really the best option. The creators of StackOverflow use Subversion but comment that it's a pain to merge code forks back into the main product (discussed in podcast #52). Joel mentioned that Mercurial is used at Fog Creek. Knowing that Joel is something of a software snob and he chose Mercurial over anything from Microsoft, I thought I would pose the quesiton to the StackOverflow audience: which source control product is the best for Visual Studio developers?
We switched from VSS to SVN, using only TortoiseSVN for a long time. Recently we began using the VisualSVN plugin for VS (unfortunately not free).
I must say, after getting over the initial pain of not having source control integration in VS, I really liked the level of control I had over all my source control operations. I highly recommend this route.
If you go with Subversion and must have source control integration, I highly recommend VisualSVN.
If you want to give SVN a try, you can install the very free (and very easy to setup) VisaulSVN Server product and have SVN running in just a few minutes on a Windows server.
My recommendation is for SourceGear Vault. It's close enough to Visual Source(un)Safe to feel "comfortable" with right away, it's rock-solid (built on SQL Server which solves your backup hassles, too), it's very reliable, has great support for branching and merging - all around good stuff.
It's free for teams up to 2 devs and reasonably priced for larger teams - much less $$$ than Team System (also it's only a Source Control, of course - not a whole team dev system). We use it in conjunction with Fogbugz bug and issue tracker and that combo gives up all the bang we need for much less buck.
Highly recommended.
Marc
I've worked with VSS, CVS, SVN, and TFS.
VSS: Skip it. I've lost too many changes that literally have just vanished.
CVS: Great solution. Has one feature SVN is missing with a visual of the merging.
SVN: Great solution. You can get add-ins to integrate if you need them. I have only one complaint: merging between branches could be better. But, the product is bomber and very affordable.
TFS: Where I was working, they didn't do much with it. They only used the source control. I was excited to use it, especially the shelving, but I couldn't merge the changes to a branch. I would say it's pretty much what VSS should be. Sometimes MS tries too hard to do things for you that you just have to do for yourself. Also, the UI isn't intuitive.
So, I'd stick with SVN. Though, the new open source standard seems to be GIT (can't comment on it though).
It seems that you want to have VS integration but I question the reason for that.
A good source control product has many more features than just VS integration.
You can get subversion to integrate with VS ( Ankh svn and visualsvn ) and I've also used vault which is stable and integrated with VS but I use source control for other things other than just vs work.
So I prefer to work with source control out of the product. You should try it.
The source control is only part of VS Team Foundation Server, which is a complete project management system.
I used both SVN and TFS, and both of them are more stable, robust than VSS.
Coming from VSS any system would be an improvement;-)
Perforce is probably the best mainstream tool I have used. Rational Apex was even better, but unless you're writing Ada that information is of no use to you.
ClearCase is pretty powerful, but I found it pretty hard to use (admittedly I only used it for a couple of weeks, so I possibly didn't give it a fair trial).
For the cost (free) SVN is excellent. The Tortoise shell add-in makes it very easy to use in Windows.
EDIT.
I see I just got an upvote from this ancient answer :-) This caused me to revisit and I find I need to update my answer.
I now use TFS at work and I really like it, it's a big beast and not appropriate for home projects perhaps, but it's a commercial tool and worth a look if you really value VS integration. I'm sure Perforce and Clear Case are still great products too, but I am out of touch with those now.
For smaller projects or personal work at home I now use Git. I don't particularly care about VS integration though, I just use it from the command line, but at home I switch between several different environments so VS integration is not a priority.
I've had much luck with Ankhsvn. I'm able to use it interchangeably with TortoiseSVN and it does a great job of tightly integrating itself with Visual Studio and the project layout.
http://ankhsvn.open.collab.net/
We use plasticscm at work, it's less known, but very well integrated into VS, you have all the options and graphs inside vs itself.
+1 to forget about VS integration.
Many of the best source control tools have great command line interfaces. I've been happily using Git for VS projects for almost a year. The downside is that Git requires a bash shell and it is not very Windows friendly. I'm willing to pay the 'cost' of not having VS integration in order to get all the advanced features that make life really easier.
I would suggest giving Mercurial a try.
I have to add that this advice is more suited for a personal choice of source control. If you are looking for a source control standard for a big company with lots of developers, I would go with a more 'standard' choice like Team System, SVN or Vault.
SVN is better and faster than VSS. We switched from VSS to SVN 2 years ago because VSS was on servers in New York and the operations on VSS seemed too slow for developers in India. SVN is faster because it was meant for WAN as opposed to VSS which is for LAN. Refer this link
You can use windows explorer to perform SVN operations or you can use AnkhSVN to be able to perform SVN operations from VS.Net IDE.
You can prefer locking files before editing if you find merging them later to be a hazzle. But IMHO merging is really not tht painful, because you get to see the clear distinction between your and your collegues code before you go ahead with the merge.
Advantages of SVN can be found here on stack overflow.
I prefer TFSVC as it is integrated with all the other services in Team Foundation Server. But it depends on what you want to do. If you want an ALM solution, this is the way to go. I have the ability to set check in policies, integrated builds, and associate with work items. I like the way it does branching and merging. I can have my testers submit bug work items associated with the code in TFSVC. I have traceability to see who is checking in and breaking the builds. I can run reports and get good visibility into the project. Everything works together.
I hope this helps.
John
We use vault, Its good. But use Team System if you can b/c it's from Microsoft. They know how to deal with their own problems/bugs/wayofthinking.
My vote is for TFS. VSS is more than a pain. I have used SVN outside of VS and I would have to see it work along with it.
Working with source control out of the product? Sounds like more work than necessary. Just because it integrates with VS doesn't mean you can't use it for other things. If I am in VS I want to stay in there and not have to go over to another client application to get my source. I like that VS can check out directly.
It depends are you looking free or commercial version control system.
Subversion
Using Subversion you have great, free, open-source ankhsvn plugin which integration Subversion with Visual Studio. Integration is really fantastic!
Mercurial
If you need distributed version control choose Mercurial with VisualHG plugin. Mercurial, in contract to the Git, was developed with native Windows support and also Visual Studio integration is much better.
PlasticSCM
The best Visual Studio integration I have ever seen had PlasticSCM which is the simple consequence that PlasticSCM is windows-background version control system. It works really well.
I can't believe no-one has mentioned Assembla! It's free for unlimited repositories, unlimited users and 1GB of space!
www.assembla.com
Perhaps you should ask yourself what scm is best for your project.
I like svn cause its free and kind of standard(perhaps a little bit bold to say).
I use both Vault and TFS at work. We used VSS and others had issues with it, so the lead at the time decided to switch to Vault. I have had no issues with Vault, but others had some with merge and branch.
I started using TFS Trial and like it as much as Vault. I do not use many of the extras, such as the bug and work item tracking just yet, but plan to.
Since you did not mention cost and the comapny is already looking at moving to TFS, I would think that will satisfy your need of getting a product better then VSS and allow you to grow into it in the future.
I've used Visual Source Safe (2005) and I wouldn't recommend it. Being a file file based solution leads to the risk of your repository being more easily corrupted. I've used Source Off-Site a SourceGear product that enables remote VSS check-in and checkout over the internet and it worked well, but still had the disadvantage that it was built on top of VSS and the flat file architecture.
SourceGear also make Vault which is my preferred solution. It's a SQL Server based repository so it's not subject to issues with the Windows File System. Restores and backups can be configured just like any other SQL Server database and you can restore to a point in time, not just to your last backup date.
I've also used Source Anywhere (version 2.2) and I found it lacking in features compared to VSS and Vault. But it was a SQL Server solution, which made the backups more reliable.
I'm interested in trying Subversion and if there was a version of Subversion that used SQL Server as the repository I think it would be a reasonable solution. If you're running on another operating system, Subversion is probably your best choice, but if you're running on Windows Server I would recommend a SQL Server solution.
I have an MSDN subscription and I'm wondering what edition of Visual Studio 2008 to get. I recall reading that Team System has a lot of bonus features like doing high-level system architecture stuff, and specialized things related for doing database work. As a solo dev, I wear many hats including database developer and architect - should I use Visual Studio Team Suite to get all of these things, or are they major overkill for a single guy?
EDIT: I have a "special" MSDN license (via the MS BizSpark program for startups) that gives me access to the FULL version of Team Suite for 3 years, for myself and any developers in my startup. After that I have to pay if I want upgrades but I'm free to use it for development indefinitely if I'm okay with not upgrading (per BizSpark licensing).
With that in mind, should I look at Team Suite or stick with Pro? I don't plan to use Team Foundation Server at all.
Well, the "test" stuff is now available in "pro" (but not profiling) so that removes one major comparator. In many ways, the MSDN subscription is a bigger factor than the VS product suite, assuming you don't need the full bredth of tools.
The VS feature list here; the MSDN feature list is here.
I used to use pro, and I never felt I missed much. Of course, you could always get pro plus something like dotTrace for profiling, ReSharper for code analysis/refactoring, and maybe TestDriven.NET for testing - you'd probably still have change left over.
I now have a team suite license (which is very nice), but if I had to pay for it I'd have to think very carefully; I'd probably get developer edition + MSDN.
I'd say that VS Team System is an overkill for single developer sweatshop, but your situation may proves otherwise. Team System is great when you're working on a project where all things are Microsoft, but all the extra features (database, architect, etc) will become useless when you start working with Oracle and MySQL database. Don't put too much stress on the tools, VS Pro is good enough if you want to save money. I'd rather spend more money on extra tools such as third party component and refactoring tools than the shining VS Team System.
But, since you join the BizzSpark program, which I think is really great for startups, I think you should go and try VSTS. You basically pay nothing for the extra features. By the time you need to pay full for the licenses, I think you will gather enough experience on VSTS to decide either to stick with it, or rollback to pro.
It never hurts to have as many toys as possible in your toy box. Sure, you may only play with some of them once in a blue moon but the point is that you have them there to play with when you want to.
I run on a Mac so I have to run all of my stuff off of a VM, and I got to thinking that all I needed was VS installed and then I could use the underlying OS to handle all of my other functions (Dreamweaver, Photoshop, Office, Web Browsing) or in other words my general day to day computing life. Thanks to VMWare the transition between the VM and the host OS is easy, but you get attachments in your email that you want in you VM, or you work on a programming doc on the host os... the list goes on and on and on.
My point is this... you'll never regret putting more into your development system, you will regret not having that one tool that you wanted to have but just didn't think you'd need.
First, you should definitely use a version control product. Being able to go back in time and recall previous builds will save you tons of time and effort. Nothing worse than having it work one day, then realizing a change you made but can't remember broke everything.
Second, if it's just you (or even a couple of other people) you should probably go with subversion. Easy to setup, manage, and interact with is the name of the game here. Not to mention free, fully supported, reliable, and easy to learn.
I have recently started using VisualSVN Server and VisualSVN Client for Visual Studio. The server is free and the client is $45 for a license you can use on every one of your development machines. Add TortuousSVN and you can use the version control from the Windows shell.
I tried the TFS and VSS products from Microsoft and found subversive much easier to deal with.
If you are serious about unit testing your code (you should be) then I'd definitely recommend using the Development Edition, as it provides code coverage, which Professional Edition doesn't.
Sure, you can get most of the functionality difference between Professional & Development Edition from free/cheap 3rd party tools, but IMO these come at a price that is usually higher than what their tag says. Since you may use the even better Team Suite for 3 years I wouldn't even bother looking at the 3rd party tools.
I believe that the Team Developer Edition will now include the Database edition. This is probably all that you would require. From memory, the full Team Suite edition (Developer, Database, Architect and Test all together) is quite an expensive purchase.
One feature from team system which I like is the ability to profile the performance of your application. That might not merit an upgrade in itself if you have to pay for it, but it's very handy in some cases.
I agree with theBadDawg.
I thought it was a travesty when the unit testing features were only available in most expensive editions of Visual studio; unit testing is something everyone should have access to because it benefits us all by instilling good habits in us and helps us write far better software. Especially if we're new to the game.
Fortunately, it's now in the Pro edition.
If you can get the Team Suite and enjoy it's tools to be more productive and produce better quality software from it, do it.
I would agree with #Marc Gravell. You can probably approximate the value of Team System with add-ons, but you also need to factor in the cost of maintaining the add-ons as well. There is some pain associated with maintaining several third-party tools to get the functionality that you could get in an integrated package. Depending on who is spending the money (you or employer), the amount of pain you are willing to deal with to get all the functionality may differ.
I've been very happy with Team System, although I have added in TestDriven.Net as a test runner. We switched to this when TS came out with baked in unit testing, coverage analysis, and source code control. I'm very happy with the choice, but if I had had to pay for it personally, I probably would have gone with nUnit, nCover, SVN, etc. and kept the leftover money. I do feel that it has made me more productive, but I just wouldn't have had that much money to spend.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Is Microsoft Project the best tool for managing software development or IT projects or is there an alternative that is better?
Project is not good for managing development at all. I find it marginally useful for scheduling / work breakdown.
If you're on a Microsoft stack, Team Foundation Server is a good project management solution. It integrates with Project for scheduling and also provides the essentials of source control, work item (task / defect) tracking, and document management (via sharepoint.) The 2008 version has matured nicely, and the 2010 version looks very promising, especially in the area of requirements specification and traceability.
You can replicate the TFS features with a stack of open source and/or less expensive off-the-shelf software, but it is more work to integrate. It's debatable which is more flexible and easier to maintain once set up.
The following are required, regardless of platform:
Bug tracking
Work item / story / progress tracking of some kind (may be managed by above)
Collective team discussion (may be managed by above - discussion on work items, like FogBugz for example)
Source control (anything but SourceSafe)
Continuous build integration that runs unit tests
Instant messaging (OpenFire works great if your network blocks external services)
Document library
Farm of virtualized test machines (especially useful for install/upgrade testing)
I tend to use MSProject for capacity planning - a nice big broad brush of who could do what over a period, at a level of abstraction that makes it easy to rejig plans. For day to day tracking of the real work, I use Fogbugz. I think of it as MSProject/Gantty stuff for the strategic planning, and Fogbugz for the tactical management and planning.
Depends on the process you're using - if it's a waterfall like process, or there's a lot of non-software parts of the project (infrasstructure, manufacturing, marketing etc) then Project's OK for the overall task management - it's certainly competitive with other similar tools.
I don't think any of the "project management" tools (tasks, WBS, gannt charts etc) are much good at the management of the detailed tasks that happen when you're into the main software development phase - I usually end up in Excel for the projects I'm involved in.
And of course, there is much more to the successful management of a non-trivial software project than the bit that can be managed with a tool like Project. It doesn't help much with managing the requirements, issues, defects, meetings, test development etc - but then it's not supposed to.
Because of these limitations, I find I usually get most value out of Project in the planning phase - working out the task breakdown, what needs to be done, and roughly what needs to happen in what order.
As Eisenhower put it: "In preparing for battle I have always found that plans are useless, but planning is indispensable." MS Project is a useful tool for planning.
If also need a free and open alternative to Project, you have OpenProj: http://openproj.org/openproj
We use Target Process here. It has a few "-isms", but overall is a good agile project management tool
We've been successfully using MS Project for planning but were missing the ability to share MS Project plans with customers and colleagues who don't have it installed. This led us to the idea of online Microsoft Project viewer - a service that would allow to view and share MS Project files (.mpp) online, apart from MS Project:
Hope this helps.
We use Acunote at my work place, but we follow a Agile/Scrum methodology.
What constitutes the "best tool" depends on many things. How you run your projects, who will be using them, etc.
There are many better alternatives, at least for software development. One such is embedded in Microsoft Visual Studio Team System. You may also want to check out tools from Rally Software and Version One. The latter are well suited to agile methods, while the former supports both agile and traditional CMM methods.
Well, given the fact that not even the Project team uses Project for Project (Source: Joel Spolsky), I would not want to use it for development.
I track my development tasks in our Bug Tracker, and the Project File just has something like "Planning 1 Week, Development 5 Weeks, QA 3 Weeks, Deployment 1 Week", aka. a VERY broad overview.
As for the BugTracker, FogBugz has this nice Estimate-Tracking that I find quite useful for making schedules, which is for me just another reason to not use Project.
But then again, I am not a Project Manager, so to me, Project is just an unnecessary complex, not really multi-user friendly and somewhat dated-feeling Tool to be used when building Houses, Highways or Space Stations, but not for Software.
We use Primavera on my project. Its supposed to be great although its the only tool I haven't really used for project management so far so I can't really compare it to anything else. Its not that easy to pick up but it can do everything I need (and apparently much more).
My favourite feature is the built in timesheets functionality which means my developers can book their hours to their tasks at the end of the week meaning that I don't need to constantly bug them about how they are progressing against their plans.
personally i dont believe ms project is good for software dev (i have used it, im not bashing it to be a purist)
its great if you are building a house or something which doesnt have such uncontrollable variables (e.g. how many bugs will you have? how long will bugs take to fix? how much feature-creep will there be?)
i like to keep my schedules very simple so more people can understand them, hence why i just use a google spreadsheet
the structure i use is described further here: Project Schedules with Google Spreadsheets
hope this helps
--LM
Is anyone out there using Team Foundation Server within a team that is geographically distributed? We're in the UK, trying work with a team in Australia and we're finding it quite tough.
Our main two issues are:
Things are being checked out to us without us asking on a get latest.
Even when using a proxy, most thing take a while to happen.
Lots of really annoying little things like this are hardening our arteries, stopping us from delivering code and is frankly creating a user experience akin to pushing golden syrup up a sand dune.
Is anyone out there actually using TFS in this manner, on a daily basis with (relative) success?
If so, do you have any hints, tips, tricks or gotchas that would be worth knowing?
P.S. Upgrading to CruiseControl.NET is not an option.
Definitely upgrade to TFS 2008 and Visual Studio 2008, as it is the "v2" version of Team System in every way. Fixes lots of small and medium sized problems.
As for "things being randomly checked out" this is almost always due to Visual Studio deciding to edit files on your behalf. Try getting latest from the Team Explorer, with nothing open in Visual Studio, and see if that behavior persists. I bet it won't!
Multiple TFS servers is a bad idea. Make sure your proxy is configured correctly, as it caches repeated GETs. That said, TFS is a server connected model, so it'll always be a bit slower than true "offline" source control systems.
Also, if you could edit your question to contain more specific complaints or details, that would help -- right now it's awfully vague, so I can't answer very well.
We use TFS with a somewhat distributed team - they aren't too far away but connect via a slow and unreliable VPN.
For your first issue, get latest on checkout is not the default behaviour. (Here's an explanation) There is an add-in that will do it for you, though.
Here's the workflow that works for us:
Get latest
Build and verify nothing's broken
Work (changes pended)
Get latest again
Deal with merge conflicts
Build and verify nothing's broken
Check in
[edit] OK looks like you rephrased this part of the question. Yes, Jeff's right, VS decides to check some files out "for you," like sln and proj files. It also automatically checks out any source file that you edit (that's what you want though, right? although you can change that setting in tools > options > source control)
The proxy apparently takes a while to get ramped up (we don't use it) but once it has cached most of the tree it's supposed to be pretty quick. Can you do some monitoring and find the bottleneck(s)?
Anything else giving you trouble, other than get-latest-on-checkout and speed?
From my understanding you can have multiple TFS Application servers in different locations. They either can both talk to the same SQL Server or you could use SQL Server mirroring. Having your own local TFS server would likely speed up your development times.