This is the 3^rd article of a series of posts on SharePoint 2013 & Office 365 Application Lifecycle Management:

• Introduction
  
• Infrastructure Overview
  
• The Development Environment(s) à You are here!
  
• The ALM Platform(s)
  
• The Testing Environment(s)
  
• Automated Build & Deployment for Full-Trust & Sandboxed Solutions
  
• Automated Build & Deployment for SharePoint-hosted & Autohosted Apps
  
• Automated Build & Deployment for Provider-hosted Apps (Azure-hosted)
  
• Automated Build, Deployment & Testing for Full-Trust & Sandboxed Solutions
  
• Automated Build, Deployment & Testing for Apps
  
• Release Management Overview
  
• Release Management for Apps
  
• Release Management for Full-Trust & Sandboxed Solutions
  

Introduction

In the previous post, I have quickly given you an overview on the full ALM environment that we will be building. The environment comprises some on-premises components & services as well as some cloud services. The on-premises components & services will be combined & hosted in three Virtual Machines as explained earlier.

Here is a quick summary for our full ALM environment:

The reason for having the setup above might not be fully understood at this point. Don’t worry, this will become crystal clear as we move forward.

In today’s post we’ll start creating & provisioning the components & services needed to support our SharePoint Server 2013/ Office 365 development efforts. This will require some on-prem components as well as some cloud services.

Development Environment Considerations

At the end of the previous post, I’ve included some very important exercises. One of which was reading the “Development environment Considerations” section of this MSDN Article. If you haven’t done so, I’d encourage you to read it first before moving forward with this post.

Figure 1. Development environment components and tools
Source: SharePoint Server 2013 Application Lifecycle Management

Creating an O365 development site

With an O365 development site, you can start creating & deploying applications that will be hosted in Office 365, on-premises or on other infrastructure in a provider-hosted model. The benefit of this environment is that infrastructure, virtualization and other hosting considerations for a SharePoint development environment are abstracted by Office 365, allowing you to create applications instantly. A prime consideration for this type of development environment is that applications that require full trust code to be deployed to SharePoint cannot be accommodated as shown in the figure below:

Figure 2. Office 365 App Development
Source: SharePoint Server 2013 Application Lifecycle Management

If you are planning to develop Provider-hosted Apps with the Provider-hosted component hosted on Windows Azure, you will to get an Azure Subscription. Actually, I’m going to show you this scenario in one of the upcoming posts.

Use the steps below to obtain and provision an O365 development site & an Azure subscription:

1. Get an O365 development site :
   

1. Are you an MSDN subscriber? Visual Studio Ultimate and Visual Studio Premium with MSDN subscribers receive a 1-year Office 365 Developer Subscription as a benefit. Redeem your benefit today.
   
2. Do you have a midsize business and enterprise (Plan E1 or E3) Office 365 subscription? You can provision a Developer Site from the Office 365 admin center. For more information, see How to: Provision a Developer Site using your existing Office 365 subscription.
   
3. You can either start with a free 30-day trial, or buy an Office 365 developer subscription (with one user license for either option) by using one of the following links. This subscription costs $99.00 per year.

2. Provision the developer site by following the instructions explained in this article.

3. Get a Windows Azure trial subscription from here.

Now, you have all what you need to develop SharePoint-hosted, Autohosted & provider-hosted (azure-hosted) apps for Office 365!

Creating a Self-contained farm environment (virtualized farm development)

For those solutions that require the deployment of full trust code to run on a SharePoint farm, a full implementation of SharePoint Server 2013 will be required. In our case, we’ll be creating and using a virtualized development machine. I’ll refer to this as the Dev Machine from this point onwards.

Figure 3. On-premises development with a virtual environment
Source: SharePoint Server 2013 Application Lifecycle Management

SharePoint has always been known to require a good deal of resources, and that requirement continues to grow. A single server setup, running SQL Server and SharePoint, with all available services requires 24 GB of RAM. This is a rather large amount even for a production server, let alone a development environment. Microsoft states that for a single server development environment, 8 GB is required to run the minimum recommended services. If Visual Studio 2013 is also running, RAM the requirements increase to 10 GB. These requirements seem rather difficult to satisfy considering most SharePoint development is done on laptops with 8 GB of RAM. To get SharePoint 2013 to run smoothly on a VM with 4-6 GB, we will run only the necessary services. This means no Excel services, workflow services, or search. The most that can be done with an environment like this will be to configure sites and build simple solutions & apps. Use this guide to create a full self-contained development machine.

Before proceeding with the steps outlined in the guide, please note the following:

• Once you create your Virtual Machine (using any Virtualization Technology), you will need to connect the machine to the two Virtual Network Switches that we created in the previous post.
  
• The installation process can quickly get out of hand if you simply choose to install all features of SQL Server and SharePoint. The recommended guide will walk you through installing only what is required to get SharePoint running on a single server.
  
• This guide is instructing you to install Visual Studio 2012 Premium, install Visual Studio 2013 Ultimate instead.
  
• For a more convenient development experience, you might need to disable loopback security check as explained here.
  
• (Optional) To optimize the performance of the Dev Machine, you might need to follow some of the instructions outlined in this post.
  
• (Important) After following the steps outlined in the guide, you will need to configure the Dev Machine for Apps development & deployment. The exact steps are explained here.
  
• If you’d like to exactly follow my steps and have a similar configuration like mine, I’m using the following :
  
  • Computer Name : dev, Domain Name : Cairo.eg
    

    
    

    Figure 4. Computer and domain configurations
    

  • Fixed IP : 192.168.150.128
    

    
    

    Figure 5. IP Configurations
    

  • When configuring your dev environment for Apps, use the following :
    
    • Forward lookup zone name : devapps.cairo.eg
      
    • App Prefix : dev
      
    • App Domain : devapps.cairo.eg
      

    
    

    Figure 7. Forward lookup zone with a wildcard DNS entry
    

    
    

    
    
    

    Figure 7. Configure App URLs using Central Administration
    

  • Use Cairo\Administrator for installing everything. Once you are done with the full installation and configuration processes, copy the “Cairo\Administrator” Active Directory domain user to create another account (cairo\sharepointer) then make sure to add the new user (Cairo\SharePointer) to the Farm Administrators Group from SharePoint Central Administration. This will be our primary user for performing development & deployment. The reason for this is that SharePoint will not allow you to install nor uninstall apps using the farm account (System Account).
    

    
    

    Figure 8. Clone an Active Directory User Account
    

    
    

    Figure 9. SharePoint Farm Administrators
    

Creating an On-Prem Development Site (Remote Development)

If you choose not to use Office 365 developer sites as a primary means for SharePoint application development, on-premises developer sites can be used to develop SharePoint applications. In this model, the Office 365 developer sites’ capability is replaced with on-premises developer sites hosted within a SharePoint farm. The on-premises developer site can be used to deploy SharePoint-hosted & Provider-hosted apps. You cannot use this model for deploying Auto-hosted apps.

Figure 10. On-premises app development with the developer site template
Source: SharePoint Server 2013 Application Lifecycle Management

To create an on-prem developer site, you can follow the steps outlined in this post. Please make sure first that you have properly configured your dev machine for SharePoint apps as explained above.

Summary:

In this post, we have created a self-contained virtualized farm (with an on-prem Developer Site) and an O365 tenant (with a SharePoint Online Developer Site). We have also obtained a Windows Azure Trial subscriptions. We will be using those Development environments to explain & try several ALM scenarios for both SharePoint Server 2013 & Office 365 SharePoint Online.

The crossed-out components in the table below are the ones we have created so far. In the next post, we will be building and provisioning our ALM Platform; that is VM2 (which will host Team Foundation Server 2013 on-prem) & Visual Studio Online (TFS Service or TFS Online).

Exercises:

While waiting for the next post, I would like you to do the following: