<img height="1" width="1" src="https://www.facebook.com/tr?id=730305433807073&amp;ev=PageView &amp;noscript=1">
Book a Demo

Package and Publish in skybow Solution Studio Online

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.

Take me to Solution Studio!


Solution Studio Package

There, solution builders can name the package, define a version, provide a meaningful description and choose an icon.


Create a ne package

After entering all the data and clicking the ‘Finish’ button, the package will be created. The whole package creation process takes a few minutes.


generating package skybow

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.


Versioning package skybow

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.


package logs

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.


Publish to new 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. 


publish package to new site


trust notifications.skybow.com

Once consent is given, the deployment process begins after creators click the ‘Next’ button.


deployment process verification

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. 


target site to publish

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.


deployment process

The deployment itself lasts for a few minutes depending on the complexity of the solution package.


deployment to a specific sharepoint site

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.


switch target site

If we switch to the target site, we can see that the deployment is complete and that everything is in place. 


update your existing deployment

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’.


import template


Select SharePoint List


Next, we will create a new package. Since we made a minor change, we will increase the version to

create a new package

In the package logs, we can see that the new lists and artefacts are already included.  


package logs 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. 


update your solutions

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.  


versioning history of deployment


deployment log

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. 


udate process

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. 


 Take me to Solution Studio!

Adis Jugo

Written by Adis Jugo

is Director of Product Technology at skybow, and a software architect with over 20 years of experience. Adis is double Microsoft MVP (Most Valuable Professional) for Office Development and for Office Servers and Services. He first met SharePoint (and Microsoft CMS server) back in 2002, and since 2006 his focus was completely shifted towards architecture and development of productivity solutions, now based on the Azure, Office 365 and SharePoint technologies. Adis is an internationally recognized speaker with over 15 years of speaker experience, speaking at various Microsoft, Community and SharePoint/Office 365/Azure conferences worldwide.