DEV Community: Jason Phillips

IaC with Excel

Jason Phillips — Tue, 24 Feb 2026 03:04:19 +0000

The Infrastructure as Code Dilemma: What If Excel WAS the IaC?

As organizations adopt Infrastructure as Code (IaC), operations teams face a dilemma: they need to deploy infrastructure using Terraform, ARM, or Bicep, but they aren't developers. What if the solution was already sitting on everyone’s desktop?

The Infrastructure as Code Dilemma

Your infrastructure team needs to deploy 50 new VMs. They know networking, storage, and security inside out, and the requirements are perfectly documented in an Excel spreadsheet.

The problem? DevOps insists on "proper IaC practices." But seasoned IT pros usually don't speak HashiCorp Configuration Language.

Currently, the deployment process is broken. Ops plans in a spreadsheet, DevOps spends days translating it into Terraform, requirements change, and the cycle repeats. When this bottleneck gets too painful, teams resort to:

ClickOps: Manually clicking through the Azure Portal 100 times.
Fragile Scripts: Hacking together PowerShell or Python from CSV exports that break when APIs change.
Copy-Paste Marathons: Duplicating last month’s deployment and hoping nothing breaks.

The Real-World Bottleneck

Whether building massive 100-VM lab environments or migrating dozens of enterprise applications, the pattern is the same. Application and Ops teams know exactly what they need, but they can't deploy it themselves.

Every deployment goes into a DevOps queue. Every change requires rewriting Terraform. Velocity is measured in weeks, not hours.

What If Excel WAS the Infrastructure as Code?

We’re fighting the wrong battle by forcing Ops teams to learn developer tools. Teams gravitate toward Excel for planning. What if we met them where they already are?

What if you could fill out an Excel spreadsheet and just click “Deploy”?

Introducing ExcelAsCode

ExcelAsCode is an open-source Excel template that generates Infrastructure as Code directly from spreadsheets. No Python scripts to maintain. No complex workflows. Just Excel with deployment superpowers.

How It Works

Download: Get the file from raisingcode/excelascode and enable macros (which safely call Azure APIs).
Authenticate: Securely connect to your Azure tenant using OAuth 2.0 device code flow.
Use Live Dropdowns: The template makes live API calls to populate dropdowns with your actual Azure regions, VM SKUs, OS images, and networks. No typos, no guessing.
Fill in Requirements: Dedicate one row per VM. Add custom columns for cost centers and use standard Excel formulas to calculate IOPS or pricing.
Generate Code: Click "Generate Terraform" or "Generate ARM." The tool validates inputs and creates modular, production-ready IaC files.
Deploy or Review: Click “Deploy to Azure” to provision immediately, or export the files to commit to Git for your CI/CD pipeline.

Core Use Cases

Application Migration at Scale: Turn application owner requirements directly into production-ready code.
Performance Testing: Model 100+ VM test matrices with cost-calculating formulas before bulk deployment.
Disaster Recovery: Clone environment configurations and swap region parameters in seconds.
Bulk Infrastructure Deployment: Replace manual portal clicks with a “fill once, deploy many” workflow.
Pre-Deployment Validation: Verify costs and regional capabilities before spinning up resources.

Getting Started

ExcelAsCode is open-source, and community feedback is vital.

Access the Project: Download the template and docs at https://github.com/raisingcode/excelascode.
Support & Feedback: Submit bugs, feature requests, or cloud provider suggestions via GitHub Issues.

5 PowerShell Modules You Should Know About

Jason Phillips — Tue, 28 Jul 2020 03:59:11 +0000

We all know the possibilities powershell can offer from automation, to cloud, to system administration.

The large variety of from modules have amplified powershell’s capability. Here are a few essential modules and a few light-weight examples of using them in action.

I. Import-Excel

Import-Excel is a powershell module that provides functions to generate excel workbooks. If you need something a little more advanced the “old csv file.” You can format, add pivots, and more

Import-Module "importexcel"

$path = ".\output-file.xlsx"
$excelfile = Export-Excel  $path -Passthru -AutoSize -WorksheetName "Worksheet 1"

$row=1

$ws.Cells["A$row"].value ="Subscription"
$ws.Cells["B$row"].value ="ResourceGroup"
$ws.Cells["C$row"].value = "PreTaxCost"
$ws.Cells["D$row"].value = "Currency"

# Fill the background-color
Set-ExcelRange -Worksheet $ws -Range $ws.Cells["B$row"] -BackgroundColor Cyan -Bold 
Set-ExcelRange -Worksheet $ws -Range $ws.Cells["C$row"] -BackgroundColor Cyan -Bold
Set-ExcelRange -Worksheet $ws -Range $ws.Cells["D$row"] -BackgroundColor Cyan -Bold 


$excelfile.Save()
$excelfile.Dispose()

II. addsadministration

addsadministration is ActiveDirectory Powershell module used to quickly commands to active directory like add users and groups. Honestly, I dont know how anyone could administer AD with out this powershell module. Unlike most module availabile on powershell gallery. You either need to running a windows server or install the RSAT

import-module aadsadministration

 New-ADUser -Name "ChewDavid" -OtherAttributes @{'title'="director";'mail'="chewdavid@fabrikam.com"}

III. AzSK

Azure Devops Security Kit (or better known by its module name as AzSK) offers plethora of tools and applications for securing your azure subscription resources from the subscription level, development, or ci/cd pipeline.

For example, to validate your arm template for any security vulnerabilities and validate it will meet compliance best-practices

Import-Module AzSK
Get-AzSKARMTemplateSecurityStatus –ARMTemplatePath <Path to ARM Template>  -UseBaselineControls

The result is the output of the arm template checker for an appservice arm template I was planning to deploy.

This is just the tip of iceberg. You can inspect your entire subscription or resource group with this powershell module as well.

IV. Universal Dashboard

Universal Dashboard is a website/webframework for powershell that allows teams to quickly develop websites, restful apis , dashboards all while leveraging a modern ui underneath the covers.

#simple hello-name example

install-module universaldashboard  -Scope CurrentUser
import-module universaldashboard

#lets output a simple request
$hellopage = New-UDPage -Url "/Hello/:name" -Endpoint {
    param($name)
    New-UDLayout -Columns 2 -Content {  
    New-UDCard -Id "DataCard"  -Content {

     New-UDMonitor -Title "Downloads per second" -Type Line -Endpoint {
     Get-Random -Minimum 0 -Maximum 10 | Out-UDMonitorData
        }
     }
    New-UDCard -Title "Hello $name" -Id "PageCard"
}
}

#add the page to the dashboard object
$dashboard = New-UDDashboard -Pages @($hellopage)

#Change the -port to anything; I'm using 1005
Start-UDDashboard -dashboard $dashboard -port 1005

After running powershell, if you go to http://localhost:1005/hello/name, you should get response back.

Its important to note their is a community (free) and enterprise version of this module use the Install-Module -Name UniversalDashboard.Community when installing

V. WriteAscii

Need a cool splash logo at the console. Checkout write ascii. Available in the PSGallery

Import-Module writeascii
"Hello World" | writeascii -foreground cyan

Conclusion

Hopefully, if you’re using PowerShell pretty consistently in your day I hope this post was hopeful; be it work or as a hobby. It’s worth mentioning that most of these gems are generated by the dedicate community of powershell users. Feel free to share your most useful powershell modules you use.

Using Github Actions to Deploy Arm Templates

Jason Phillips — Fri, 05 Jun 2020 05:07:48 +0000

Background

Github Actions are one of the fairly newer tools that have entered into the CI/CD tool arena.

What is CI/CD?

The term refers to Continous Integration/Continuous Deployment. Although the terms are coupled together there different. Continuous integration is process of building code and ensuring passes the intergration and code quality of other components in the system. Continous Deployment are tools/process that allow for continous deployment of code.

CI/CD with ARM Templates

ARM templates are one of many approaches to building Azure Resources (VMs, appservices, vnets, xyz) as code or (json template) and allowing software engineering principles to improve the quality of deployments in the cloud.

Why Github Actions?

I would point out Github Actions are still pretty lightweight. Gitlab Runners and Azure Pipelines pack on additional tools such as manual deployments, pipeline stages, approvals etc. So if you need one of those you may have to migrate to something more enterprise but its Github Actions meets a lot scenarios today.

There are certainly a lot of pros. You now have a single location that can houses your source code management and you're CI/CD pipeline.

Another pro with using Github Actions, is there numerous positive community contributions. There are a plethora plugins/marketplace connectors for your deployment simplifying the amount lines you need to script out. You'll see an example of that in later.

What you need

I will walk through setting up a quick Azure Resource Manager (ARM) deployment with Github Actions.

A Github Account
Access to an Azure Subscription as Owner Role
- The Owner Role will allow us to create a resource group and assign roles/permissions to it; we also need a service principal for workflow to run as
- In Azure AD, the account your using has appropriate permissions to create a service principal
  - User is typically good enough unless permissions were customized in AD (see this Required permissions for Service Principals )*
Azure CLI or Cloud Shell Access

Setting Up the Azure Environment

We will create the following*:

A Resource Group to deploy our ARM Templates in GitHub Actions
Service Principal Created that has contributor role to create resources in a Resource Group

*Note: If you have already identified a resource group and service principal created with contributor access, please go to the next step

Create a resource group

Azure CLI Commands

az login
az group create --name lab_resourcegroup --location eastus2
~~~
The first command authenticates us in azure with will be assumed has been been done before running the remainder of commands. It's assumed you're running <b>az login</b> using an account with Owner Role at the subscription and Azure AD Permission to create the Service Principal

I'm using location with eastu2 but feel free to use region thats closest to you.

## Create the Service Principal

Azure CLI Commands

az ad sp create-for-rbac -n "gha_administrator" --sdk-auth
~~~~
The output will be simular below save this information for later

Assign contributor role to Service Principal for the resource group

az role assignment create --assignee [clientId from previous output] --role contributor --resource-group lab_resourcegroup
~~~~
## Next Steps
Now that we have the resource group, service principal, and role assignments setup in Azure, we can move on to setting up github.



# GitHub Setup Steps for CI/CD
In this step, we will:
- Set up a new Github Repo
- Download a simple linux vm arm template for Microsofts ARM repo
- Create a github action workflow
- Commit and push changes to the remote branch

## Set up the Github Repo
- Log into Github
- Create a new repo
- Call it "GHActions" 

  *_Note: If you haven't done this in while, there will be a plus icon near the top-right right-corner; click that, then click "New repository"_

<img src='https://dev-to-uploads.s3.amazonaws.com/i/ge4gd0pi2bxmyxu6o76z.png' style='width:200px; height:75px' />

- On your local system, clone the repo, just created from above

~~~
git clone https://github.com/[your username]/GHActions.git
~~~

<table><tr><td>Warning: If you receive errors such as command not found, it is likely git is not installed in your environment. Please click here to download [https://git-scm.com/downloads](https://git-scm.com/downloads)</td></tr></table>

## Download the sample ARM Template
There are plethora of ARM Templates that can easily be accessed for Azure-QuickStart-Template repo [https://github.com/Azure/azure-quickstart-templates]

For the the Github Action Workflow, we're going go use a simple VM template. 

Download two files from Azure-Quick Start Repo and save them in the current GHAction directory:

1. ARM Deployment Template
[Template File](https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/101-vm-simple-linux/azuredeploy.json)

2. ARM Deployment Parameter File
[Parameter File](https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/101-vm-simple-linux/azuredeploy.parameters.json)

  The second file (ARM template parameter file) is used to conjunction with  the deployment template to pass values for variables at deployment time.

### Make changes to the parameter file
At bear mininum the parameter file needs to be update with a username, pass, for the ARM template. Update the parameter file to something like below:



```
{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "adminUsername": {
            "value": "testadm"
        },
        "adminPasswordOrKey": {
            "value": "Change2ASuperSecureP@ss"
        },
        "dnsLabelPrefix": {
            "value": "labtest"
        }
    }
}
```



## Commit changes


```
git commit add . 
git commit -m  "include the arm template and arm parameter files"
git push origin
```


The repo should now reflect the new arm template files in Github

## Create Secrets for Github Actions
Next we'll create a Secret in the Github repository. Secrets provide a secure way store/retrieve credentials in your CI/CD workflow. Since we're using a Github hosted workloads this is reasonable solution. 

- In Github, click on the "*Settings*" tab
- Click the "New Secret Button"
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/3mh1limoy1nothjdijcm.png)

- Add the output of service principal json we saved earlier
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/vshjq8rrjpokouaick3w.png)

- Let's name the secret "service_creds"

## Create Github Action Workflow
- Click on the Github action tab at the top
![Image](https://dev-to-uploads.s3.amazonaws.com/i/ruww1aiz5oh733mc09gn.png)

- Choose "Skip this and setup a workflow yourself"
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/n4vz9c8qglfpk3jse2cw.png)

## Setting up github actions workflow 
Workflow actions behind the curtain is just a yaml and actually are stored in .\github\workflows
- You can have multiple workflow pipelines ie one for dev, test, prod and deploy to different resource groups or subscriptions. *But* In this example we just have one which will build deploy a linux vm.

Modify the workflow file to look like this


```
# This is a basic workflow to help you get started with Actions

name: CI

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
  push:
    branches: [ master ]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    steps:
    # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
    - uses: actions/checkout@v2

    - name: Azure Login
      uses: Azure/login@v1.1
      with:
        # Paste output of `az ad sp create-for-rbac` as value of secret variable: AZURE_CREDENTIALS
        creds: ${{ secrets.SERVICE_CREDS }}

    # Runs a set of commands using the runners shell
    - name: Deploy ARM Template
      run: |
        az group deployment create --template-file ./azuredeploy.json --template-parameter-file ./azuredeploy.parameters.json --resource-group lab_resourcegroup
```



## Structure of the YAML
This will look very similar if you've Azure Pipelines. At the top part the yaml the name of pipeline the name of the job specified <b>CI</b>

### Event Triggers
The "on" descriptor specifies the conditions that trigger a deployment. In this case its when ever a push occurs to master branch in github. Triggers are extremely customization. My triggers could be specific file or folder or specific wildcard.

### Jobs/Runners/Steps
A job is series of steps the Workflow does. In this Workflow yaml jobs are running on shared pool of "runners"  virtual machines that Github graciously provides and are wiped after the workflow completion. There many flavors linux, windows, etc. you can choose (for this I'm using the ubuntu-latest). They also come preconfigured with binaries such as azcli, terraform, git.

Jobs have steps. Here we have a step to authenticate to azure. I'm using azurelogin from the marketplace instead of "az login." Why? Well it offers support azcli/and powershell. The cred variable is configured to read repo secret we set up earlier. 

Lastly, the next step is deployment command it self deploying to resource group lab_resourcegroup that was set up in the pre-work

## Build Outcome
Once you committed you workflow you should see the results of your deployment in actions

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/xv242bwl3npj0fb3qctd.png)

### Create a Badge
GH Actions allows you easily provide a status to the users on latest build status of the ARM template

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/rmfofuin14nh1294u393.png)

# Summary
This was simple, yet rather long example of how to use ARM Templates with Github Actions. I hope you see the potential for using GitHub Workflows as a quick/free solution to automate deployments of your Cloud Infrastructure. 

One Azure Virtual Machine might not really be the prime candidate. However as infrastructure and app dependencies grow the need to consistently and repeatable deploy the exact replica is where Actions show it's true promise.