Detecting language please wait for.......
As this is the first mention of ISHDeploy into this community, I'll first provide some background on what it is. I'll refer to some posts already available on my personal space.
ISHDeploy is a PowerShell module specific to the version of Knowledge Center Content manager. The mapping goes like this
Both modules are available in the PowerShell gallery though this query.
The module comes with its own documentation portal. For example for the ISHDeploy.12.0.1 please refer here.
The portal contains many code oriented tutorials on how to work with module, use the cmdlets to configure, customize and integrate the deployment as well as how to execute various hypothetical certificate rollovers.
For more insight, information and history about the code as configuration concept and ISHDeploy please follow
ISHDeploy had its first stable version 1.1 back in September and since yesterday there is the latest 1.2 available.
This is the slide with what is new but you can get a more detailed summary in the documentation portal's history.
With this new version you can fully control the menu and button items in the content manager's web client, as well as apply your customization into the web client.
This is fully documented and analyzed in tutorials in the documentation portal. For example the tutorial Work with files and packages explains how to upload and apply the customization and Configuring ISHCM web UI button bars how to create buttons that consume it.
There are also some improvements into the experience offered to the script author.
A hidden gem, and my personal favorite, in this release is the ability to explicitly backup files using the Backup-ISHDeployment cmdlet before changing them on the deployment. It is recommended that the changes are applied through scripts and not through a file overwrite. You can always undo your changes with Undo-ISHDeployment cmdlet.
This combined with the recommended delta scripts will reduce your dependency to the Content Manager version specific files, thus reduce your cost for upgrades and make the upgrade more predictable. This complies with the code as configuration principal and if extended with automation, it can go a long way. The Backup-ISHDeployment cmdlet opens up also the road for script based configuration that are not fully supported by the module or are two specific to each deployment's use case.
As an example, if your customization is about an extra node in an xml file then a script will always be successful regardless of the changes in the file, unless the schema of the xml changed. A smarter script can even raise warnings or errors on why it is not compatible. When empowered with automation, then you get an automated report if and how much of your code as configuration scripts are compatible with the new version.
Any feedback would be much appreciated.