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.
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.
No comments:
Post a Comment