Automation Packs include an Azure Resource Manager template that deploys Automation resources to Azure. The template can include any Automation resource needed for an Automation solution. Automation resources include:
- Runbooks
- DSC Configurations
- DSC Configuration Compilation Jobs
- Runbook jobs
- Integration Modules
- Schedules
- Credentials
- Certificates
- Variables
- Connections
##Rules for contributing to the Automation repository
-
Each Automation pack is contained in its own folder.
-
The parent deployment template must be named azuredeploy.json. You can also have child templates which do not need to follow a naming convention.
-
Include a Readme.md file that explains: 4. How the template works and what the Automation pack automates 5. What resources are deployed 6. Includes the "Deploy to Azure" link 7. Any known limitations
-
Any Automation assets used in your runbooks or DSC configurations should be included in the deployment template.
-
Any runbooks, modules, or DSC Configurations in your ARM template should use the following conventions:
-
1. A **variable** containing the **URL** for the resource content 2. A **variable** containing the **Name** of the resource
-
Any Automation assets in your template should follow the the following conventions:
-
1. **Parameter(s)** for the asset value(s) are in the deployment template to allow end users input their own values 2. A **variable** for each asset name
-
Template parameters should:
- Follow camelCasing
- Contain allowedValues wherever it makes sense
- Have the description specified using the metadata property. An example is included below:
"automationAccountName": {
"type": "string",
"metadata": {
"description": "The name of the Automation Account"
}
}
##Recommendations for writing your Automation Pack
You can store runbooks referenced in Automation Packs in two different ways:
- In an external location of your choice. Preferred locations are the PowerShell Gallery or Script Center
- In a Runbook subfolder within the Automation Pack.
Best practices for runbooks:
- Follow practices outlined here.
- Always include a header with the following when publishing to PowerShell Gallery:
<#PSScriptInfo
.Version 1.0
.Author elcooper
.CompanyName Microsoft Corporation
.Copyright (c) 2015 Microsoft Corporation. All rights reserved.
.Tags Tag1 Tag2
.LicenseUri https://contoso.com/License
.ProjectUri https://contoso.com/
.IconUri https://contoso.com/MyScriptIcon
.ExternalModuleDependencies bar
.RequiredScripts foo
.ReleaseNotes
contoso script now supports following features
Feature 1
Feature 2
Feature 3
#>
You can store modules used in your runbook in two different ways:
- Create a Module subfolder and place all your modules in the folder.
- Place your modules on the PowerShell GitHub repository and publish your module to PowerShell Gallery.
To deploy a module, you must also have a zipped module folder formatted for Azure Automation. This is used in the Azure Resource Manager deployment template. For more on creating modules for Azure Automation see Authoring Integration Modules.
Follow the PowerShell best practices for publishing a module to the PowerShell gallery outlined in this blog.
If you have a pack that contains many Automation resources, you can write one parent template that refers to the base templates: 000-base-templates. This allows you to reuse the core Automation resource templates without having to write your own.