How to develop for Insight
(Process was agreed on. Also, backup_migrate is now available in all branches el5, el6, f15+.)
(Don't need draft notice anymore)
|Line 1:||Line 1:|
== What you need to know ==
== What you need to know ==
Revision as of 20:45, 10 May 2011
What you need to know
- We do not do any work on the staging or production servers that has not been tested and documented.
- We do not alter code directly on our staging server, or the production server. You can use a local sandbox to do experiments. Public tests are done on the development server.
- Our goal is to write as little custom code as possible for Insight. Wherever possible, we prefer to use community provided modules that are well tested and actively maintained.
- All code must be packaged before it goes on the development, staging, or production servers.
- Packaging ensures the site structure can be recreated in the event of a catastrophic failure.
- Packaging ensures other community members can benefit from our work.
- If you are helping develop the Insight platform, it is your responsibility to keep other team members updated on your work. You can do this through the mailing list and through tickets assigned to you.
How to make a change
Unfortunately, we don't have the ability to simply capture changes in a source code management system like git. So we must have some process to provide change in an orderly fashion. It's not orderly for everyone to simply make whatever changes they want without attention to our goals. At the same time, the process needs to be easy to follow and conducive to change.
Here is our change process:
- Make sure a ticket is filed in the fedora-infrastructure Trac to record the issue you're fixing or the desired enhancement. Whether you file the ticket, or take up an existing ticket, make sure you have assigned the ticket to yourself, and accepted it using the Trac interface.
- Test your proposed fix on your own sandbox, to make sure you know what you're changing, and that it works. The team can provide a copy of the production data if needed. (NOTE: This depends on the backup_migrate module.)
- Write down the steps needed for the change as a comment in the ticket you filed, so the team mailing list receives a notice.
- Try the steps in the development server, being careful to exactly follow the steps you wrote. If you find a discrepancy, update the ticket so it is accurate. No one will mind if you need to alter your steps! But it's important that we be able to track the correct series of changes you made.
- Add the keyword insight in the Trac ticket's Keywords field, so the change will be discussed at the next meeting.
- Once the team approves the change, it will be made on the staging and then production servers.
In this way, as a team we can look over and approve each other's changes to ensure we're constantly improving our service.