There are no comments yet...Kick things off by filling out the form below.
How Often Do You Check in?
One of the common parts or even the common part of the software teamwork on a source control is developer check-ins to add new code to the source control.
It's always been an interest for me to see how often other developers check their codes in and what are their rules for doing this.
Although there are some automated ways to manage check-in to some extent but there is almost no way to force all developers in a team to follow same method.
Leading and contributing to several small and big projects I believed that having a constant way for check-ins can help the productivity of a team and its management very much. So I decided to think and work more on this subject and find some results to apply them to my own projects.
There are some common methods that developers follow to check their new codes in. Some developers use one of them and some other developers use a combination of multiple methods. Here is an outline of these common methods:
- Reaching to a specified amount of new code. For example, some developers check their codes in when they reach to something around 500 lines of new code. The measurement of the amount of code can be different per project.
- Reaching to a specified stage in the project. Usually a project consists of several minor and major stages and components and some developers prefer to keep their code local until they finish their work on a stage. This of course depends on the team management and developer roles. If multiple developers are working on a component this isn't possible.
- Closing a work item. Some developers check new code in whenever they close a work item by writing new code whether it's a bug, a task or a new feature and addition.
- Having a stable build. The other common way for check-ins is adding new code to source control whenever the whole project is in a stable stage and can be built without errors. This can let other developers on a team to check out the code and add other portions of code without worrying about errors that arise from the work that others have done.
These are what I've seen that are common among developers. But usually developers try to use a combination of these ways and it's a kind of habit for them rather than a team-based method. In other words, a developer follows a constant habit in several projects and doesn't change it per project.
The other point is about pros and cons of each method. Obviously these methods have their own pros and cons. For instance, the last method is good but what will happen if it takes a long time to have a stable build? Other team members may want to get their hands on the code to work with it or leave their comments to improve it. Team leader may want to see the status to control the project from going wrong.
Logically using a combination of these methods can reduce the negative points for each of them. If a developer uses a combination of the last method with the second or third methods then some of the abovementioned difficulties can be solved.
I personally use a combination of first, third and fourth methods. I don't care much about the stages in a project but after passing a reasonable amount of new code and finishing my work on a work item, I try to check-in a stable build to the source control. This has worked very well for myself and my teams and I never faced with any problem around this.
The last point about check-ins is the time between your check-ins. Regardless of your method for check-ins it's better to add something new to the source control on a regular basis. This helps the progress and activity on a team especially if it's a small team and more especially if it's an open source team. I've seen some developers that are working on something smoothly but don't add their code to the source control and for others it seems that no work is in progress for them. In my own opinion in teamwork progress and activity is something more important than many other stuff.
Searching for resources about this main part of software teamwork, I couldn't find anything to refer to it here. I think it would be valuable to have a good documented resource about most appropriate methods of new code check-ins in software projects. In general, I don't know an excellent resource (online or offline) about software teamwork and its best practices. If you know any, that would be great to drop a line and let me (and probably others) know.
[advertisement] Axosoft OnTime 2008 is four developer tools in one: bug tracking, project wiki, feature management, and help desk. It manages your development process so developers can focus on coding. Installed or Hosted – Free Single-user license -- Free 30-day team trial.
No Comments : 02.28.08