Skip to content
Permalink
Browse files

moving tracking code to shortcode

  • Loading branch information...
aaronpowell committed Mar 10, 2019
1 parent d42954b commit 893b67ca4575f4a636c970c9dcf869ab9ef43926
@@ -25,7 +25,7 @@ We won't build anything particularly complex, the Go support is experimental at

## Getting Setup

The first thing you'll need to do is to setup a development environment. Go works on all major operating systems and I've used Windows + [Windows Subsystem for Linux (WSL)](https://docs.microsoft.com/en-us/windows/wsl/about?WT.mc_id=aaronpowelldotcom-blog-aapowell). My colleague Scott Coulton has written how to setup a [WSL dev environment, including Go](https://medium.com/devopslinks/windows-for-a-linux-guy-823276351826) that I followed.
The first thing you'll need to do is to setup a development environment. Go works on all major operating systems and I've used Windows + [Windows Subsystem for Linux (WSL)](https://docs.microsoft.com/en-us/windows/wsl/about?{{< cda >}}). My colleague Scott Coulton has written how to setup a [WSL dev environment, including Go](https://medium.com/devopslinks/windows-for-a-linux-guy-823276351826) that I followed.

~~One thing I will note is that I haven't managed to get code completion working in VSCode at the moment, something seems incorrect in the way I've setup my `GOPATH` and `GOROOT`, but so far it hasn't been _too_ painful for me to work without code completion.~~ Once I got my `GOPATH` and `GOROOT` set properly and defined as environment variables in both Windows and Linux (WSL) it worked fine.

@@ -210,7 +210,7 @@ Using the `|` tells TypeScript that the arguments into the function are a string

We're done! It works locally! Now it's time to deploy it somewhere.

I'm going to use [Azure DevOps Pipelines](https://azure.microsoft.com/en-au/services/devops/?WT.mc_id=aaronpowelldotcom-blog-aapowell) to build and then deploy it as an [Azure Blob Static Website](https://docs.microsoft.com/en-au/azure/storage/blobs/storage-blob-static-website?WT.mc_id=aaronpowelldotcom-blog-aapowell).
I'm going to use [Azure DevOps Pipelines](https://azure.microsoft.com/en-au/services/devops/?{{< cda >}}) to build and then deploy it as an [Azure Blob Static Website](https://docs.microsoft.com/en-au/azure/storage/blobs/storage-blob-static-website?{{< cda >}}).

### Building

@@ -221,7 +221,7 @@ To build you'll need to run the following steps:
* Run webpack
* Copy the required files as a build artifact

I've created an [Azure DevOps YAML build](https://docs.microsoft.com/en-us/azure/devops/pipelines/get-started-yaml?view=azdevops&WT.mc_id=aaronpowelldotcom-blog-aapowell) that is in the [GitHub repo](https://github.com/aaronpowell/go-wasm-experiments/blob/master/azure-pipelines.yml). It's modeled on the standard Node.js pipeline but I've added the specific Go steps.
I've created an [Azure DevOps YAML build](https://docs.microsoft.com/en-us/azure/devops/pipelines/get-started-yaml?view=azdevops&{{< cda >}}) that is in the [GitHub repo](https://github.com/aaronpowell/go-wasm-experiments/blob/master/azure-pipelines.yml). It's modeled on the standard Node.js pipeline but I've added the specific Go steps.

The things of note are that you'll need to install the appropriate Go packages with `go get`. To use the `gobridge` I created for the loader you'll need to set the `GOOS` and `GOARCH` too:

@@ -253,7 +253,7 @@ variables:

### Release

At the time of writing we don't have support for releases in the YAML file for Azure DevOps Pipelines. I use the [Azure File Copy task](https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-file-copy?view=azdevops&WT.mc_id=aaronpowelldotcom-blog-aapowell) to copy all the files into the storage account I'm running in, followed by the [Azure CLI task](https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-cli?view=azdevops&WT.mc_id=aaronpowelldotcom-blog-aapowell) to set the WASM content type on the WASM file, otherwise it won't be served correctly:
At the time of writing we don't have support for releases in the YAML file for Azure DevOps Pipelines. I use the [Azure File Copy task](https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-file-copy?view=azdevops&{{< cda >}}) to copy all the files into the storage account I'm running in, followed by the [Azure CLI task](https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-cli?view=azdevops&{{< cda >}}) to set the WASM content type on the WASM file, otherwise it won't be served correctly:

```shell
az storage blob update --container-name "$web" --name "hello.wasm" --content-type "application/wasm" --account-name gowasm
@@ -8,7 +8,7 @@ tags = ["javascript", "azure-devops"]

In my recent article about [creating a webpack loader to generate WebAssembly with Go]({{< ref "/posts/2019-02-08-golang-wasm-5-compiling-with-webpack.md" >}}) I decided I wanted to be able to easily release the loader to npm as I was building it.

To do this I decided that I was going to use [Azure DevOps](https://azure.microsoft.com/en-au/services/devops/?WT.mc_id=aaronpowelldotcom-blog-aapowell) as it gives me a nice separation between the build phase and the release phase. Also, a lot of people are unaware that Azure DevOps pipelines are free for open source projects, so again there's a nice little bonus that we can leverage for our project.
To do this I decided that I was going to use [Azure DevOps](https://azure.microsoft.com/en-au/services/devops/?{{< cda >}}) as it gives me a nice separation between the build phase and the release phase. Also, a lot of people are unaware that Azure DevOps pipelines are free for open source projects, so again there's a nice little bonus that we can leverage for our project.

## Creating a build

@@ -83,7 +83,7 @@ We've now generated a `tgz` file, next we need to attach it as an artifact to th
displayName: 'Publish npm artifact'
```

Using the [Copy Files](https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/copy-files?view=azure-devops&tabs=yaml&WT.mc_id=aaronpowelldotcom-blog-aapowell) task we can get the files (our `tgz` and our `package.json`) and copy them across to the _artifacts staging location_ defined by the variable `$(Build.ArtifactStagingDirectory)`. This is a special directory that the agent has that's intended to by published as artifacts. Once these files are in the right place we use the [Publish Artifacts](https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/publish-build-artifacts?view=azure-devops&WT.mc_id=aaronpowelldotcom-blog-aapowell) task to tell our build the files in the folder will be in a _named artifact_ of `npm`. This name is important as we'll use it in the future to access them, so make it something logical. I'll also avoid using spaces in the name of the artifact so that you don't have to do escaping when you try and use them.
Using the [Copy Files](https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/copy-files?view=azure-devops&tabs=yaml&{{< cda >}}) task we can get the files (our `tgz` and our `package.json`) and copy them across to the _artifacts staging location_ defined by the variable `$(Build.ArtifactStagingDirectory)`. This is a special directory that the agent has that's intended to by published as artifacts. Once these files are in the right place we use the [Publish Artifacts](https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/publish-build-artifacts?view=azure-devops&{{< cda >}}) task to tell our build the files in the folder will be in a _named artifact_ of `npm`. This name is important as we'll use it in the future to access them, so make it something logical. I'll also avoid using spaces in the name of the artifact so that you don't have to do escaping when you try and use them.

I'll also copy across the release notes as well as the JavaScript files we generate from the TypeScript compiler as these can be useful for debugging.

@@ -99,11 +99,11 @@ Within the Azure DevOps portal we'll create a new release, use the **Empty Job**

![Our blank release](/images/npm-azd/blank-release.jpg)

Now we need to define what the stages that our release will go through. A stage can represent an environment, so if you are releasing to UAT then Pre Prod and finally Production you'd have them all mapped out in the build. You can also define gates on each stage, whether there are approvers of a stage release, etc. but all of that is beyond what we need here, we've only got one stage, that's releasing to npm. Check out the [docs for more info on Stages](https://docs.microsoft.com/en-us/azure/devops/pipelines/release/environments?view=azure-devops&WT.mc_id=aaronpowelldotcom-blog-aapowell).
Now we need to define what the stages that our release will go through. A stage can represent an environment, so if you are releasing to UAT then Pre Prod and finally Production you'd have them all mapped out in the build. You can also define gates on each stage, whether there are approvers of a stage release, etc. but all of that is beyond what we need here, we've only got one stage, that's releasing to npm. Check out the [docs for more info on Stages](https://docs.microsoft.com/en-us/azure/devops/pipelines/release/environments?view=azure-devops&{{< cda >}}).

Conveniently there's a `npm` task provided by Azure DevOps that has some common commands defined, including the one we want, `publish`! Specify the path to our linked artifact named `npm` (which we named above) and choose to publish to an **External npm registry** (we use that because Azure DevOps can act as a npm registry).

If you haven't done so previously you'll need to create a [service connection](https://docs.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints?view=azure-devops&WT.mc_id=aaronpowelldotcom-blog-aapowell#sep-npm) to the npm registry, use the **New** button for that and enter `https://registry.npmjs.org` as the source and a token that you can generate from the npm website under your profile.
If you haven't done so previously you'll need to create a [service connection](https://docs.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints?view=azure-devops&{{< cda >}}#sep-npm) to the npm registry, use the **New** button for that and enter `https://registry.npmjs.org` as the source and a token that you can generate from the npm website under your profile.

Now you'd think we'd be ready to roll right? Well... yes you do publish to npm but what you publish is a package that _contains_ your `tgz`, not your `tgz`. You see, the `publish` command is capable of taking a `tgz` and publishing that to npm but there's a [bug in the Azure DevOps task](https://github.com/Microsoft/azure-pipelines-tasks/issues/4958) that means it doesn't work. So unfortunately we'll need a workaround 😦.

@@ -6,17 +6,17 @@ draft = false
tags = ["fsharp", "azure-functions"]
+++

I'm starting to work on a new project in which I'm going to use [Azure Functions v2](https://docs.microsoft.com/en-us/azure/azure-functions/?WT.mc_id=aaronpowelldotcom-blog-aapowell) for a simple API backend.
I'm starting to work on a new project in which I'm going to use [Azure Functions v2](https://docs.microsoft.com/en-us/azure/azure-functions/?{{< cda >}}) for a simple API backend.

Azure Functions support a number of different languages such as [Java](https://azure.microsoft.com/en-us/blog/announcing-the-general-availability-of-java-support-in-azure-functions/), [Python (in preview at time of writing)](https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-first-function-python?WT.mc_id=aaronpowelldotcom-blog-aapowell), [TypeScript (and naturally JavaScript)](https://azure.microsoft.com/en-us/blog/improving-the-typescript-support-in-azure-functions/) and of course C#. So with all those to pick from what would I want to choose?
Azure Functions support a number of different languages such as [Java](https://azure.microsoft.com/en-us/blog/announcing-the-general-availability-of-java-support-in-azure-functions/), [Python (in preview at time of writing)](https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-first-function-python?{{< cda >}}), [TypeScript (and naturally JavaScript)](https://azure.microsoft.com/en-us/blog/improving-the-typescript-support-in-azure-functions/) and of course C#. So with all those to pick from what would I want to choose?

Well, naturally I decided to go with F#, which _kind of_ worked in v1. And after all, it's a CLR language so there's no reason it shouldn't work in v2 like C# does.

But unfortunately there's no templates available, so getting started seems to be a bit trickier.

## Creating an F# Functions Application

To create a F# Functions Application the easiest approach is to follow the [Visual Studio Code instructions](https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-first-function-vs-code?WT.mc_id=aaronpowelldotcom-blog-aapowell) to get the extensions installed.
To create a F# Functions Application the easiest approach is to follow the [Visual Studio Code instructions](https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-first-function-vs-code?{{< cda >}}) to get the extensions installed.

Once VS Code is ready to go we'll create a new [New Functions Project](https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-first-function-vs-code#create-an-azure-functions-project) choosing C# as the language.

@@ -0,0 +1 @@
WT.mc_id=aaronpowell-blog-aapowell

0 comments on commit 893b67c

Please sign in to comment.
You can’t perform that action at this time.