I'd like to know if anybody can give me an idea how to keep track of delivered software version(s) to a customer or maybe tell me how others do this?
Say I have a couple of different software binaries each with it's own release versions. Different customers got delivered different versions - for whatever reason. Later on I'd like to know which customer is running which binaries and which versions.
Of course there maybe an approach to simply drop the information into an excel sheet or something like this. But this all depends on the person delivering the software to the customer to keep track of this information.
Ideally I would like to integrate this information into the release/delivery workflow.
We already use a bug tracking system - in our case redmine - but I personally didn't find a working solution which can be combined with the bug tracker. The bug tracking integration is not a requirement. If there is any software based system as described I would prefer a web based system.
Well, since you mentioned Redmine, here is a workflow that I would use
I would create branches for per-client versions of software on SVN or git I'll assume you use some source code version control system, and a project for each user as a child project in Redmine of some software product, for example with svn:
Accounting software (holds main branch /svn/trunk)
|- Client Bobo (holds /svn/accounting/branches/bobo)
|- Client Koko (holds /svn/accounting/branches/koko)
CRM software (/svn/crm/trunk)
|- Client Kiki (/svn/crm/branches/kiki)
|- Client Dudu (/svn/crm/branches/dudu)
|- etc...
This way I would be also able to track bugs on per-client basis, and even be able to have ISSUE-CODE relationship between bugs and particular issues for a particular client!
Best luck! Hope that my answer was helpful!
Related
Our group integrates a bunch of different sub-blocks into our main project and we are trying to determine the best way to manage all of these different pieces of intellectual property. (From here on out I will refer to these sub-projects as pieces of IP "Intellectual Property").
The IP will be a mixture of third party vendor IP, previous projects IP and new to this project IP. Here are some of the ideas we are considering for managing all the different pieces of IP:
Publish releases on a physical drive and have the main project point to the correct releases.
PROS - Little to no dependencies on the SCM: seems simpler to manage initially:
CONS - Must remember to keep each physical design center up to date:
Use Perforce client spec views to include the correct version.
PROS - Able to quickly see what IPs are being used in the client spec:
CONS - With a lot of IPs the client spec becomes very messy and hard to manage: each team member manages there own client spec (inconsistencies): the very thing determining which IP version to use is not under SCM (by default):
Integrate the the different releases into a single one line client view.
PROS - Makes client spec maintenance dead simple: any change to the IP version is easly observable with the standard Perforce tools:
CONS - Not as easy to see what versions of IP we are using:
Our manager prefers #2 because it is easiest for him to look at a client spec and know all the IPs we are using and the versions. The worker bees tend to strongly dislike this one as it means we have to try and keep everyones individual client specs up to date and is not under SCM of the project itself.
How do others handle IP within a Perforce project and what recommendations do you have?
UPDATE:
I am really leaning towards solution #3, it just seems so much cleaner and easier to maintain. If any one can think of why #3 is not a good idea please let me know.
I would go for the third solution too.
I can't think of any downsides, and have not experienced any when faced with similar situations in the past.
You could placate your manager by using a branch spec that clearly spells out which IP versions are branched in. He could then refer to that branch spec instead of a client spec.
Also if you look up 'spec depots' in the help, you can set Perforce up so that it version controls all specs, including branch specs, automatically, which will give you traceability if you alter IP versions.
"each team member manages there own client spec (inconsistencies)"
Don't do that. Have the client spec be a file that is checked in to Perforce.
I would suggest #2 as it is the most transparent system. Yes it will mean some more work keeping clients up to date, but you can minimize that issue by using template clients.
At my work we use template clients that the devs copy from to keep their clients properly configured. We name this with the pattern "0-PRODUCT-BRANCH" (and sometimes add platform if needed). Then it is a one line command from the command line, or a couple clicks from the GUI to update your client. I send notices to the team whenever the template changes.
Now in my case, template changes don't happen very often. There is maybe a max of 5-6 per year, so the hassle level may be different for you.
At the moment support requests / bug reports made by customers are coming in by mail. It is getting harder to organize priorities and stay at the helm of all this. So I am looking for bugtracking(?) tools. Not all reports are bugs of course, sometimes it's just feature request or support requests.
So my question is: whicht open source bugtracker / support request handling tool do you recommend? I know Mantis which seems to be my front runner for a more elaborate evaluation, but I already worked with it (as a reporter / contributor) and found the GUI a little cumbersome. Another issue is that I thought about using the tool for multiple website projects of different customers.
Intuitively I would prefer to run only one instance of the tool for all projects to have a better overview of all critical issues (independently of the project). Of course customer A should not be able to see customer Bs request (but every customer can have multiple reporting accounts) Is Mantis able to handle that? Can you recommend any other alternatives?
P.S.: I heard about Jira, but I will try to find a free tool for my first try.
It's possible to use email with Mantis, so that you can get incoming email (directly or by forwarding) to Mantis.
Then you can have a workflow in Mantis, f.ex. have an incoming project and customer projects, and you can send email with bcc Mantis and subject containing issue number (I use [1234] as a pattern).
I haven't used other issue trackers as much, but my experience with a customized Mantis is good regarding different kinds of issues and using with email.
Since you're turned to Open source, I'd say install a project management platform like Launchpad, redmine... etc and then create a project for each of your clients (of course you can have multiple accounts for only one client). The bug tracker in these platforms can serve as a support request service.
I'd go for Launchpad because it also has the Q/A feature and blueprints, and is also nice looking and very very user-friendly. And also damn easy to install on a Ubuntu Server.
Kind regards
A friend of mine and I are developing a web server for system administration in perl, similar to webmin. We have a setup a linux box with the current version of the server working, along with other open source web products like webmail, calendar, inventory management system and more.
Currently, the code is not under revision control and we're just doing periodic snapshots.
We would like to put the code under revision control.
My question is what will be a good way to set this up and software solution to use:
One solution i can think of is to set up the root of the project which is currently on the linux box to be the root of the repository a well. And we will check out the code on our personal machines, work on it, commit and test the result.
Any other ideas, approaches?
Thanks a lot,
Spasski
Version Control with Subversion covers many fundamental version control concepts in addition to being the authority on Subversion itself. If you read the first chapter, you might get a good idea on how to set things up.
In your case, it sounds like you're making the actual development on the live system. This doesn't really matter as far as a version control system is concerned. In your case, you can still use Subversion for:
Committing as a means of backing up your code and updating your repository with working changes. Make a habit of committing after testing, so there are as few broken commits as possible.
Tagging as a means of keeping track of what you do. When you've added a feature, make a tag. This way you can easily revert to "before we implemented X" if necessary.
Branching to developt larger chunks of changes. If a feature takes several days to develop, you might want to commit during development, but not to the trunk, since you are then committing something that is only half finished. In this case, you should commit to a branch.
Where you create a repository doesn't really matter, but you should only place working copies where they are actually usable. In your case, it sounds like the live server is the only such place.
For a more light-weight solution, with less overhead, where any folder anywhere can be a repository, you might want to use Bazaar instead. Bazaar is a more flexible version control system than Subversion, and might suit your needs better. With Bazaar, you could make a repository of your live system instead of setting up a repository somewhere else, but still follow the 3 guidelines above.
How many webapp instances can you run?
You shouldn't commit untested code, or make commits from a machine that can't run your code. Though you can push to backup clones if you like.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I have a team of developers distributed Globally over different time zones.
what are the best tools to achieve maximum productivity in such a team?
I am looking for:
Source Control
Bug Tracking
Build Management
Any other thing that may help
Thanks
For the first two:
Distributed source control, like git
A good issue tracking tool, like Jira
This question is underspecified. Many packages exist for each category that you list, all designed to support collaboration across people distributed globally over different time zones.
So I can make a recommendation, based on open-source tools that have worked for me in the past. You may have specific needs that require more specific solutions, but you didn't mention them. Also, for productivity, it is useful if people can continue to use tools they are familiar with, and you didn't explain what tools your people already know.
In any case, here is my recommendation:
use Subversion for source control
use Roundup as the bug tracker
use make for the build management, use Buildbot for automated, distributed builds
use mailing lists, based on Mailman
For .NET environment:
SVN server: VisualSVN server (free)
SVN client: AnkhSVN 2.0 (open-source)
Continuous Integration: CruiseControl.Net (open-source)
Bug tracker: BugTracker.NET (open-source). But if you can, i would recommend Trac.
I am very satisfied with Assembla - they host SVN server and Trac for your projects for very reasonable prices (or for free if the oproject is public).
Consider Fogbugz for bug tracking. It's helpful.
As source control: why not a distributed system, like git (if you are not using Windows), Mercurial or Bazaar?
For bug tracking, I would go on Trac - it has also an integrated Wiki, that is always useful for project documentation.
As for build management, you could go on cruise control, or ant - I am not really expert on this side.
However, there is something you should really take into consideration: the main issue for distributed teams is not the toolset, is communication.
This is even more important in an "agile" setup, as suggested by your tag.
The best mitigation I have ever seen for this issue is videoconferencing. It is very effective for enhancing communication bandwidth in distributed teams, and with GTalk and Skype is now really inexpensive.
When you say "open source" do you just mean free software, or do you mean "I need/prefer to be able to see the source"?
Note that your decision will be influenced by the nature of your project. There are many free development/project hosting sites that require that your project must be an open source project and free/open to the public.
You may also choose to go with a particular hosting platform based on the language you are using to develop the project. For example, CodePlex (http://www.codeplex.com/) is a site that hosts open source .Net based projects, and Java.Net (http://community.java.net/projects/) hosts Java projects.
The other answers given to your question are solid, here is what I currently use or have used in the past:
A great continuous build tool JetBrains TeamCity. (http://www.jetbrains.com/teamcity/) The tool has out of the box support for many build tools as well as for building Visual Studio solutions out of the box. It is free for teams of 20 or less developers. It also has loads of functionality out of the box, and can be up and running for you in minutes - a remarkably low learning curve without cutting back on features.
A useful SVN repository which is free for two developers, and will save you the time of setting up and administering your own SVN repository is Unfuddle. (http://www.unfuddle.com) Unfuddle also has extra paid-for features and basic task tracking.
Another paid source repository is ProjectLocker (http://www.projectlocker.com) which has low priced SVN repositories and Trac integration for task management.
A useful task tracking tool is Remember The Milk (http://www.rememberthemilk.com) - it does not work on "tickets" like Trac, it is not only for tracking projects, but it does allow you to email each other tasks, and to have shared task lists. I also point them out because the product itself is developed by a distributed development team and you might want to try mail them for advice. :-)
All the best to your team!
A wiki is a must.
It helps as an asynchronous communication media between ans inside the teams. People can share their tips (eg how do I compile this, how to activate traces ... ). It can be used to gather design decisions or changes...
People can ask questions to the whole team without clobbering other mailboxes.
It can also be used to grow the documentation.
There is a gazillion of wiki's, pick one depending on what you plan to do with it.
I think you'll need a few more things to help out with this project than what you've asked.
First, I'll give my recommendations for your list:
Source control: git or svn, if yu use either of these, you'll need a way to let your developers know who checked in what and when, Trac is good for this for svn
Bug tracking: Trac (not Bugzilla), Mantis, FogBuz
Build Management: CruiseControl is great for continuous integration; if you need build scripts try Ant or Maven
Other things you will probably need:
Collaboration tool: Trac has a wiki or pick a wiki of your choice
Chat tools: Even though they are across timezones, instant communication will be needed. IRC, Jabber, Skype, which is great for video or audio calls over the internet.
Project management: you'll need a way to setup your releases (sprints if using Scrum) and your backlog. My favorite tool for this is Acunote: (http://www.acunote.com). There are some other out there but they are more expensive and you get all of the features that you probable don't need.
I hope this helps.
Yes I strongly believe that in distributed teams a tool is important. Communication is hard enough if you are not working locally together. A tool like e.g Agilo for Scrum that is based on trac offers you with a wiki, a planning board (online whiteboard) and supports you in this way to improve the communication with your colleagues.
My company is a custom development shop for a number of projects, some larger and some smaller. Currently we handle all of our client communication through email. So we email a design doc, they mark it up and send it back. Then we roll out a beta version of their product and they email us with any bugs, new features, etc. And so on....
As I am working on implementing a new bug tracking system (it looks like it will be Mantis right now), I got to wondering how we could best allow our customers an interface with our development process that would provide better tracking of feature requests and client submitted bugs as well as communicate our responses back to the client.
If anyone is aware of a a bug tracking system that does this exceptionally well I'd be interested to hear of that. Otherwise I'm just looking for some general guidelines or good business practices that have allowed your companies to interface effectively and efficiently with your clients.
UPDATE: My company uses a LAMPP stack and as we are a small shop with a limited budget we tend to stick to tools that are open-source and free.
Do most people either use Team Foundation Server to handle this or emails back and forth?
I think the key is to have the dedicated tracking system there for bugs/requests, and to establish a set process for communication. With that at minimum you will start getting consistent feedback. From there you can tweak it to get your specific needs.
As an aside, rather than just using e-mail for your communication, I strongly recommend going to smething like BaseCamp for a project management tool. I find that it helps greatly with keeping messages, documentation, and timelines communicated to the client.
If you are using Team Foundation Server, I recommend you to install TeamPlain Web Access. They allow you to expose a web interface to your TFS project. The only things left to do, is give rights to your client and a username and a password.
Otherwise, there is some paying tools like FogBugz. Of course, the principal is having to bug reporting tools directly linked to your Source Control so that the developers can easily fix bugs.
Although I know of no specific tools (at least no open source ones), I suggest that you setup a system which will cover your overall requirements gathering and implementation process. Requirements could be tracked in the system, which would also contain the design documents (which could be "checked out from" and "committed to" the system). This way, you would tackle the problem of having multiple revisions of design documents around. Addionally, the design documents and the requirements could be tracked easily. If this system were linked to your source code management system, you would additionally ease your development process/requirements tracking.
Another possibility is to use two products in concert, here's our current setup with a team of 12:
osTicket for incoming requests from clients
Allows for issues to be handled by support staff and bugs to be verified
Status can be checked with just an email address and ticket ID
Typically users don't submit detailed enough bug reports so is a good first step
redmine for development tickets
Ticket created by QA or a developer if issue is a real bug
Provides solid enough project and release management
Is a solid step up from trac and mantis (and provides migration tools)