Versions
Perhaps one of the necessary evils of software releases is that it introduces versions of shipped software. Customers generally take their own time to upgrade their copy of the software and at any point of time, different customers may have different versions of the software from the maker. Therefore, a Sustaining engineer is sure to find that a defect appearing in an old version may also manifest in other versions. Consequently, a fix applicable to a defect in a version may also be needed to be ported in other versions. When the fix is made to the current software and applied retroactively as a patch to former releases, it is called backporting a fix. Likewise, a fix made as a patch to a shipped software may need to be made to the current development pipeline so that the defect does not reappear in future releases.
Determining the software versions where the defect occurs, finding a suitable fix without side-effects and safe for those releases and propagating the fixes forward and backwards through versions constitute one of the main tasks of the sustaining engineering team. A large part of this effort involves side by side or sequential installation, testing and validation of fixes and take up a lot of time. Yet there are no tools to facilitate these chores for the Sustaining Engineer. One tool that comes very handy to track these fixes is source code version control systems such as git where branching and versioning strategy helps the engineers to label the fixes so that they can be tracked across releases and repeatedly applied to more than one versions.
Let us say there are two previous versions of software releases in addition to the current source code version that is in active development for future releases. A fix made to the current version may also need to be made to the earlier versions and vice versa. Yet there is no automation of bringing in the fix to these branches unless the branch itself is closed out and carried forward into the others. This makes up a significant delay in the appearance of the same fix in other branches. Moreover, the delay is dependent on manual actions taken to issue the command to bring in the same fix to these other versions. If the branches were chained and a fix could be tagged as applicable to specified branches the commands issued to make the fixes in these other branches could be automated. Such automation will not only relieve the tasks associated with making fixes in more than one places, it will also help with the consistency in performing these steps and to the result in each and every place where it is performed. Since fixes are made to components and components have owners, such fixes could trigger notifications to the component developers so that they are made aware of the flaws that have appeared in the component and affected external customers.
Perhaps one of the necessary evils of software releases is that it introduces versions of shipped software. Customers generally take their own time to upgrade their copy of the software and at any point of time, different customers may have different versions of the software from the maker. Therefore, a Sustaining engineer is sure to find that a defect appearing in an old version may also manifest in other versions. Consequently, a fix applicable to a defect in a version may also be needed to be ported in other versions. When the fix is made to the current software and applied retroactively as a patch to former releases, it is called backporting a fix. Likewise, a fix made as a patch to a shipped software may need to be made to the current development pipeline so that the defect does not reappear in future releases.
Determining the software versions where the defect occurs, finding a suitable fix without side-effects and safe for those releases and propagating the fixes forward and backwards through versions constitute one of the main tasks of the sustaining engineering team. A large part of this effort involves side by side or sequential installation, testing and validation of fixes and take up a lot of time. Yet there are no tools to facilitate these chores for the Sustaining Engineer. One tool that comes very handy to track these fixes is source code version control systems such as git where branching and versioning strategy helps the engineers to label the fixes so that they can be tracked across releases and repeatedly applied to more than one versions.
Let us say there are two previous versions of software releases in addition to the current source code version that is in active development for future releases. A fix made to the current version may also need to be made to the earlier versions and vice versa. Yet there is no automation of bringing in the fix to these branches unless the branch itself is closed out and carried forward into the others. This makes up a significant delay in the appearance of the same fix in other branches. Moreover, the delay is dependent on manual actions taken to issue the command to bring in the same fix to these other versions. If the branches were chained and a fix could be tagged as applicable to specified branches the commands issued to make the fixes in these other branches could be automated. Such automation will not only relieve the tasks associated with making fixes in more than one places, it will also help with the consistency in performing these steps and to the result in each and every place where it is performed. Since fixes are made to components and components have owners, such fixes could trigger notifications to the component developers so that they are made aware of the flaws that have appeared in the component and affected external customers.
codingexercise
Find the minimum gap in an array. The largest gap is between the maximum and the minimum:
int GetMinGap(List<int> A)
{
A.sort();
int min = A.max() - A.min();
for(int i = 1; i < A.Count; i++)
if (A[i]-A[i-1] < min)
min = A[i] - A[i-1];
return min;
}
Find the minimum gap in an array. The largest gap is between the maximum and the minimum:
int GetMinGap(List<int> A)
{
A.sort();
int min = A.max() - A.min();
for(int i = 1; i < A.Count; i++)
if (A[i]-A[i-1] < min)
min = A[i] - A[i-1];
return min;
}
No comments:
Post a Comment