Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Architecture Council/Top Ten Project Development Practices"
(→Integrate in small steps) |
(→Integrate in small steps) |
||
| Line 30: | Line 30: | ||
Integrate pieces in stages, don't make big giant change. Most processes can be broken down into smaller stages. | Integrate pieces in stages, don't make big giant change. Most processes can be broken down into smaller stages. | ||
| − | [[Category:Architecture Council | + | [[Category:Architecture Council]] |
Revision as of 11:07, 22 December 2008
Contents
Introduction
There are many ways to develop software. There is no one right solution for every project. However, over the years, there are some principles and practices that have been found to work well for eclipse projects. Particularly these principles have been found to work well with the Eclipse Development Process. For background reading, see also these agile project management presentations.
Community Practices
The following are recommendations on how to help your project grow it's user community.
Engage your user community
As outlined by the article, "Active User Involvement is Imperative", your project must actively engage your user community. This means blogging, responding to newsgroup questions, responding to inquiries on your mailing lists. Presenting at various eclipse related events. Most importantly, you should respond to bugs as soon as possible. The later is your most direct interface to your end users. A bug report is one of your first and best interfaces with your users. It sets the tone for how the rest of your project is viewed.
Software Development
The following are suggested practices that have been found to work well within the Eclipse Development Process, to meet the goals and criteria specified there.
Unit Test, Unit Test, Unit Test
Your project should incorporate unit testing into it's daily work flow. This means writing tests for every bug or feature. Some reasons for testing are outlined in "Agile Testing is Not for Dummies". If a test fails, it should be given the highest priority over anything else. Do not comment out failing tests, fix the test! Having a good suite of unit tests helps new committers, new contributors, and allows refactoring of the code with out changing functionality.
Tests should be automated and repeatable. They should not be environment dependent.
Continuous Integration
Synchronize with the repository daily. Eclipse projects have committers world wide, so code is always being changed. It's important to synchronize with the latest code, so that you have the same version as everyone else. This also helps eliminate failing unit tests as you catch items early instead of later.
Integrate in small steps
Integrate pieces in stages, don't make big giant change. Most processes can be broken down into smaller stages.