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

Advertisement

MEA MVP Open Day 2014 – I’m inspired!

Last weekend, Middle East & Africa MVPs had their first local gathering since 2008. Although this was very close a long trip to Las Vegas to attend and speak at the global SharePoint Conference 2014, I made it to Istanbul on March 20th to attend “MEA MVP Open Day” and spend a couple of days in one of my favorite cities worldwide.

It has been an amazing event for me, not only did I get to make new friends but I also had the chance to meet some friends that I had previously met during global MVP Summits, TechEd events as well as local conferences.

During the two days, we had the opportunity to listen to great & informative talks by Aben Kovoor (MEA HQ DPE Lead), Michael Fosmire (Microsoft MVP Program Business Lead), Dariusz Zalewski (Nokia Developer Champion CEE Lead) and Ekaterina Lajintseva (International Senior Site Manager for MSDN & TechNet). We also had some MVP-to-MVP sessions and discussions, those for me were the coolest & most useful part in the two days!

Although I’ve been in the community for a long time, the MVP-to-MVP sessions in addition to our side talks inspired me to come up with new plans and work on new things:

  • I liked how Alistair Pugin (SharePoint MVP) united the efforts of the South African SharePoint User Groups & SQL User Groups to work together on joint big events, this is something that I’m planning to replicate in some of the countries that I regularly visit in Middle East & Africa.
  • I also liked how Taylor Gibb (Windows Consumer MVP) reached millions of technology users through his consumer-focused blog. Although I’m maintaining an active blog that deeply tackles many business productivity and collaborations areas, I still didn’t offer much in the consumer space. During the next months, I’ll also extend my focus to cover other products areas like Office Online, Skype and others.
  • I very much liked the personal branding tips and tricks presented by Daron Yondem (Azure MVP). Daron was kind enough to share with us very useful online services that can help boost the reach of our technology contributions. IFTTT.com & bufferapp.com are just two examples.

Besides, I enjoyed learning about some of the impactful activities in the past 12 months:

  • Yasser Makram’s (Client Dev MVP) well-received sessions at TechEd North America & TechEd Europe events.
  • Sherif Talaat’s (PowerShell MVP) two books in 1 year!!
  • Niyi Omotoyinbo’s (Directory Services MVP) contribution to the Cloud OS MVP Roadshow in Africa.
  • Ahmed Bahaa’s (Visual Studio ALM MVP) session @ MEA Visual Studio 2013 launch in Dubai.
  • And more …

Last but not least, I would like to extend a huge word of thanks to Hande Kayadeniz Torkan (MEA MVP Lead) and Sinem Eylem Arslan (Turkey MVP Lead) for putting together such a phenomenal event. Cannot wait to see you along with fellow MEA MVPs in Seattle (well, If my MVP status is renewed in April) J

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!