Category Archives: Testing

[Arabic Video] Continuous Deployment & Automated Testing Workflows for SharePoint & Office 365 Apps

spsgulf

Today’s video has been recorded from SharePoint Saturday Gulf 2014. What’s different about this session is that it’s all demos, few slides then a long demo that explains & shows the different aspects for managing the Lifecycle of SharePoint & Office 365 apps. This includes but not limited to Continuous integration, Continuous deployment, Automated Testing, Manual Testing, etc…

Please note that this video is in Arabic, to watch the English version, please check my session at SP24 Conference from here.

Advertisements

[SP24 Conference] Automated Build-Deploy-Test Workflows for SharePoint 2013 & Office 365 Using VS2013 – Slides & Video Recording

I’m glad to announce that the slide-deck & video recording for my session at SP24 Conference are now available.

For watching my session recording, click here.
For viewing the slides, click here.
For the other sessions, click here.

Speaking at SharePoint Saturday Gulf on April 12th

Title: Application Lifecycle Management in SharePoint 2013 & Office 365
Description: There are several methods to customize SharePoint. Developers have the option of creating new cloud applications for SharePoint or maintaining legacy full trust code. Coupled with the complexity many organizations have in terms of managing SharePoint customizations across Office 365 and on-premises implementations, developers and solution architects will need to understand how to adjust application lifecycle management (ALM) techniques to support and deploy quality solutions. This series of blog posts will focus on the establishment of development, testing and deployment best practices for on-prem and cloud applications and solutions. This will also include concepts such as continuous integration & automated testing.
Language: Arabic
Level: 400
Date: April 12th
Time: 12:00 PM (GMT+4)

Register for SPS Gulf from here

Meet SP24 Conference Speakers!

I’m so excited about SP24 Online Conference and I very much appreciate the efforts behind it. During the past two weeks, the team behind SP24 has been publishing some short videos to introduce the conference speakers and sessions. Click on the image below to watch the videos and choose the sessions that you’re most interested in attending.

As you might know, I’ll also be speaking at the conference. Below my session details:

Title: Automated Build-Deploy-Test Workflows for SharePoint 2013 & Office 365 Apps

Description
: With the introduction of SharePoint 2013, there are different methods to customize SharePoint. Developers have the option of creating new cloud applications for SharePoint or maintaining legacy full trust code. Coupled with the complexity many organizations have in terms of managing SharePoint customizations across Office 365 and on-premises implementations, developers and solution architects will need to understand how to adjust application Lifecycle Management (ALM) techniques to support and deploy quality solutions.
In Visual Studio 2013, you can create a build-deploy-test workflow to deploy and test your SharePoint apps & solutions when you run a build. Over several demos, we will cover how to get started with automating the build, deploying the resulting packages to SharePoint Virtual Testing labs using PowerShell, then automatically running automated tests against the SharePoint Applications & Solutions.

Click on one of the pictures below to watch my introductory video.

Automated Testing Challenges for SharePoint Apps – Assigning the Latest Build to the Current Test Plan!

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:

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.

The Challenge:

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:

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:

bdttr

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.

[SPC14] Application Lifecycle Management in Office & SharePoint – Slides, Recording & a Complementary Video!

I’m extremely happy to announce that my session (#SPC273) from the SharePoint Conference 2014 (#SPC14) on “Application Lifecycle Management in Office and SharePoint” is now available on Channel 9. This means that now you can view the slide-deck, download it or download the full session recording.

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). I’ve quickly explained the theory in the session but I didn’t have time to show the full process, so I highly recommend that you watch the session first before watching the complementary video.

ayman_eric

Note : You might also want to check this blog post (Automated Testing Challenges for SharePoint Apps – Trusting the app!) for additional details about the App Trust workaround!

Automated Testing Challenges for SharePoint Apps – Trusting the app!

Many architects are trying to establish a fully automated continuous deployment process for their SharePoint apps. While automating the build, packaging & deployment is fairly simple (check this), there is a big challenge that is preventing architects and developers from reaching the full automation stage. That’s is “Trusting the App“!

Following the deployment of the application components (to pre-prod environments), it is important to note that before anyone accessing the application, including automated tests that may be part of the build, a tenant (or site collection) administrator will have to trust the application on the app information page in SharePoint. This is usually a manual process and there is no way to trust your app through PowerShell or .NET CSOM but there is a trick that I use for achieving a full automation! PowerShell IE Automation!

Here is the script that I use from within my deployment script:

$url = “$($web.Url.TrimEnd(‘/’))/_layouts/15/appinv.aspx?AppInstanceId={$($appInstance.Id)}”
     $ie = New-Object -com internetexplorer.application
     try
     {
         $ie.visible=$true
         $ie.navigate2($url)
        while ($ie.busy)
         {
             sleep -milliseconds 60
         }
         $trustButton = $ie.Document.getElementById(“ctl00_PlaceHolderMain_BtnAllow”)         
         $trustButton.click() 
         sleep -Seconds 1
         Write-Host “App was trusted successfully!”
     }
   catch
   {
   throw (“Error Trusting App”);
   }
   finally
   {
        $ie.Quit()
  }

You just need to add the code above to your deployment script and VOILA. You no longer need to suspend the testing process until the application is trusted. Now a completely “Build-Deploy-Test workflow” is possible!

Finally, I would like to give some credit to Alexander Brassington, his blog post about automated publishing for content types using PowerShell IE Automation inspired me. Although, the post is completely unrelated to Build Automation, it helped a lot on coming up with the workaround!