Project management with Jira, CVS, Xplanner, wikis

project Management with Jira, CVS, Xplanner, wikis

JIRA, a very good issue tracking system, here issue not only refers to bugs, often can also be task, improvement, NEW FEATURE, even a question. Many years ago, I tried to use the classic Bugzilla, but a project came down and everyone reflected that the interface of that thing was too rough to tolerate and the report function was too weak. Finally, everyone discussed their own bug tracking system, just as we have completed the design document preparation code, we found that Jira is what we are looking for, and more than we want. It is built into a configurable workflow engine (Osworkflow), a fast full-text search function (based on Apache Lucene). And a configurable dashboard (portlet), as well as a CVS-connected engine, through this connection, In a issue can directly see the modified file name, if configured Viewcvs, but also directly to the line, according to a problem can be traced to the line of code, which we dream of the function of a dream. It is this feature that makes it possible for us to consider one issue as a unit of release and version management.

CVS, this should be known to everyone. In the process of system development, all the source code and design documents should be entered into the version management system to manage, sometimes the resource pool may be bloated, but the cost is worthwhile.

Xplanner, in the whole management system, progress management has been a 䒈 relatively weak link, I have tried dotproject such management software, but because Dotproject management too detailed, fill up too complex, we gradually lost the enthusiasm to fill. This Xplanner software can be much simpler. You specify an iteration, story, and then you can fill in the progress. As this software is also opensource, so if you feel dissatisfied, modify it is also very convenient, now Lim on this system has made some improvements, can be directly connected to the Jira system, Jira in the establishment of issue, can be reflected in the Xplaner, even fill in Story time is omitted, and then a detailed report can be produced before work, listing the processing time and progress of each person in the issue in charge of the day.

Wiki, which we've been using as a document management and Portlet system in Project management, has now become our team's platform, where we have all the design documents, including system development design specifications, and dozens of regular howto projects in the wiki, Examples include how to quota a standard development environment, how to use CVS clients, how to use Jira, and your own JavaDoc, JSDoc, and so on. We can also use wikis to simply integrate the system, and in the wiki we list all the development environments and the portals of the development tools, such as the connection to Jira,xplanner and our project, and even to There is no one to record these URLs in the common use of Project Javadoc in Apache, as long as all the resources on the wiki are open, and because the wiki itself is open, the members of each team are a maintainer and a beneficiary of the system. What's often happening in many teams is that a kid is very good at a technology, everybody encounters this question to ask him, in the small team, face-to-face communication is usually the quickest communication way, but puts in the big team, this is not feasible, that kid sooner or later will be asked the vexed to vomit blood to, Especially when his own work is not finished on time. Take one hours to write it, put it in the wiki, don't ask me, check out the wiki yourself.

Post management based on issue.

From a version management perspective, the ideal way to publish is to take the code in CVS and tag it, compile it, and test it until it's released. This kind of management is really very simple, but in fact the user can not buy the account, the user feels he doesn't want a new feature in the new version, which may be that he hasn't sorted out the initial data for the business or is not ready for the actual business process or people, and God says that we can't release the new feature. In this case, the release management based on issue is a good solution.

The issue here is a issue in the front Jira system. Typically, the completion of each issue will be accompanied by some modification of this code. Based on issue's release, it is simple to publish a group of issue changed files into a formal system in the form of patch.

Based on the premise of issue release is to establish a connection between issue and source, so that the publisher clearly know what each issue modified source code is. The easiest way to do this is to add the Jira number when submitting source, and no Jira number code is not submitted. This has the following advantages.
1 prevent some inexperienced programmers from committing without meaning, for example, a kid today submitted a Java file, tomorrow found that the variable naming a bit uncomfortable, after the change will be submitted, in this case, this submission is meaningless, if the test group has tested this issue, whether the test group to be tested again. To name a variable such time and adventure is tender. The young man was still submitting the variable name when he first submitted it.

2 Programmers secretly modify the code, a young man found himself has been closed issue has a bug, then secretly modify the code. This is certainly not possible, usually submitted to CVS in the code is not their own, that is everyone, there is not enough reason to change of course not so easy. First set up a issue, report to team leader, and then modify the code.