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.
Related
If taken from a developers perspective, what would my team and I gain from using Visual Studio Team System and Visual Studio Team Foundation Server?
I can see some features and the like, but what have you gained from using the two versus using VS Professional and SVN (for a weak example). If there are any good links that you know of, please feel free to post them.
Team suite will allow you to manage the entire lifecycle management in a unified framework.
It is very easy to bind your changes and source code to a build, work-items, create release notes, etc.
Well, lets talk 2010... ;)
You can not compare Prof + SVN with TFS and TS - reason is you msis out a LOT. The comparisong would have to include some other technologies toget on feature parity.
IMHO good points are:
Good source control (including stable server based storage, proxies for external subteams etc.). Not saying SVN sucks, but I dont like not having locking checkouts on times, and if you run a larger / distributed team, the proxy functionaltiy really pushes performance.
Automatded build / Continous integration (which is where CC.NET or TeamCity would come in). Unless you dont do that, plus unit testing etc. - you simply did not mention any solution for this, and in TS it is integrated, which I take as a big plus.
Gated checkin (check in only after build server ok's the changes - harder to break builds)
Bug tracking / work item tracking (not the best, but again - you need another product for that). I personally think it does a mediocre job there (Axosoft OnTime looks a lot better), but - well... it is integrated ;)
Data Dude - database change script generation and handling of database versioning. Again, this is a big problematic area otherwise - third "another piece of software needed" thing.
That is a decent start at least to show you that the comparison is a lot more complicated.
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 10 years ago.
Improve this question
What is a best way to organize many software development projects, interaction with clients, project documentation, sources, emails, knowledge, time tracking, issue and features tracking, support for releases and versions etc. for a small company?
For me (and I believe for many others) it is obvious that it must be some sort of web-based solutions. It would be great if it could provide an interface for iPhone (if not, it is also OK).
Important thing: it must be hosted on our servers, so PHP + MySQL is the best platform so far.
I have found the following system to consider:
http://www.activecollab.com/ (but I didn't found issue tracking as well as support for releases and versions, so it is not the best match for software development company)
http://www.mantisbt.org/ (Great tool, but no project planing...)
http://www.twproject.com/ (didn't try yet, but it has very strange interface)
But none of them is a 100% solution for me.
It also should (but not must) support SCRUM
We have about 25 people in our team and about 50 from client side. At once we run about 3-7 projects (some in dev. phase, some in support).
So, my questions: does anybody knows any good web-based system that gives everything software development company needs? I believe this information will be useful for many of us.
I would recommend FogBugz
They have a very interesting (admittedly not everyone's cup of tea) scheduling system and is apparently supporting scrum.
Their support for release management is something i'm particularly fond of, but i should also say that i have very little experience of other similar systems.
Another feature that I like is the ability to link different e-mail accounts as well as pure HTML forms to different projects.
Oh, and it is not a MySQL/PHP solution.
Some of the features are:
Issue tracking
Project planning
Scheduling
Customer support
Wiki
References:
Scrum and Fogbugz / Fogbugz questions / FogBugz Knowledge Exchange
I think it really depends on your company size. I used activecollab for a while but it never really convinced me and then they made it commercial anyway. There is an open source fork of it called ProjectPier.
Even if it is not MySQL + PHP but Ruby On Rails Redmine convinced me the most from all tools I tried (and installing the ruby module into apache is a question of 5 minutes). It is simpel and yet has anything I need (including Eclipse Mylyn, SCM integration, E-Mail Notification and time tracking). With a little RoR knowledge it is easily customizable, too.
The most popular Open Source sollution is probably Trac. It is written in Python, so it is not a PHP either.
But maybe it makes sense to consider a non PHP sollution. I didn't find any PHP open source tool that had the functionality and simplicity of Redmine or Trac. If you don't mind a hosted sollution Basecamp is probably the first address to turn to (never tried it though).
Trac with Agilo plugin might be a good option.
Here is link for Trac pluigns, some category are:
Code Documentation
User feedback and discussions
For another pespective - having used many of the above solutions, and liking them very much for bug tracking, wiki documentation and tracking information - I tend to move towards keeping much of my project "meta-data" (summary information pulling together wiki, bugs, schedules, communication) in spreadsheets now.
For those now climbing onto the top rope of the ring preparing for a takedown, here's why... I come from a programming background, and one of the best books I read early in my career was The Pragmatic Programmer. One of the tenets they preach is finding a fundamental editor that you like, and get good with it (for various Very Good Reasons). After trying (frustratingly) to port and adapt my PM/Dev Management approach multiple times to multiple systems, I've extrapolated that Pragmatic tooling philosophy to the product/project management world I now inhabit. To stretch the metaphor, my editor is now Excel.
I can't guarantee that for any company I work with, they have "Software Project Management xyz" or "Bug Tracking System abc" with the proper plugins - but I can be darn well sure they have Excel or some variant available. I know if I get ninja-like with that tool, I can continue to use it - and focus on the project, not the tools.
This spreadsheet approach comes with some caveats:
Excel done poorly can suck. We've all seen that. Watch for bloat and stupidity.
Keep the bugs in the bug tracking system, the wiki stuff in the wiki. The spreadsheet is meant to pull this stuff together, not replace it.
Keep it readable. Don't stuff everything in just because you can. Summary sheets are good.
Try to standardize your templates and macros meaningfully for tasks and information, to maximize reuse over time and projects. Just like good programming.
Back it up - use a document management system if you can. This approach isn't in the cloud or hosted centrally by default, so be aware of that.
Have you tried Assembla? They've recently released a new product called Portfolio which is great if you have to manage multiple projects + you get free clients! :)
You might like to consider http://targetprocess.com/ We use that in my current job and it works pretty well, from a developer point of view. I'm unsure as to whether it supports your installation requirements, however.
Microsoft has recently put a release of their Code Contracts framework on DevLabs with a commercial license. We're interested on using them in our project (mostly C#, some C++/CLI) to gradually replace all the custom validation code, but I'm keen to know about the experience other people have had with it before we commit to it, specifically:
Do you think the framework is sufficiently mature for large and complex commercial projects?
What problems have you run into while using it?
What benefits have you got from it?
Is it currently more pain than it's worth?
I realise that this is a somewhat subjective question as it requires opinion, but given that this framework is a very significant part of .NET 4.0 and will (potentially) change the way we all write validation code, I hope that this question will be left open to gather experience on the subject to help me make a decision to a specific, answerable question:
Should we be starting to use it next month?
Note that we do not ship a code API, only a web service one, so for the majority of code breaking compatibility in terms of the exception type thrown is not a concern. However, as I'm hoping more people than just me will benefit from this post and its answers, any detail around this area is more than welcome.
The last mature response to this was in 2009, and .NET 4 is out. I figure we're due for an update:
Code Contracts might well be mature enough for your Debug releases.
I realise this is somewhat of an upgrade from “Harmless” to “Mostly Harmless”.
The Code Contracts home page links to quite thorough documentation in PDF format. The documentation outlines usage guidelines in section 5. To summarize, you can pick how brave you feel about the Contract Tools re-writing your IL in your Release builds.
We're using the “don't rewrite my Release IL” mode.
So far, I'm most enjoying this unexpected benefit: there's less code, thus less code to test. All your guard clauses melt away.
if(arg != null) {
throw new ArgumentNullException("arg");
}
// Blank line here insisted upon by StyleCop
becomes:
Contract.Requires(arg != null);
Your functions are shorter. Your intent is clearer. And, you no longer have to write a test named ArgumentShouldNotBeNull just to reach 100% coverage.
So far, I've run into two problems:
I had a unit test which relied on a contract failure to succeed. You might argue the existence of the test was a blunder, but I wanted to document this particular prohibition in the form of a test. The test failed on my build server because I didn't have the tools installed. Solution: install the tools.
We're using two tools that rewrite IL: Code Contracts and PostSharp. They didn't get along too well. PostSharp's 2.0.8.1283 fixed the problem. I'd cautiously evaluate how any two IL-rewriting tools get along, though.
So far, the benefits are outweighing the hazards.
Addressing out-of-date concerns raised in other answers:
Code Contracts's documentation is quite thorough, though regrettably in PDF.
There's at least one Code Contract forum hosted by Microsoft.
Code Contracts Standard Edition is free if you have any VS2010 license.
.NET 4 is out. I've run into Microsoft's contracts when implementing generic collection interfaces.
I've been playing around with the code contracts some more myself on a small but moderately complex standalone project, which needs to inherit from some BCL classes and use other ones.
The contracts thing seems great when you're working in a completely isolated environment with just your own code and primitive types, but as soon as you start using BCL classes (which until .NET 4.0 do not have their own contracts) the verifier cannot check whether they will violate any of the requires/ensures/invariants and so you get a lot of warnings about potentially unsatisfied constraints.
On the other hand, it does find some invalid or potentially unsatisfied constraints which could be real bugs. But it's very hard to find these because there is so much noise that it's hard to find out which ones you can fix. It's possible to suppress the warnings from the BCL classes by using the assume mechanism, but this is somewhat self-defeating as these classes will have contracts in the future and assumptions will lessen their worth.
So my feeling is that for now, because in 3.5 we're trying to build on a framework that the verifier does not sufficiently understand, that it's probably worth waiting for 4.0.
Judging by this thread I would say it is not quite mature enough to use for an enterprise level project. I haven't used it myself, but people are still running into bugs that would bring your contract-critical project to a halt. It seems like a really great framework and the example videos they've provided have been exciting, but I'd wait for:
Existence of a community forum. You're going to want to be able to discuss inevitable problems you run into with other developers, and you want to know there is a decently strong base of developers out there to discuss solutions with.
A successful pilot project release. Generally, when Microsoft Research releases something that they think is mature enough to be used in a commercial project, they will work with an organization to pilot it, and then release that project open source to as a proof of concept and trial-by-fire of all of the major features. This would give a lot of confidence that most of the common contract scenarios are covered and working.
More complete documentation. Plain and simple, at some point you're going to want to do something with contracts that you can't do yet using Microsoft Code Contracts. You want to be able to quickly and clearly reason that your scenario is not yet supported. The current documentation is going to keep you guessing and trying different things, though, in my opinion, which will result in a lot of wasted time.
It's not mature enough.
It will be as soon as Microsoft releases it with the affordable editions of VS, but without the static code analysis it's not usable at all.
The editions of VS, that have it, are so insanely expensive that only a handful of people will ever be able to afford it.
It's a shame Microsoft killed this amazing idea with their pricing policy. I wish Code Contracts would become mainstream, but they won't.
Epic fail.
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