DEV Community: Manuel Sidler

Create a SharePoint list item with a people lookup field using Microsoft Graph SDK

Manuel Sidler — Fri, 28 May 2021 09:55:41 +0000

Starting point

Assume we have a simple SharePoint list with the following columns to manage expenses:

Column Name	Column Type
Title	Single line of text
Amount	Currency
Employee	Person or Group

Now we'd like to create expense list items from our C# application. Thankfully, Microsoft Graph provides an endpoint to do that:

POST https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items

So we don't have to fiddle around with some SharePoint APIs and leverage the Microsoft Graph SDK.

The Problem

Let's take a look at the JSON representation of an expense list item:

{
  "id": "2",
  "fields": {
    "Title": "Flight to Zurich",
    "Amount": 125.6,
    "EmployeeLookupId": 13
    }
}

The employee field isn't a user principal name nor an Azure AD object id. That's how we usually work with users inside Graph. Instead, SharePoint uses a hidden lookup list to store a user reference, which differs from site to site.

So how do we get the actual lookup id for a user?

The Solution

There's a way with Microsoft Graph. A bit quirky, to be honest, but at least we don't have to use a SharePoint API and stay inside our Graph bubble.

First, we have to fetch the id of the hidden user lookup list:

var hiddenUserListId = (await _graph
    .Sites["<siteid>"]
    .Lists
    .Request()
    .Filter("displayName eq 'User Information List'")
    .GetAsync())[0].Id;

Next we have to get the user principal name if we don't have it yet:

var userName = (await _graph
    .Users[userId]
    .Request()
    .Select("userPrincipalName")
    .GetAsync()).UserPrincipalName;

With the user principal name in hand, we now can query the lookup id:

var userLookupId = (await _graph
    .Sites["<siteid>"]
    .Lists[hiddenUserListId]
    .Items
    .Request()
    .Header("Prefer", "HonorNonIndexedQueriesWarningMayFailRandomly")
    .Filter($"fields/UserName eq '{userName}'")
    .GetAsync())[0].Id;

The prefer header with HonorNonIndexedQueriesWarningMayFailRandomly is required to query non-indexed columns.

And finally, we can create a new expense list item:

var expenseItem = new ListItem
{
    Fields = new FieldValueSet
    {
        AdditionalData = new Dictionary<string, object>
        {
            {"Title", "Train to Zurich"},
            {"Amount", 23.2},
            {"EmployeeLookupId", userLookupId}
        }
    }
};

await _graph
    .Sites["<siteid>"]
    .Lists["Expenses"]
    .Items
    .Request()
    .AddAsync(expenseItem);

If there's another option to save a user reference in a people column or a more clean way to get the lookup id, let me know in the comments!

Building a CI/CD pipeline for your Azure project with GitHub Actions from scratch

Manuel Sidler — Wed, 17 Feb 2021 09:21:22 +0000

Cover photo by Quinten de Graaf on Unsplash

So you have decided to host your web application on Azure. Now it's time to take care of the infrastructure. Let's open the Azure portal, create all the resources and publish your application with Visual Studio.

But wait! You're going to add some resources and re-create the same infrastructure for different environments. Manual work all over, time-consuming, and prone to error. Wouldn't it be great to have infrastructure as code and let the CI/CD system continuously deploy it together with your web application?

In this blog post, we will use Azure Resource Manager templates and GitHub actions to achieve all of that.

Before we start, please be aware that this blog post isn't a theoretical introduction to ARM templates nor GitHub actions. Our goal is to set up a CI/CD pipeline from scratch to avoid right-click publishing from Visual Studio and manually create Azure resources. We're good people, and good people don't let friends right-click publishing their projects ;-)

If you're interested in Azure infrastructure as code in general, definitely check out other solutions as well like Terraform, Pulumi, Farmer and Bicep.

Tools

The following tools will help us to set up our pipeline:

Visual Studio Code
- Azure Resource Manager (ARM) Tools extension (snippets, syntax highlighting, Azure schema completion and validation)
- GitHub Actions Extension (syntax highlighting and snippets)
Windows Terminal
Azure CLI
Git

Prerequisites

To set up a CI/CD pipeline for our Azure project, we need a GitHub repository, an active Azure subscription and a web application.

In the following example, we use a plain web application created by the dotnet CLI:

dotnet new webapp -o HelloWorld

With that, our basic folder structure in our GitHub repository looks like the following:

│   .gitignore
│
└───src
    │
    └───web
        │   HelloWorld.csproj
        │   ...

The last prerequisite is an active Azure subscription. We can use the Azure CLI to log in to our account:

az login

After a successful login we can see our subscription details in the command prompt:

{
  "environmentName": "AzureCloud",
  "homeTenantId": "xxx-xxx-xxx-xxx-xxx",
  "id": "xxx-xxx-xxx-xxx-xxx",
  "isDefault": true,
  "managedByTenants": [],
  "name": "Azure subscription 1",
  "state": "Enabled",
  "tenantId": "xxx-xxx-xxx-xxx-xxx",
  "user": {
    "name": "manuel.sidler@xxx.xxx",
    "type": "user"
  }
}

Now we're ready to go!

Azure infrastructure

First, we need to create an Azure resource group. It's a container to group different Azure resources together. We can use the Azure CLI to make the group:

az group create --location "West Europe" --name rg-dev-blog

Please notice the abbreviation rg- in the name parameter. It's important to use some conventions when we name Azure resources. In case we don't have any specific ones defined in our company, we should stick to the abbreviations documented by Microsoft. If the command ran successful, we get a response with some details about the created resource group:

{
  "id": "/subscriptions/xxx-xxx-xxx-xxx-xxx/resourceGroups/rg-dev-blog",
  "location": "westeurope",
  "managedBy": null,
  "name": "rg-dev-blog",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
}

For our web application, we're going to set up three Azure resources:

Application Insights
App Service Plan
App Service

Application Insights is optional, but it's always a good idea to have it for logging, events, and other stuff. For more information, visit the official documentation from Microsoft.

The App Service Plan is kind of a server farm, which will host our App Service (the dotnet web application in this case). An App Service has to be assigned to an App Service Plan. If you're coming from a Windows Server world, you can think of an App Service Plan as an IIS and an app service as a site.

ARM Template

Instead of creating these three resources in the Azure portal, we define it in an ARM template JSON file. The question now is where to store it. As we use infrastructure as code here obviously, we should save it in our source directory:

│   ...
│
└───src
    │
    └───azure
    |   |   azuredeploy.json
    |
    └───web
        │   ...

Thanks to the Azure Resource Manager (ARM) Tools extension for VS Code, we now can type arm! in the empty file. This snippet will create a skeleton of the ARM template:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {},
    "functions": [],
    "variables": {},
    "resources": [],
    "outputs": {}
}

Now let's start with the Application Insights resource:

{
    ...
    "variables": {
        "appInsightsName": "appi-dev-blog"
    },
    "resources": [
        {
            "name": "[variables('appInsightsName')]",
            "type": "Microsoft.Insights/components",
            "apiVersion": "2015-05-01",
            "location": "[resourceGroup().location]",
            "kind": "web",
            "properties": {
                "application_Type": "web"
            }
        }
    ],
    ...
}

There are two things to notice here:

Use variables for resource names, because we usually reference them in several places inside an ARM template
To avoid additional traffic cost and performance issues, host your Azure resources in the same location. We can use the resourceGroup().location function to refer to the resource group location

Next, we take care of the App Service Plan:

{
    ...
    "parameters": {
        "appServicePlanSku": {
            "type": "string"
        }
    },
    ...
    "variables": {
        ...
        "appServicePlanName": "plan-dev-blog"
    },
    "resources": [
        ...
        {
            "name": "[variables('appServicePlanName')]",
            "type": "Microsoft.Web/serverfarms",
            "apiVersion": "2018-02-01",
            "location": "[resourceGroup().location]",
            "sku": {
                "name": "[parameters('appServicePlanSku')]"
            },
            "properties": {

            }
        }
    ],
    ...
}

Please notice the sku option, which basically defines the CPU and memory of our machine. This option will probably vary in different environments. We introduce a new parameter to pass it from outside into the template. We'll take care of that in a later step.

Last but not least, here's the template definition for our Azure App Service:

{
    ...
    "variables": {
        ...
        "appServiceName": "app-dev-blog"
    },
    "resources": [
        ...
        {
            "name": "[variables('appServiceName')]",
            "type": "Microsoft.Web/sites",
            "apiVersion": "2018-11-01",
            "location": "[resourceGroup().location]",
            "dependsOn": [
                "[resourceId('Microsoft.Web/serverfarms', variables('appServicePlanName'))]",
                "[resourceId('Microsoft.Insights/components', variables('appInsightsName'))]"
            ],
            "kind": "app",
            "properties": {
                "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('appServicePlanName'))]",
                "siteConfig": {
                    "appSettings": [
                        {
                            "name": "APPLICATIONINSIGHTS_CONNECTION_STRING",
                            "value": "[concat('InstrumentationKey=',reference(resourceId('Microsoft.Insights/components', variables('appInsightsName')), '2015-05-01').InstrumentationKey)]"
                        },
                        {
                            "name": "ApplicationInsightsAgent_EXTENSION_VERSION",
                            "value": "~2"
                        },
                        {
                            "name": "APPINSIGHTS_PROFILERFEATURE_VERSION",
                            "value": "1.0.0"
                        },
                        {
                            "name": "APPINSIGHTS_SNAPSHOTFEATURE_VERSION",
                            "value": "1.0.0"
                        },
                        {
                            "name": "DiagnosticServices_EXTENSION_VERSION",
                            "value": "~3"
                        },
                        {
                            "name": "InstrumentationEngine_EXTENSION_VERSION",
                            "value": "~1"
                        },
                        {
                            "name": "SnapshotDebugger_EXTENSION_VERSION",
                            "value": "~1"
                        },
                        {
                            "name": "XDT_MicrosoftApplicationInsights_BaseExtensions",
                            "value": "~1"
                        },
                        {
                            "name": "XDT_MicrosoftApplicationInsights_Mode",
                            "value": "recommended"
                        },
                        {
                            "name": "XDT_MicrosoftApplicationInsights_PreemptSdk",
                            "value": "disabled"
                        }
                    ]
                }
            }
        }
    ],
    ...
}

A couple of things to mention here:

With dependsOn we're able to define dependencies between resources in an ARM template. When deploying the template, the Azure Resource Manager will take care of the dependency graph and create the Azure resources in the correct order
While dependsOn defines the relationship inside the template, serverFarmId sets the actual reference to the App Service Plan instance
We add several app settings entries to enable and configure the Application Insights options

ARM Template Parameters

Our ARM template is now complete. Or is it? Remember the sku parameter for the App Service Plan? Right! We have to create an additional parameters file:

│   ...
│
└───src
    │
    └───azure
    |   |   azuredeploy.json
    |   |   azuredeploy.parameters.json
    |
    └───web
        │   ...

In a real project, we would create a parameters file per environment. But in our example here one is enough. The content of the file is actually quite simple. We can again use a snippet (armp!) to create the skeleton:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
    }
}

Now we just have to define our sku parameter (visit the official documentation for all available plans):

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "appServicePlanSku": {
            "value": "F1"
        }
    }
}

Azure Active Directory Service Principal

There's one thing left to do before we take care of the actual CI/CD pipeline. We need an Azure Active Directory service principal which we have to use for deploying the ARM template. Let's go back to the Azure CLI and do that:

az ad sp create-for-rbac --name sp-dev-blog --role contributor --scopes /subscriptions/xxx-xxx-xxx-xxx-xxx/resourceGroups/rg-dev-blog --sdk-auth

When working in Azure, we should always stick with the principle of least privilege. That's why we assign the contributor role just to the scope of our resource group.

By setting the --sdk-auth parameter, we get back a JSON response which we have to save as a GitHub repository secret:

{
  "clientId": "xxx-xxx-xxx-xxx-xxx",
  "clientSecret": "xxx",
  "subscriptionId": "xxx-xxx-xxx-xxx-xxx",
  "tenantId": "xxx-xxx-xxx-xxx-xxx",
  "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
  "resourceManagerEndpointUrl": "https://management.azure.com/",
  "activeDirectoryGraphResourceId": "https://graph.windows.net/",
  "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
  "galleryEndpointUrl": "https://gallery.azure.com/",
  "managementEndpointUrl": "https://management.core.windows.net/"
}

To do that, we open our GitHub repository, switch to Settings, click Secrets and add the secret there:

We're done now with defining our Azure infrastructure as code. Perfect!

GitHub actions for Azure

GitHub Action workflows are defined in .yml files and stored under .github/workflows:

│   ...
│
│───.github
│   │
│   └───workflows
│       |   azure.yml
│       |   web.yml
|
└───src
    │
    └───azure
    |   |   ...
    |
    └───web
        │   ...

So let's create those folders and the .yml files and start with azure.yml. First, we have to give the workflow a name and define a trigger:

name: Azure

on:
  push:
    paths:
      - 'src/azure/**'
      - '.github/workflows/azure.yml'
    branches:
      - '**'

Since we have our web application and Azure infrastructure as code in the same repository, we don't want to trigger this workflow if something inside the web application changes. That's why we configure a path filter here.

Next, we define some environment variables which we later can reuse in our jobs:

...

env:
  AZURE_RESOURCE_GROUP: 'rg-dev-blog'
  TEMPLATE_FILE: 'src/azure/azuredeploy.json'
  PARAMETERS_FILE: 'src/azure/azuredeploy.parameters.json'

Now we have to define the continuous integration and deployment jobs. For continuous integration, we'd like to execute the following steps:

Checkout source code
Log in to Azure CLI
Validate the ARM template
Execute a what-if command to see, what actually would happen in case of a deployment

And here's the result in our azure.yml file:

...

jobs:
  CI:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: login to Azure
        uses: Azure/login@v1
        with:
          creds: ${{ secrets.AZURE_DEPLOYMENT_CREDENTIALS }}

      - name: validate template
        uses: Azure/cli@v1.0.0
        with:
          inlineScript: 'az deployment group validate --resource-group ${{ env.AZURE_RESOURCE_GROUP}} --template-file ${{ env.TEMPLATE_FILE }} --parameters ${{ env.PARAMETERS_FILE }}'

      - name: what-if
        uses: Azure/cli@v1.0.0
        with:
          inlineScript: 'az deployment group what-if --resource-group ${{ env.AZURE_RESOURCE_GROUP}} --template-file ${{ env.TEMPLATE_FILE }} --parameters ${{ env.PARAMETERS_FILE }}'

Notice the reference to our service principal secrets (${{ secrets.AZURE_DEPLOYMENT_CREDENTIALS }}) when login to the Azure CLI.

The continuous deployment job should behave a little bit different. First, it has only to run if the CI job was successful and if we're on the main branch. Second, there's no need to validate the template and rerun the what-if command. We can simply deploy the template:

jobs:
  CI:
    ...

  CD:
    needs: [CI]
    if: success() && (github.ref == 'refs/heads/main')

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: login to Azure
        uses: Azure/login@v1
        with:
          creds: ${{ secrets.AZURE_DEPLOYMENT_CREDENTIALS }}

      - name: deploy
        uses: Azure/cli@v1.0.0
        with:
          inlineScript: 'az deployment group create --resource-group ${{ env.AZURE_RESOURCE_GROUP}} --template-file ${{ env.TEMPLATE_FILE }} --parameters ${{ env.PARAMETERS_FILE }}'

That's it! If we now commit our workflow file, the actions get triggered. Since we're committing directly to the main branch, the CD action runs and executes our ARM template deployment. To see this in action, we can switch to GitHub and click on the Actions menu:

To verify that all Azure resources have been created successfully, we can run the following Azure CLI command:

az resource list --query "[?resourceGroup=='rg-dev-blog'].{ name: name, resourceType: type }"

The command returns a list of our deployed resources:

[
  {
    "name": "appi-dev-blog",
    "resourceType": "Microsoft.Insights/components"
  },
  {
    "name": "plan-dev-blog",
    "resourceType": "Microsoft.Web/serverFarms"
  },
  {
    "name": "app-dev-blog",
    "resourceType": "Microsoft.Web/sites"
  }
]

GitHub actions for web

One thing left to complete the CI/CD pipeline for our Azure project: a GitHub workflow file for the web application. So let's open the empty web.yml file and define our action. Again, we first start with the name and the trigger:

name: Web

on:
  push:
    paths:
      - 'src/web/**'
      - '.github/workflows/web.yml'
    branches:
      - '**'

Like in the workflow for our Azure infrastructure, this workflow should only get triggered by changes at the web application or the workflow file itself. We continue with some environment variables:

...

env:
  BUILD_CONFIGURATION: Release
  PUBLISH_OUTPUT: web_publish_output
  AZURE_WEBAPP_NAME: app-dev-blog
  WEB_PROJECT: ./src/web/HelloWorld.csproj

The CI job will actually be quite simple:

Check out source code
Set up .NET Core 5
Compile the project

Of course, if we had some unit tests, we would also execute them here:

...

jobs:
  CI:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - name: Setup .NET Core
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: 5.0.100

    - name: build web
      run: dotnet build ${{ env.WEB_PROJECT }}

As in our previous workflow, the CD job should only run if the CI job was successful and if we're on the main branch. Again we check out the source code and set up .NET Core 5. After that, we use the dotnet CLI to publish the web application and deploy it via the Azure CLI:

jobs:
  CI:
    ...

  CD:
    needs: [CI]
    if: success() && (github.ref == 'refs/heads/main')

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Setup .NET Core
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: 5.0.100

      - name: publish web
        run: dotnet publish ${{ env.WEB_PROJECT }} -c ${{ env.BUILD_CONFIGURATION }} -o ${{ env.PUBLISH_OUTPUT }}

      - name: login to azure
        uses: Azure/login@v1
        with:
          creds: ${{ secrets.AZURE_DEPLOYMENT_CREDENTIALS }}

      - name: deploy to azure
        uses: Azure/webapps-deploy@v2
        with:
          app-name: ${{ env.AZURE_WEBAPP_NAME }}
          package: './${{ env.PUBLISH_OUTPUT }}'

After a commit to the main branch, the CI and CD jobs ran successfully, and the web application got deployed:

Conclusion

As we saw in this blog post, it's not that hard to create a simple CI/CD pipeline. Of course, in a real-world project, the pipeline's and ARM templates' size and complexity will grow. That's exactly why it's important to start with them right at the beginning of the project. It's so much harder to set up a CI/CD pipeline when a project already got to a larger size and complexity.

You can find the complete code samples in this GitHub repository.

Keep your Git history clean - 101

Manuel Sidler — Sun, 01 Sep 2019 19:19:40 +0000

Cover photo by JESHOOTS.COM on Unsplash

I've been working with Git for a few years now and admittedly, a clean commit history wasn't always that important to me. As we know from Back to the Future, rewriting history could have some bad consequences. I can only assume that's why it's such a scary topic. In this post I'd like to share the basic commands, which will help you to keep your Git history clean and take away your trauma from Back to the Future ;-)

First things first

All commands in this post will generate new commit hashes and therefore diverge your branch from origin. That means you have to do a force push to overwrite the history on remote with git push --force or git push -f
This in turn means: NEVER change the git history on a shared branch.
There's a safer option that will reject even a force push if the remote branch contains newer commits than your local branch:
git push --force-with-lease

Scenario 1: Add something to your last commit

Everyone has been in a situation like this. You add your changes to the staging area, commit it and wait for a green build. Unfortunately your build fails. Of course, you forgot to add file x. What's coming next? Add file x to the staging area, commit with a message like "stupid me forgot to add file x" aaaaaaaaand STOP! Let me introduce you to our first command:
git commit --amend
This command adds your changes from the staging area to the last commit and gives you the opportunity to change your last commit message. You can also do that with one single command:
git commit --amend -m "new message"
If you don't want to change your last commit message, you can just add the --no-edit parameter:
git commit --amend --no-edit
So no more "stupid me forgot" commits!

Git interactive rebase

For the next few scenarios we're going to use interactive git rebase. This tool helps us to modify changes that are further back in history. You simply start an interactive rebase with the following command:
git rebase -i <base>
Where <base> means how far back you'd like to rewrite your history.
For instance, rewrite last three commits:
git rebase -i HEAD~3
Another example, rewrite history to a specific commit:
git rebase -i 63a2356
The command now shows you the commits and options in your configured editor:

pick bcfd87e add sql scripts for database
pick 9fb0b9c prevent users from changing their email
pick e0b46b9 cleanup web config

# Rebase dfef724..e0b46b9 onto dfef724 (3 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

Let's jump into the first rebase scenario.

Scenario 2: Add something to an arbitrary commit in your history

Like in scenario 1 you forgot to add something to your commit. But instead of adding it to your last commit, you'd like to amend that change to a commit further away in history. For such a case, interactive rebase provides us the edit option.
We start with the interactive rebase command (see above) and set the edit command on the commit we'd like to change:

pick bcfd87e add sql scripts for database
edit 9fb0b9c prevent users from changing their email
pick e0b46b9 cleanup web config

Interactive rebase now stops at this commit and you're able to add your changes:

Stopped at 9fb0b9c...  prevent users from changing their email
You can amend the commit now, with

  git commit --amend 

Once you are satisfied with your changes, run

  git rebase --continue

After you're done you simply add the changes to the staging area and commit them with the amend command:
git commit --amend
Almost done! Now we have to continue the interactive rebase:
git rebase --continue

Scenario 3: Merge commits

I try to commit as often as possible. That means my git history in a feature branch usually looks something like this:

9edf77a more review findings
67b5e01 review findings
940778d enable users to change their name
dc6b0db enable users to change their name
dfdd77d wip

That may be useful during feature development, but it's not for the overall git repository history. Therefore I'd like to merge all commits into one. There are two options to do this: squash and fixup. Both commands meld a commit into the previous one. The only difference is that squash lets you provide an option to write a new commit message while fixup discards the message.
So let's squash some commits. We start the interactive rebase like we did before and set the appropriate options:

pick dfdd77d wip
squash dc6b0db enable users to change their name
squash 940778d enable users to change their name
squash 67b5e01 review findings
squash 9edf77a more review findings

# Rebase 63a2356..9edf77a onto 63a2356 (5 commands)

Git now provides an overview with all messages:

# This is a combination of 5 commits.
# This is the 1st commit message:

wip

# This is the commit message #2:

enable users to change their name

# This is the commit message #3:

enable users to change their name

# This is the commit message #4:

review findings

# This is the commit message #5:

more review findings

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.

We remove all lines and write just the message we'd like to have in the end:

enable users to change their name

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.

And voilà, we have squashed our commits into one:

cb88cf6 enable users to change their name

We can do the same with the fixup command. In the scenario below I'm happy with the commit message where I'd like to meld my commits into:

pick dc6b0db enable users to change their name
fixup dfdd77d wip
fixup 940778d enable users to change their name
fixup 67b5e01 review findings
fixup 9edf77a more review findings

# Rebase 63a2356..9edf77a onto 63a2356 (5 commands)

The result is the same like the squash example above:

b8e76d1 enable users to change their name

Scenario 4: Split commit

Now and then we tend to commit two or more different topics into one:

7080968 add sql scripts for database
172db2b prevent user from changing their email and cleanup web config

In this case it would be a lot cleaner to separate the cleanup of our web config, wouldn't it? At this point we can take advantage from the edit command again. Let's start the interactive rebase session and do that:

pick 7080968 add sql scripts for database
edit 172db2b prevent user from changing their email and cleanup web config

# Rebase dfef724..172db2b onto dfef724 (2 commands)

As you expect, Git stops at our commit. Now we can take back our changes into the working area:
git reset HEAD~
The rest is straightforward, just create two commits for our changes:
git add [files]
git commit -m "prevent user from changing their email"
git add [files]
git commit -m "cleanup web config"
Don't forget to continue the rebase session:
git rebase --continue
Let's see the result:

9fb0b9c prevent user from changing their email
dfef724 cleanup web config
7080968 add sql scripts for database

Neat!

Scenario 5: Reorder commits

What if you'd like to merge two or more commits and they're not in order?

09f43c9 validate user inputs
62490ed import user data
c531f57 validate user inputs

You simply reorder the commits inside the rebase editor. After that you can use the fixup or squash option to merge them.

pick 62490ed import user data
pick c531f57 validate user inputs
fixup 09f43c9 validate user inputs

# Rebase 6c70ff2..09f43c9 onto 6c70ff2 (3 commands)

Scenario 6: Change commit message

Not satisfied with a specific commit message? With help of the reword command you can always change it:

reword c531f57 validate user inputs
pick 62490ed import user data

# Rebase 6c70ff2..09f43c9 onto 6c70ff2 (3 commands)

Git will stop at this commit and you have the option to change the message:

validate user inputs

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.

Scenario 7: Drop commit

Need to revert a specific commit completely? For such a scenario we can use the drop command:

pick bcfd87e add sql scripts for database
drop 9fb0b9c prevent users from changing their email
pick e0b46b9 cleanup web config

# Rebase dfef724..e0b46b9 onto dfef724 (3 commands)

Here, at the latest, here you can see why it's important to keep your Git history clean. Imagine you've put different features into one commit or split up a feature into multiple (pointless) commits. A revert would be much more complicated.

When something's going wrong

Don't worry about breaking something when rewriting your Git history.
First, you can always abort an interactive rebase session with git rebase --abort
This command will stop the rebase session and revert all changes you already made.
Second, even if you've completed a rebase and messed it up somehow, you can revert it. Git (luckily) keeps track of all your commands that you execute. You open this log with git reflog

e0b46b9 (HEAD -> feature/my2, feature/my3) HEAD@{34}: rebase -i (finish): returning to refs/heads/feature/my2
e0b46b9 (HEAD -> feature/my2, feature/my3) HEAD@{35}: commit: cleanup web config
9fb0b9c HEAD@{36}: commit: prevent users from changing their email
bcfd87e HEAD@{37}: reset: moving to HEAD~
3892bc7 HEAD@{38}: rebase -i: fast-forward
bcfd87e HEAD@{39}: rebase -i (start): checkout master
3892bc7 HEAD@{40}: rebase -i (finish): returning to refs/heads/feature/my2
3892bc7 HEAD@{41}: commit (amend): prevent user from changing their email and cleanup web config
39262b5 HEAD@{42}: rebase -i: fast-forward
bcfd87e HEAD@{43}: rebase -i (start): checkout master
39262b5 HEAD@{44}: rebase -i (abort): updating HEAD
39262b5 HEAD@{45}: rebase -i (abort): updating HEAD
bcfd87e HEAD@{46}: reset: moving to HEAD~
39262b5 HEAD@{47}: rebase -i: fast-forward
bcfd87e HEAD@{48}: rebase -i (start): checkout master
39262b5 HEAD@{49}: rebase -i (finish): returning to refs/heads/feature/my2
39262b5 HEAD@{50}: rebase -i (pick): prevent user from changing their email and cleanup web config
bcfd87e HEAD@{51}: commit (amend): add sql scripts for database
7080968 HEAD@{52}: rebase -i: fast-forward
dfef724 (master) HEAD@{53}: rebase -i (start): checkout master
172db2b (feature/my) HEAD@{54}: checkout: moving from feature/my to feature/my2
172db2b (feature/my) HEAD@{55}: commit: prevent user from changing their email and cleanup web config
7080968 HEAD@{56}: commit: add sql scripts for database
dfef724 (master) HEAD@{57}: checkout: moving from master to feature/my
dfef724 (master) HEAD@{58}: commit (initial): init

Now you can search for your last action before starting the interactive rebase session and revert back to that state. For instance:
git reset --hard HEAD@{18}

So, let's fight against our fear and keep our Git history clean! :-)

Short introduction to Discriminated Unions in F#

Manuel Sidler — Sun, 05 May 2019 19:28:13 +0000

Cover photo by Ilija Boshkov on Unsplash

The last few months I've been trying to get my head around F#. If you'd like to start learning F# I can highly recommend Get Programming with F# by Isaac Abraham, especially when you have a background in C# like I do.
Today I've learned something about Discriminated Unions in F#. You use a DU when you have to model an is-a relationship.
But first things first, how does such a relationship look like in an object oriented language like C#?

public abstract class Animal
{
    public abstract string Talk();
}

public class Dog : Animal
{
    public override string Talk()
    {
        return "Woof!";
    }
}

public class Cat : Animal
{
    public bool IsAggressive { get; set; }

    public override string Talk()
    {
        return IsAggressive
            ? "MEEEEEEEEOOOOOOOW!!!"
            : "Meow";
    }
}

// usage
var dog = new Dog();
dog.Talk(); // Woof!

var cat = new Cat();
cat.Talk(); // Meow

var aggressiveCat = new Cat { IsAggressive = true };
aggressiveCat.Talk(); // MEEEEEEEEOOOOOOOW!!!

And now let's see the equivalent in F#:

type Animal = // base type
    | Dog // no custom fields
    | Cat of IsAggressive:bool // add custom field

// add function with the help of pattern matching
let talk animal =
    match animal with
    | Dog -> "Woof!"
    | Cat aggressive when aggressive = true -> "MEEEEEEEEOOOOOOOW!!!"
    | Cat _ -> "Meow"

// usage

let dog = Dog
dog |> talk // Woof!

let cat = Cat false
cat |> talk // Meow

let aggressiveCat = Cat true
aggressiveCat |> talk // MEEEEEEEEOOOOOOOW!!!

Pretty neat, isn't it?
What I really like about the F# approach is that I'm able to see the whole type hierarchy at a glance. Of course it's technically possible to put all C# classes into one file. But then you would certainly follow the "One class per file" convention ;-)

You can read more about Discriminated Unions on F# for fun and profit or Microsoft Docs.

How to stay up to date as a Software Developer

Manuel Sidler — Wed, 01 May 2019 19:15:03 +0000

Cover photo by Alexis Brown on Unsplash

Being a software developer is great. But being a software developer is also hard. Whilst I'm writing this post and you're reading it, there will probably be dozens of new frameworks, libraries, tools and methodologies announced. That's one of the most interesting part of our job. But from time to time it's just overwhelming and I get FOMO.

Photo by Alexander Lam on Unsplash

Am I going to miss something important? How do I stay up to date as a software developer?

In the last few years I've been using the following strategies for myself:

See what's going on and get the big picture
Dive into something a little deeper
Use it in a real project

1. See what's going on and get the big picture

To see what's going on I primarily use the following medias:

Twitter
RSS Feeds
dev.to
Podcasts (eg. Dotnetrocks, Hanselminutes)
Newsletters (eg. JavaScript Weekly)
Meetup group and conference lists

Even if you just scroll through your timeline, RSS or podcast feeds, meetup groups and conference lists, you'll get a feeling about what's going on and get the bigger picture in your head. When I stumble over an interesting tweet, RSS feed, dev.to article or a link in a newsletter, I save it on Pocket. I take notes about interesting meetups and conferences and put them into my calendar.

2. Dive into something a little deeper

Packed with the bigger picture in my head and a collection of interesting articles, blogs and other things in my Pocket, I'm able to dive deeper into a specific topic. I read blog posts and docs. I listen to podcasts. I join meetup groups and attend conferences. In case of a very interesting topic, be it personal interest or for a specific project at my job, I dig deeper into it by means of a book or a Pluralsight video. And last but not least, I play with it in code.

3. Use it in a real project

Videos, podcasts, books, blogs and code playgrounds are all great ways to learn something new. But if you really like to know that stuff, you have to get your hands dirty! That means I try to use something I learned in a real world project at my job, even if it's risky sometimes.

Conclusion

You may notice that my strategy heavily depends on free content provided by other people. I'm really thankful and I have a lot of respect for these women and men. Thank you!
I'm trying to make my contribution to the community and to my co-workers in form of blog posts, brown bag sessions and hopefully soon speaking at a local meetup group :-)

But now I'm interested about you. What's your strategy? How do you stay up to date as a software developer?

Setup your Azure Search with PowerShell

Manuel Sidler — Tue, 26 Mar 2019 11:39:17 +0000

Microsoft provides cmdlets through Azure PowerShell and a REST API to manage your Azure Search resource.

In this scenario we need a Azure Search service which will:

extract storage metadata from an Azure Blob container
store the metadata inside an index
provide a custom key to query our index

To fullfil these requirements we're going to use a combination of the Azure PowerShell cmdlets and REST API endpoints to setup an Azure Search with the following components:

Azure Search service
Search query key
Search index connected to an Azure Blob storage

In order to achieve this, we're going to take these steps:

Define common variables
Login to Azure
Create search service
Create search query key
Get search primary admin key
Create index
Create data source
Create indexer

Prerequisites

Azure subscription
Resource group
Storage account with a Blob container
Installed Azure PowerShell module

Variables

First of all we need to define some variables which we'll use throughout the upcoming steps.

$tenantId = "<tenantId>" # eg. 12133905-3bce-414e-983f-79013911deee
$subscriptionId = "<subscriptionId>" # eg. 510f6c5b-b136-45e7-b239-dccb600331ea
$resourceGroup = "<resourceGroup>" # eg. my-project
$location = "<location>" # eg. WestEurope
$storageAccountName = "<storageaccount>" # eg. myprojectstorage
$searchName = "<searchName>" # eg. my-project-search

Login

To get access to our Azure resources we need to connect to our Azure account:

Connect-AzAccount -Tenant $tenantId -Subscription $subscriptionId

This cmdlet will open a popup where you can enter your credentials for your Azure account.

Create search service

Assuming the login was successful we're now able to create the search service:

$sku = "Free" # Free|Basic|S1|S2|S3|S3-HD
New-AzSearchService -Name $searchName -ResourceGroupName $resourceGroup -Sku $sku -Location $location

Create search query key

We also need an additional search query key in our scenario:

$queryKey = "MyQueryKey"
New-AzSearchQueryKey -Name $queryKey -ServiceName $searchName -ResourceGroupName $resourceGroup

Get search primary admin key

Unfortunately Azure PowerShell doesn't provide cmdlets to manage your search indexes, indexers and data sources. To create these resources we'll put the Azure REST API into action. But first we need to fetch the search primary admin key which we're going to use as an API key:

$adminKeyPair = Get-AzSearchAdminKeyPair -ResourceGroupName $resourceGroup -ServiceName $searchName
$primaryAdminKey = $adminKeyPair.Primary

Create index

Instead of using a variable for the index definition, I would like to store it as JSON inside a folder. Once we stored the index definition, we can iterate through them when actually calling the Create Index endpoint. We're going to keep this index as simple as possible. Fields:

ID (Primary Key)
Title
Tags (Filterable Collection)
metadata_storage_path (Path of the Blob)

/indexes/myindex.json

{
    "name": "my-index",  
    "fields": [
        {"name": "ID", "type": "Edm.String", "key": true, "filterable": false, "sortable": false, "facetable": false, "searchable": false},
        {"name": "TITLE", "type": "Edm.String", "filterable": false, "sortable": false, "facetable": false, "searchable": false},
        {"name": "TAGS", "type": "Collection(Edm.String)", "filterable": true, "sortable": false, "facetable": false, "searchable": false},
        {"name": "metadata_storage_path", "type": "Edm.String", "filterable": false, "sortable": false, "facetable": false, "searchable": false}
    ]
}

With our definition we're now able to create our index:

Get-ChildItem "indexes" -Filter *.json |
        ForEach-Object {
            $indexDefinition = Get-Content $_.FullName -Raw

            $headers = @{
                'api-key' = $primaryAdminKey
                'Content-Type' = 'application/json' 
                'Accept' = 'application/json' }

            $url = "https://$searchName.search.windows.net/indexes?api-version=2017-11-11"

            Invoke-RestMethod -Uri $url -Headers $headers -Method Post -Body $indexDefinition | ConvertTo-Json
        }

Create data source

We take the same approach for creating the data source. But in this case we need to set the connection string from our storage account. As we're good developers we won't store the string inside the data source JSON definition ;-)

/datasources/mydatasource.json

{   
    "name" : "my-datasource",
    "type" : "azureblob",
    "credentials" : { 
        "connectionString" : "[STORAGECONNECTION]" 
    },  
    "container" : { 
        "name" : "myblobcontainer" 
    }
}

To replace the STORAGECONNECTION placeholder we first need to fetch the connection string:

$storageKey = (Get-AzStorageAccountKey -Name $storageAccountName -ResourceGroupName $resourceGroup)[0].Value

$storageConnectionString = "DefaultEndpointsProtocol=https;AccountName=$storageAccountName;AccountKey=$storageKey;EndpointSuffix=core.windows.net"

With the storage connection string available we now can iterate through the data source folder and use the Create Data Source endpoint to create the data source:

Get-ChildItem "datasources" -Filter *.json |
        ForEach-Object {
            $datasourceDefinition = (Get-Content $_.FullName -Raw).replace("[STORAGECONNECTION]", $storageConnectionString)

            $headers = @{
                'api-key' = $primaryAdminKey
                'Content-Type' = 'application/json' 
                'Accept' = 'application/json' }

             $url = "https://$searchName.search.windows.net/datasources?api-version=2017-11-11"

             Invoke-RestMethod -Uri $url -Headers $headers -Method Post -Body $dataSourceDefinition | ConvertTo-Json
        }

Create indexer

Last but not least we have to create an indexer. Again we use a JSON file to define the indexer. What's important here is that in our scenario we just want to index the storage metadata. You could also choose to extract all metadata or the file content.

/indexers/myindexer.json

{
    "name" : "my-indexer",
    "dataSourceName" : "my-datasource",
    "targetIndexName" : "my-index",
    "schedule" : {
        "interval" : "PT1H"
    },
    "parameters" : {
        "configuration" : {
            "dataToExtract" : "storageMetadata"
        }
     }
}

To create the indexer we're going to use the Create Indexer endpoint:

Get-ChildItem "indexers" -Filter *.json |
        ForEach-Object {
            $indexerDefinition = Get-Content $_.FullName -Raw

            $headers = @{
                'api-key' = $primaryAdminKey
                'Content-Type' = 'application/json' 
                'Accept' = 'application/json' }

            $url = "https://$searchName.search.windows.net/indexers?api-version=2017-11-11"

            Invoke-RestMethod -Uri $url -Headers $headers -Method Post -Body $indexerDefinition | ConvertTo-Json
        }

Conclusion

We now have an Azure Search service which:

provides a custom key to query our index
extracts storage metadata from an Azure Blob container
stores the metadata inside an index