As developers, we are told to check in the code at least by end of the day, so that if our laptop gone missing in action, or the hard disk of our desktop decided to take a long break, our work is still preserved.
As developers, we are also told do not check in the code that could break the build or even further, do not check in the code if it breaks test cases.
In order to follow these 2 guidelines, we make sure our code does not break the build, does not break test cases and we checked them in before going home. More than often, this means some overtime in the evening…
To make things even more complicated, we add code review process into the development process. To make code review process more productive, it will be better if we have minimum number of changesets ( only one change set would be great!).
How to meet these conflicted goals at the same time?
Microsoft understands the hard time we are facing, and it offered us a solution in TFS. In TFS , MS introduced a concept of “Shelve and Unshelve”.
Shelve : means put my code change to the TFS server but do not update the code base. It means when I try to get latest version, I will not get the code change you made in a shelved set.
Unshelve: means take out the shelved set I shelved before and continue working on it
With this concept, you could “Shelve” your pending changes at the end of the day without worrying if it break build or break test case. And then next morning, you can unshelve your pending changes and start to work it again. When you are done, you check them in as one changeset.
it solved our problem, we do not need to stay back late in the evening, and as a reviewer, we will have less changesets to check. Dream comes true!
Furthermore, there is one bi-product in this process. That is “shelve set”. When you shelve your pending changes, you can make it public or private. Once you make it public, you are making it available to others ( for this case, to the code reviewer). The code reviewer can review your code before you check them in.
If you think this is what you want to do, you shelve your pending changes make it public, and then tell your code reviewer shelve set name. he or she can review the pending changes in the shelve set and once it passed the code review. you then can check in them to TFS…
With this, we may not need to have 2 other code branch and use merging as part of code review process…
Okay, happy Shelving and Unshelving,
one last piece of advice, after you shelved your pending changes, before you un-shelve it, do not change your code. Otherwise TFS will complain about it.
No comments:
Post a Comment