During my SharePoint Conference session (SPC273 : Application lifecycle management in Office and SharePoint), I showed the audience how simple it’s to automate the process of building, packaging & deploying SharePoint apps by creating very basic Team Foundation Server Build Definitions. I’ve also quickly touched upon two challenges that architects and developers usually face when trying to add Automated Build Verification Tests (BVT) to the process & hence reaching a fully automated continuous deployment process.
The two challenges are:
- The SharePoint App should be manually trusted before any manual or automated testing take place.
- From Microsoft Test Manager & before any automated test cases are executed, the latest build should be manually assigned to the test plan containing those test cases.
I’ve explained the first challenge along with a trick that you can use to eliminate the manual step needed in this post. Today, I’m going to explain the second challenge and show you how to handle it.
If you are using Microsoft Test Manager for testing, the “build in use” field within the Test Plan should be updated to use the specific build that your testers are going to test.
There are two main reasons for this:
- As you proceed with testing, you might find bugs. Those bugs should be logged against a specific build for traceability & reporting reasons. For more info, please check this article.
- Before automated tests are executed, Microsoft Team Foundation Server copies the Test Automation assemblies from the drop folder of the assigned Build to the remote testing environment where test cases would be executed. I’ve written a post and recorded a quick video last year to show how and where those DLLs are copied, you can check them out from here.
Unfortunately, There is no option out-of-the-box to automatically update the “Build in use” field to use the latest build. This means that after the SharePoint App is built, packaged, deployed & trusted, you still need to pause the testing efforts, go to Microsoft Test Manager and update this field manually to use the latest build. In case you want to add Automated Build Verification Tests (BVT) to your build definition, you will need to find a way to automate this task and that’s exactly what we are aiming for; a fully automated continuous deployment and quality assurance process.
The trick is simple:
- Create a console application that uses Team Foundation Server API to retrieve the latest successful build and then assign it to the current test plan.
- Call the console app from within your build definition (After the app is built, packaged, deployed and trusted and before test cases are executed).
Now I have a few questions to answer:
- How can I create the console application?
Here is some code that you can use. The code is self explanatory.
Where should I deploy it?
I usually copy the output .exe to my testing environment. You can copy it anywhere, just keep in mind that it should be executed on a machine with ‘at least’ Visual Studio Team Explorer is installed.
How can I call it from the build definition?
There are different options. The one I use is as follows:
- Create a build definition based on the “Lab Default Build Process Template”
- Copy the .exe to the testing environment.
- Call the Console Application after the app deployment (and trust) take place and just before test cases are executed.
Once the console application is called, the “Build in use” field is updated, the latest & correct Test Automation assemblies are copied to the remote testing environment, the test cases are executed on the latest build, and the results are published and reported against it.
Here is an example for what you can get once a developer checks-in some code to the source control repository:
See it in action:
To complement my #SPC14 session, I’ve recorded a 25-min video to show how to create a fully automated continuous deployment process for SharePoint Apps (Build – Deploy – Trust – Test – Report). The two challenges are handled in the video, you can watch it from here.