What is Continuous Delivery and why do you need it
In today’s world, one of the key elements for market success is the time it takes for your product(s) and features to get to the market. For software development, continuous delivery is an approach that eliminates waste and removes the traditional long waiting times between implementation and release.
However, not everyone is reviewing their deployment and release processes in their products, and prefers to invest this time in other ways (e.g. in extra features). If you also consider software development in the enterprise world on large, complex platforms such as SharePoint, the deployment process becomes even more cumbersome.
When we started working on a content authoring and management product built on top of SharePoint and Office365, we immediately saw that there was quite a long time spent in deploying and releasing even minor versions. We have also been working for quite a while with Visual Studio Team Service and Azure so we decided to take full advantage of them and give up the old traditional deployment process.
The goal was to reduce the product team’s intervention to a minimum, automate the process as much as possible, from creating the builds, binaries and related artefacts to having automated testing and finally creating and delivering the deployment package. We wanted to reach a state in which, new features pushed into the repository could automatically or, at the press of a button, reach the target environment, whether we’re talking about testing, staging or production.
Continuous delivery is about creating a fast, efficient and streamlined process of delivering new functionality to end users. The process allows for a constant flow of changes to go from development into production in as little time as possible with the help of an automated pipeline. The code is always ready to be deployed to production, but as opposed to continuous deployment, where every change is automatically pushed to production, continuous delivery allows us to determine the exact time when the deployment should be made.
A continuous delivery system does not necessarily deliver only to the productive environment, although that is an ultimate goal for shortening the time to market and feedback loops. A lot of development, testing and deployment effort can also be saved by having multiple pipelines, for each stage of the release process. In our case, we have planned for QA/Integration, Staging and Production environments. The pipeline is split into several key stages, each responsible of validating and verifying the code before it gets to the next stage. So, how did we do it?
The first step is automating the builds and setting up continuous integration. Build tasks can be used to create the necessary binaries, and can provide developers with quick feedback about their application.
The continuous integration builds perform basic validations on the code:
- It compiles correctly
- All unit tests pass
- Code quality gates pass
By applying this to our SharePoint add-in, we created a build definition in VSTS, where the code runs through quality gates (for now – StyleCop[link needed] and SonarQube[link needed]), compiles the necessary binaries for the web application, and packages the SharePoint Add-in Manifest as an App Package. When continuous integration is in place, these quality gates play a crucial role in only allowing reliable and well-written code to get to the next stage.
The second stage is the test automation performed on the intermediate environments. In our case, we set up several test environments to perform the integration tests and functional validation. The pipelined version of the application is tested with both automated integration tests as well as load and performance tests.
The final deployment package can consist of artefacts and binaries from multiple applications or sources. It is quite easy to setup as many artefact sources as necessary. Using tasks that run PowerShell scripts or built-in VSTS tasks, all the final steps can be automated to aggregate all the artefact sources into the final deployment package, which will be delivered to production.
As we are targeting both On-Premise and Office 365 users, the final stage of the deployment part is split up in two.
In the case of on-premise environments, where the environment is behind a firewall, a deployment package is created with all the necessary artefacts for performing an upgrade. This deployment package also contains the necessary documentation to perform the upgrade or a fresh product install.
Office 365 & Azure
In the case of Office365 releases with Azure infrastructure, we can automatically deploy the binaries to the virtual machines hosting the provider-hosted app.
Because of VSTS’s powerful release infrastructure, in case of any emergency, rolling back to a previous version is a breeze, and it can be done in minutes.
The SharePoint App Package itself is automatically uploaded to the App Catalog of each tenant.
To sum up, the less time we spend doing manual deployment tasks, the more time we can spend delivering value to our customers, as well as receiving faster and more pertinent feedback from users, which in turn allows us to iterate and improve faster.
We have the same vision we began with: to shorten feedback loops, to be able to “furiously iterate” and to take “small bites, but chew them fast”. Continuous delivery helps us do this by reducing testing and deployment overhead through automation and by creating an environment in which the entire team feels confident and encouraged to push features to the end-users, all this without compromising release stability.
Example: Smart Attachr
Find the files you need by simplifying how you search through SharePoint’s complex & highly distributed site structure. Smart Attachr – File Search Assistant is accessible from your Outlook window – so forget about switching windows when you are writing e-mails. Just let the assistant know what document you need– using plain English – and it will find it for you.