It is rare that in real-life project that we only deliver 1 SharePoint Solution using WSP in the installation package of our solution. Even in very simple case, the installation package must contain at least Release Notes, Installation Guide which is not part of WSP. In more complex case, the installation package must also contains scripts, batch file, reporting services files, windows service installation and many more.
Yes, we can create custom MSI and put all of those items together in the installation package as our ancient did. And then, the creation of the package itself become another major task of the project.
This article will approach the solution of the problem from different angle, which is more developer’s friendly using day-to-day tools that we can find in the internet.
Concepts & Goal
What we want to achieve is that we don’t want to reinvent the wheel, we want to use standard stsadm or PowerShell to deploy SharePoint solution. The package must be adaptive to future changes, easy to create and combine many tools that we can find today or in the future.
Each individual component that build the installation package must support independent versioning. Independent versioning allow that each component can have different cycle of bug-fix, major/minor release without compromising other component.
The installation package must contains version numbering, which makes easy for the IT Pro to deliver and pick-up the correct components. It must include package information such as Release Notes, User Guide and Testing Document. The installation package must also be versioned.
So in summary, our requirement are
- The component in the package must be independent, versioned without affecting other components.
- The installation package creation must be easy, versioned and can contains other metadata information.
- The installation package must be adaptive to future changes in the tools for deployment, script.
- It must as much as possible to use available tools in the market, and not reinvent the wheel.