Adxstudio Portals for Microsoft Dynamics CRM implementations should follow a similar implementation methodology that’s used on traditional software development projects. This post describes the first environment, the development environment, which is typically setup when embarking on a new implementation of a Portals project that needs configuration or development efforts.
Adxstudio Portals can be used as an application or as a platform upon which solutions are built. As an application, it contains built-in features that provide a fully functioning website, and many users will find those built-in features provide all of the capabilities they ever need without needing to make any extensions. In this case a development environment isn’t necessary.
On the other hand, as a platform, Adxstudio Portals provides a starting point for building web applications with a lot of common features already in place, and along with Dynamics CRM provides application creation capabilities that allow one to extend the application to do more than it comes with by default. For those using Adxstudio Portals as a platform, even though the efforts in building the functionality aren’t always done using software development techniques and can often be accomplished through configuration efforts, the same needs and objectives seen during software development – that of being able to successfully extend, maintain, upgrade, and deploy applications – are still present and will be needed, and are best managed by following software development practices.
The development environment is the first environment normally created when starting a new Portals project that falls under the Portals as a platform criteria mentioned above. The word development doesn’t have to necessarily imply that software development is being performed in this environment, but it’s where new work and changes are done first (or developed).
Two primary infrastructure components need to be in place for all Portals projects: the CRM and the Portal. The CRM acts as the database for the Portal, and contains the schema and data for the Portal. The Portal is the website that presents the interface to users, showing information stored within CRM and storing information it captures back into CRM. The Portal connects to the CRM using the CRM’s web services.
The CRM used for a Portal is Microsoft Dynamics CRM. The Portal used is Microsoft’s Adxstudio Portals product, which is an ASP.NET application that’s hosted on an IIS web server. In a development environment it can either run on a desktop version of Windows or on Windows Server. New installations of Adxstudio Portals should use the newest supported versions of CRM and Windows because those are the versions most frequently tested and used, and will provide the most features.
The development environment runs either on a local computer that only individual users will access, or on a shared server that’s accessed by multiple users. A hybrid of the two is often needed to maximize individual and team productivity – working on a local computer provides isolation when working on destabilizing changes that would otherwise disrupt other team members if made on the shared server, and a shared server is used to avoid productivity losses that occur when attempting complex schema and data merging efforts that originate from one’s local computer.
Team members will often comprise users of multiple roles and skillsets, but primarily those who are implementing features have job titles such as software developers, business analysts, technical consultants, or functional consultants. These individuals have the skills needed to make all the types of changes required to implement a CRM and Portals solution.
The CRM environment is setup by importing a starting set of schema and data into a CRM organization. The Adxstudio Portals MSI installation file includes a solution called Adxstudio Installer that streamlines the initial import of the CRM solution files and data that the out-of-box Portals websites depend on.
The Portal environment is setup by configuring an IIS website to use the MasterPortal ASP.NET project that is distributed with the Adxstudio Portals MSI installation file, and then configuring the Portal to connect to the CRM organization where solution files and data were installed.
After the schema and data installation is complete, site features are implemented in an iterative manner. Features may be satisfied using the out-of-box capabilities already provided by the base installation of CRM and Portals, or they may need to be implemented because the requirements are custom to the business. Implementation techniques vary depending on the requirements and their complexity, and will either involve data entry efforts within CRM or the Portal’s interfaces, or will require software development efforts using Visual Studio.
A development environment is usually unstable because of the frequent and iterative changes being made while implementing functionality. Also to ensure the implementation proceeds as productively as possible, developers should have full control over as much of the environment as possible. The development environment is usually only accessed by the implementation team to facilitate their productivity and also prevents the occurrence and perception of instability should other team members or stakeholders to try use the environment.
As code, schema, and data changes are made to implement functionality, these components should be getting saved on a regular basis to a source control system. This provides a version history of the implementation, allows new development environments to be created quickly, serves as a backup in case changes are accidentally lost or need to be recovered, and enables point in time deployments to other environments based on dates or milestones.
After features have been implemented in the development environment, all of the schema, data, and code changes that have been made to produce the completed work needs to be deployed to other environments where team members and stakeholders can review the work and provide feedback. Deploying to separate environments involves the implementation team packaging up the completed work and installing everything in a new environment that runs in parallel with the development environment. Having a separate environment provides a stable environment where other team members and stakeholders can review the completed work and provide feedback, while at the same time new work can proceed in parallel in the development environment.
This post outlined the high level efforts and principles needed for setting up and using a development environment. Future posts will delve into more details on this process, showing the tried and tested strategies we follow to produce successful solutions.