Emergency defect fixing: Giving local fixes for quick verification

During the process of defect fixing and verification, there is a standard process whereby a build process is created and defect fixes checked into this build. What this does is to ensure that every day (the builds typically come every day) the defects which were fixed the previous day are available for testing in a proper installer which can be used by the testing team similar to the product that is available to the customer.
This process works pretty well, as long as everybody involved knows the process well, and there are people in the process who have responsibilities for the different parts of the process (for example, somebody who ensures that the build stability systems are in place, others who do a quick smoke testing to ensure that the build is usable), and so on.
However, such a system cannot protect against a case where a defect has not been fixed, either fully, or partially. In the normal case of operations, it is normal to have defects that are not fixed and are rejected by the testing team, or some part of the defect not being fixed well, and a new defect being filed for the same.
When does this process not work ? Consider the case where the product development process is nearing the end of the schedule. In such a case, the defects that are to be fixed are restricted, and only those defects that are being allocated for fixing are passed onto the development team and the list given to the testing team for verification. However, the cost of a failed defect fix can be fairly high.
A defect fix that has failed would mean that the build for that day is not ready for use, and this can be very expensive.
When such parts of the schedules have been reached, there is the need for much closer interaction between the specific developer and the tester(s) for that defect fix. When the developer has made the fix, he/she would work with the tester and provide the fix in a local build, made on the developer's machine, which could be quickly tested by the tester to ensure that the fix has been made to the satisfaction of both the developer and the tester. This goes a long way to help that the build that comes the next day is usable and important fixes are not failing.
There are some problems that can still happen in this process. The local build may not be incorporating changes made by the other developers, and this can cause a dependency problem that may still cause the defect fix to fail. However, the chance of this happening is low (or can be monitored by the developer to reduce the failure rate) and goes a long way to ensure that the development process has reduced risk near the end of the cycle.
However, this requires close collaboration between the tester and the developer, and is not really required to be done in the regular part of the development cycle, since there is an overhead involved in the process.

Ensuring a regular email with changelist information ..

The daily build is a pretty important item for a development team. There is a need to have a new build of the software on a daily basis, so that defect fixes and code changes make ti to the testing team as quickly as possible. If the build gets delayed for any reason, it means that the development team will have to wait to get these fixes. These delays cause a delay in the actual schedule, and hence most teams have a schedule whereby they get a build early in the morning before the team members have arrived, and also because this means that everything that has been done in the previous day will be available in this build.
However, just because you need a build every day does not mean that you will get it. The process goes that all the changes done in the previous day are all checked in the source safe that the team uses, and based on the last checkin (typically at the cut off time decided between the development team and the build team), the build is fired and takes the required amount of time to process and become a build that is available to the team in time before they come in the next morning.
However, there are a number of things that can go wrong. One of these items relates to whether a checkin done by a developer near to the cutoff time has been incorporated in the build. At near milestone times, there will be a lot of discussion between the development team and the build team to be sure about the actual checkin that is used as the last checkin on which the build has been fired, but on a regular basis, such kind of discussions do not happen. And it is not only the last checkin that can cause a problem, there are other components that go into the application which need to be included in the build and become part of the application. However, all of these are engineering tasks, and sometimes the configuration can go wrong, or the build number that is picked up for one of the components could be wrong (we had a tough case once where a particular functionality was not working as desired, and we found that there was a problem in the execution of a script, which was getting affected due to one of the latest patches, and hence it was picking up the previous version of a component - this was painful to find and diagnose). The other case was when somebody made a great big checkin, but it did not make it into the build while the testing team was under the impression that it was there in the build and start to find issues.
As a result of all these cases, one of the solutions that we had come up with was about ensuring that the build script would also number of the last checkin, and also capture the latest version numbers of all the components that go into the system, and make this available along with the build. Since we also had defect fixes in the defect management system marked with the checkin number, the testing team was easily able to figure out whether the defect fix that they were waiting for made the current build, or came in too late and would only be available in the next build. At times, especially near milestones, the team could even request a new build with this latest checkin to ensure that the feature or defect that they had been waiting for was available to them. Similarly, the version numbers of the components made it very easy to determine whether the component list that was there in the product was the latest.