How to build a quality testing merge management process methodology in your organization
Are you working in parallel with several software versions? Part of them already released to production and part still not?
If the answer is yes, you have probably borrowed the proper merge management process.
Merge management process is one of the most important things during the software release cycle.
Unfortunately from any reason usually not thought of as part of the standard development process.
How often do you hear from developers that they need to merge code to trunk?
As a result of it the QA team very difficult to follow what the merged code amendments are the main version working on a project.
Just imagine that your project has some versions. You are working on versions in parallel but usually, a project has a trunk version.
As part of the software merge process, all developers should merge code to trunk. QA should verify that all merges are including in the main version and here is exactly the problem…
After all, developers do not always remember or know what merges should be including to trunk and there is a gap…
The fact that the project often doesn’t follow a process for the merging of code leads to disarray and pain leads to disarray and gaps.
Here is a simple idea to follow merge management process methodology in TFS :
>Every current version will contain “merge” work items for each latest previous version that should be included.
>Each R&D changeset that made for merging changes from the previous version must be related to the same work item as it was related to the source branch.
In addition, should manage parallel versions methodology:
> Work items which will be included in more than one current version should be duplicated to both of the versions.
>The work item in TFS should be linked in the following way (Work Item-> All Links->Link to).
Is this article helpful for you? Tell everyone how it helped you