Git Product home page Git Product logo

azure-automation-devops-integration's Introduction

Manage-AutomationAccount

The Manage-AutomationAccount DevOps pipeline extension provides a seamless experience for Azure Automation Account resources, automatically updating individual items in the automation account based on the local project with a predefined structure. These items include Runbooks, Variables, Configurations, Schedules, Modules, JobSchedules and Webhooks.

Integrate this extension into your pipeline and let it take care of everything for you!

How does it all work?

The logic of this extension is based on a predefined directory structure where you store individual items you want to synchronize with Azure Automation. To obtain this directory structure, a PowerShell script called InitializeRepository is used, which, among other things, creates an example in each directory of how the definition of each item to be synchronized should look. The only mandatory input for this script is the directory where the predefined structure should be created. This script creates a directory structure divided into Definitions and Source. Individual environments are defined in the Source directory (for example: UAT, Production,..Note: if you do not use an environment, use the Common directory). The definition is the same for all environments in the Source directory. Simply put, in Definitions you specify the definition and bindings of individual objects, and in Source you store common objects to be synchronized with the storage account.

Let's demonstrate this with the following example:

Directory tree:

-Definitions
    -Runbooks
        -test.json
        -test2.json
    -JobSchedules
        -test.json
        -test2.json
    -Schedules
        -Minutes-15.json
        -Minutes-30.json
-Source
    -Common
    -Prod
        -Runbooks
            -test.ps1
            -test2.ps1
        -JobSchedules
            -Default-Parameters.json
    -UAT

Definitions

Example of runbook file named test.json

{
    "Name": "test",
    "Implementation": "test.ps1",
    "Type": "PowerShell",
    "RuntimeVersion": "5.1",
    "AutoPublish": true,
    "RequiredModules": [
        "CosmosLite"
    ]
}

Example of schedule file named Minutes-15.json

{
    "Name": "Minutes-15",
    "StartTime": "00:00:00",
    "Interval": 15,
    "Frequency": "Minute",
    "MonthDays": [],
    "WeekDays": [],
    "Description": "Schedule starting every 15 minutes",
    "Disabled": false
}

Example of jobSchedule file named test.json

{
    "RunbookName": "test",
    "ScheduleName": "Minutes-15",
    "Settings": "Default-Parameters.json"
}

Note: Setting refers to the detail (parameters) of schedules of a specific runbook. In this example in Source in file Default-Parameters.json the parameters are defined.

Source

Example of runbook file named test.ps1

Write-Host "This is production pwsh script..."

Example of jobSchedule file named Default-Parameters.json

{
    "RunOn": "azure",
    "Parameters": {"parameterTest":"test2"}
}

The Manage-automationAccount DevOps extension consists of two main parts:

  1. manage-automationAccount - With this part, you can synchronize items such as Runbooks, Variables, Configurations, Schedules, Modules, and Job Schedules.
  2. manage-automationWebHooks - Use this part even if you use WebHooks to trigger some Runbooks.

The following properties serve as inputs for the manage-automationAccount DevOps extension:

  1. environmentName (required) - Defines the environment for which you want to perform synchronization (the default environment is "Common").
  2. projectDir (required) - Defines the path where the predefined directory structure is located in the project repository.
  3. subscription (required) - Defines the subscription in which Azure Automation resides.
  4. azureSubscription (required) - Defines the service connection that has the necessary permissions for Azure Automation. Current version suport service connection as ARM Service principal.
  5. resourceGroup (required) - Defines the resource group in which Azure Automation resides.
  6. automationAccount (required) - The name of the Azure Automation account to which items will be synchronized.
  7. storageAccount - If you need to use powershell modules in your solution that are not part of the powershell gallery and you don't want them to be public, this devOps extension can automatically upload these powershell modules to the storage account whose name you define in this field.
  8. storageAccountContainer - Here you can define a specific container in which the powershell module should be saved
  9. fullSync - Defines whether items that are not in the predefined directory structure should be deleted from Azure Automation.
  10. reportMissingImplementation - Returns a list of items that do not have an implementation.
  11. verboseLog - A switch for detailed logging.

Requirements

There are no specific requirements that the extension requires.

Extension Settings

No special setting is required.

Release Notes

Initial release of Manage-AutomationAccount Extension.

Enjoy!

azure-automation-devops-integration's People

Contributors

jformacek avatar patrikjelc avatar romansebranek avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

azure-automation-devops-integration's Issues

How do Jobschedules support different parameters for each envionment?

Hi, I'm trying to create different jobSchedules (with different parameters) for each environment. Its unclear how this is done as there's no separation of the JobSchedule definition from the parameters passed in. I.e.no separate Source file capability for each jobschedule.

I think this has been refactored since I last visited this repo, and is now supported, but the documentation / initialise repository function doesn't seem to have kept pace with the recent changes.

Is it possible to post a sample jobschedule source file showing how the parameters are meant to be defined/passed in ?

Runbook deployment for powershell 7.2 fails with 404 error

As stated above, runbooks targeting powershell 7.2 now fail to deploy with error:

##[error]The remote server returned an error: (404) Not Found.
##[error]PowerShell exited with code '1'.

I think this may be due to the API version 2022-06-30-preview no longer being valid, though I'm struggling to find that documented.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.