Procedure of modifying project code

Why to define procedure

As a company, we have to deliver constant quality of our work. Also, to be efficient, it should be easy, for any new team member, to quickly get into project details, modify the failed placed of code, fix bug, and publish changes. The procedure below, describes how to do that the way that you don't break the install.

The main advantage of using common procedure within the company - anyone can make a modification, update his own version of project code, update production version of code: all without asking external help from main project maintainer.

Rules to follow

  • Test the code before & after modifications were made
  • Provide clear information on what, where and why were modified
  • Supply SQL and other data transformation scripts along with your modifications
  • If your code is not complete and final solution, use new branch
  • If you encounter some problem which you can not solve, reassign bug(task) to a perspective owner

More on each rule will be said below.

Test code before & after modifications were made

It is found to be more effective, when bugs are fixed by a person which actually invented them. But spotting those bugs in time is a task of testing, either manual or automated.

Normally, during project development and later, we maintain automated project tests, so we are assured that central functionality, covered by tests, is not broke by recent changes. If tests are not working, the work can not be continued until either code or tests are fixed. That makes it easy to solve problems immediately, by the same person, which made the mistake. Solving same problem by external person which suddenly finds a bug, would be a lot more difficult.

Every our project comes with tests in one, or several forms. It can be Django internal tests, running with manage.py test or FunkLoad or Selenium tests. All external tests are usually situated in 'djw/custom/tests' subdirectory for DjWarehouse based projects, and directly in 'tests' subdirectory for other projects.

Provide clear information on what, where and why were modified

Correctly documented change means that:

  • You can relate your task with Subversion code changes (changesets). This automatically answers question who made changes, when, and which lines & files were modified.
  • If looking from a subversion perspective, looking into every changeset, there must be URL/link to bug tracking system linking to bug/task requesting the change

So, it can be tracked both directions - see which bugs are realted to change, or see which changes are related to every bug. This also makes it easy to find out who, when and why did every single line change, who requested the change.

Normally, it allowed to post direct links between Bugzilla and Timeline views. So, actually, there are 2 rules to follow:

  • When doing SVN commit: Post Bugzilla bug/task URL explaining which work were done (shortly) and that full description can be found at [bugzilla url]
  • When adding comment to Bugzilla: post all links to URLs of Trac or other subversion browser Timeline view.

Supply SQL and other data transformation scripts along with your modifications

If data model is changed, we usually use per-project trac Wiki page named SQLUpgrade where the following is listed: date, revision, branch (optional), and SQL to transfer old data to new form. If SQL can not solve the problem, Python script must be created and placed into project 'bin' directory.

If your code is not complete and final solution, use new branch

Suppose you've started to work on project which originally should take a few hours, but found that it would take more. You should always save your changes to subversion from time to time, from reasons of having backup & having a consistent improvements. But if this code would break production or other development versions, please create a branch, and work with it until code is completely done, tested & ready for production use.

If you encounter some problem which you can not solve, reassign bug(task) to a perspective owner

That is explained in a more detail at Halogen bugzilla guide. The main point, is that bugs should not be stuck on a person, which can not provide any progress on them.

Comments: 0

No comments.

Post a comment

Guests can\'t leave comments.