Every software solution goes through well-known, long-established lifecycle stages. Of course, this is also the case with the business solutions built on top of SharePoint. Each solution must be deployable on multiple environments (e.g. tenants and farms). It must be possible to apply updates caused by requirement changes easily to one or more environments. On the end, it should be possible to retract the solution from the environment without leaving proprietary stuff behind.
In SharePoint, there is an additional level of complexity: SharePoint data structures, i.e. lists and libraries, are usually created through the SharePoint user interface, which is a valid way to do so. However, creating data structures through the user interface and developing customizations separately introduces various issues to the ALM cycle (i.e. development, testing, staging, production), especially in the deployment and update process.
skybow Solution Studio adds unique and yet standardized capabilities to this process. SharePoint data structures, solutions and customizations are easy to package and deploy to any target site, regardless if they are in the same or different environment. Solution versioning and updating process is standardized, and different deployments are easily managed and tracked through solution dashboards.
This is our take on SharePoint solution lifecycle, which includes development, packaging, deployment, changes and updates.
Development is usually done on a development SharePoint environment, either in a completely different development tenant or a separate site collection in an existing tenant. Solution creators will create SharePoint artefacts, such as lists and libraries, and all the forms, actions and processes that are part of the solution.
Once the solution has been developed, the next step is packaging. Packages include SharePoint artefacts and all customizations. Each package has a name, a major and minor version and a package description that helps with package management. All created packages are shown in solution dashboard so they are easily accessible and manageable. Old packages can be removed when they are no longer needed.
Created packages can be deployed to target SharePoint sites, which do not have to reside inside the same tenant. With each deployment, SharePoint artefacts, such as lists and libraries, are deployed to the target site with the user interface, processes, actions and all other customizations, which are part of the business solution.
Requirements for every business solution change occasionally. skybow Solution Studio offers a seamless update process, which lets solution creators create updates in the development environment and publish it to the testing, staging or production environment while retaining all the data.
Let’s see an example of how this works. Once solution creators are happy with how their solution looks and works, the first step is to create a solution package. For this purpose, we have set up a link in the upper right-hand corner of the online version of skybow Solution Studio.
There, solution builders can name the package, define a version, provide a meaningful description and choose an icon.
After entering all the data and clicking the ‘Finish’ button, the package will be created. The whole package creation process takes a few minutes.
Once the packaging process is finished, solution creators can see their new package on the dashboard, along with all the other packages for that solution, their version numbers and their descriptions.
If we select that package and look at the package logs, we can see that all the SharePoint lists and libraries used in the solution and all the customizations have been analysed and packaged.
The next task is to deploy this solution into a target site in another Office 365 tenant. For this purpose, we have created a new empty site where our solution will reside.
In Solution Studio, we will click the ‘Publish’ link in the top right-hand corner. This is the deployments dashboard, where solution creators can see all the deployments for this solution, including which version has been deployed to which target site.
Clicking ‘Publish to new site’ will being the publishing (deployment) process. Solution creators will enter the publishing title and description, choose the package version (the newest one will be offered by default) and enter the path to the target site. Site owner-level permissions are needed at the target site. If the solution contains calls to skybow Notifications (i.e. if Remote Event Receivers are used instead of web hooks), solution creators will have to confirm that they trust the skybow Notifications add-in.
Once consent is given, the deployment process begins after creators click the ‘Next’ button.
The first step in the deployment process is verification, in which skybow Solution Studio determines whether the target site is suitable for deployment and whether there are any potential conflicts.
In this case, the target site already contains the default Shared Documents library. Since we know it is empty, we can simply choose to overwrite it with the same library from the solution package.
The deployment itself lasts for a few minutes depending on the complexity of the solution package.
Once the deployment is complete, we can see the deployment information in the publishing dashboard, which includes the target environment, publishing date, version published and much more.
If we switch to the target site, we can see that the deployment is complete and that everything is in place.
When the requirements change, which happens more often than you might think, we can update the existing deployment. In our example, we will create a new action link called ‘Import timesheet’ and a custom list called ‘ImportResults’.
Next, we will create a new package. Since we made a minor change, we will increase the version to 188.8.131.52.
In the package logs, we can see that the new lists and artefacts are already included.
If we switch to the Publish section, we can now see that our existing deployment has a new button: Update. skybow Solution Studio has noticed that there is a new version of the deployed package, and it offers an automated update process.
We will click that to trigger the deployment process again, but only the artefacts and customizations that are different from those in the previous package will be deployed. Once the deployment is complete, we can click on the deployed package and look at the logs. We can see that only the new list and the new action link have been deployed, while the other artefacts are left intact.
Now if we switch to the target site, we will immediately notice the new action link and the new list; the update process has worked as expected.
The packaging and publishing process in skybow Solution Studio Online offers a unique yet standardized and streamlined take on deploying skybow Solutions—or any SharePoint artefacts—to target SharePoint environments. skybow Solution Studio was created with the ALM cycle in mind, and scenarios that involve deploying to the customer’s environment are fully supported through this process. Deployment in SharePoint made easy—finally.