Akumina 184.108.40.206 and later
Before proceeding, please review the Site Package Overview.
To obtain the sitedeployer console application, please look at the Code section of this wiki, at SampleFrontEndStarterProject/tools/Akumina.SiteDeployer.exe
You will need to download the entirety of the SampleFrontEndStarterProject.
Package examples can be found at https://github.com/akumina/AkuminaTraining/tree/master/SiteProvisioning.SampleSite/SiteProvisioning.SampleSite/SiteDefinitions
An Akumina site is deployed via a site package; it is fundamentally a "package" of instructions, files, pages and other artifacts that determines what gets deployed into a site and/or site collection. This same site package can be deployed either:
- By a business user inside AppManager, using the Site Creator/Deployment Manager app.
- By a developer using a console application - The console app uses the site collection credentials and your Site package name and will deploy the assets just like the Site Creator does, but from an automated command line.
Integration into build process
The console application allows continuous and unattended Akumina deployments; when integrated into a development process, a team of developers can collaborate on changes that are deployed into an Akumina site. In the example below:
- Developers check in code to source control (TFS).
- A continuous integration process extracts out the artifacts from source control and it is placed in a build drop.
- From there, a continuous delivery process takes the package from the build drop and deploys it to the QA and/or PROD environments.
Comparison with using the Deployment Manager/Site Creator app
An Akumina site package is generally deployed via the Deployment Manager/Site Creator app inside AppManager. There are a number of considerations to this - it requires a user to login to the app manager, navigated screens, click to take actions and have the browser open while deployment occurs. The console app offers a better and faster way to deploy site packages, and one that can be integrated with existing build tools and processes.
The site deployer accepts several command line parameters:
|options||The artifacts to deploy from the package.|
|envdir||The path to the package directory. See the SampleFrontEndStarterProject in the code link below.|
|assetdirectory||The name of the package to be deployed; this corresponds to the folder name of the site package off the envdir.|
|spurl||The URL of the site that the package will be executed against.|
|spuser||The user to execute the package.|
|sppassword||The password of the user to execute the package.|
To run the tool, you will use the following command (from a command prompt or batch file, assumes the exe is in a directory named tools and you are in the parent directory to that). The example below deploys the master page and the js files to the specified site collection:
tools\Akumina.SiteDeployer.exe options masterpage,js envdir C:\source\Site\ assetdirectory packageFolderName spdirectory DigitalWorkplace spurl https://tenant.sharepoint.com/sites/sharepointsitecollection spuser firstname.lastname@example.org sppassword userpassword
See the deploy.js file in SampleFrontEndStarterProject
The following options are available for deployment:
- controls - updates page content per the assetdirectory/PageContent directory
- widgets - deploys widget pacakages in the assetdirectory/WidgetPackages directory
- imagefiles - uploads images in the assetdirectory/branding/images directory
- fonts - uploads fonts in the assetdirectory/branding/fonts directory
In this example, we have a basic site package that only deploys a single list:
The SiteDeployer console app executes the step:
The resulting output inside the site - a deployed list as well as content:
Other use cases:
The following list are use cases where the site deployer tool will provide benefit for a single developer or entire development team:
- Deploying a single widget instance or a single list, or a set of files - packages can be as atomic as you wish.
- A distributed team of Akumina Developers - Using a continuous integration server such as CruiseControl.NET to deploy changes on demand.
- A project needing a development and staging environment - changes can be trialed in the development environment, then deployed using the tool to the production environment.