Serverless: Testing and DevOps

The following post is part of a series of articles chronicling my journey into serverless implementation via a sample Case Study using a minimal viable product (MVP). TL; DR the source code used for the implementation and instructions on how to run the app locally are on GitHub.

One of the challenges for testing serverless implementation is integration with third-party libraries, in this case, the Twilio API. Even though unit tests could catch code related issues early on the development cycle to truly test the application end-to-end locally there needs to be a way to call into the Twilio API without deploying the function in Azure. Here is where the Visual Studio (VS) Function debugger and ngRok come in handy.

To test application end-to-end:

1. Clone the Git Repo and follow the instructions on the GitHub page to set up your environment
2. Run VS debugger (F5) and check the port that the application is running under (usually 7071)
3. Download ngRok and run the command
4. `ngRok http 7071`
5. Jot down the public web endpoint (note the /api/ URL needs to be in the webhook link)
6. Update Twilio set up for the number you are using to redirect text messages to the public API from ngRoc

Now you can send a text message to your Twilio number and see the Http request come through to your local VS debugger session.

DevOps

If the code is hosted in Azure DevOps, creating a pipeline to build, stage, and deploy the function from git repo will be easier with templates provided in Azure DevOps Pipelines.

You will need to first associate your AzureDevOps account with your Azure subscription and then from your project pipeline create a new Azure Function Pipeline and point it to your Azure subscription.

I have found that the default settings work except for two minor updates.

1. I needed to update the release path in the YAML file from

`--output $(System.DefaultWorkingDirectory)/publish_output --configuration Release` to `--output $(Build.BinariesDirectory) --configuration Release`

At the time of this writing, the function pipeline template by default puts your build artifact in a location that will not be accessible during releases. The updates above fixes the issue (I hope this will be fixed in Azure DevOps in the future).

2. The pipeline template provides a step for building the application from source and releasing it into my Azure Function resource in one pipeline; however, for a flexible DevOps planning, and not to violate the DevOps maxim of build once deploy anytime I needed to break the pipeline into two separate processes.

I removed the deployment stage that is auto-generated in the YAML file (it starts with the text `stage: Deploy …` and saved the rest of my YAML steps as my build pipeline and went to the release area in Azure DevOps to define my environment targets and releases (which only requires following steps in the UI to configure).

At the end of those two minor updates, I now have a build pipeline that takes care of building my projects whenever a change is committed to the master branch. If the build passes, I have set up triggers so that the build artifact gets automatically deployed to Stating . Deployments to Prooduction is manual so that I can test the updates on Staging before promoting a build artifact to production. I don’t have to worry about managing data during deployments as the data contained in each environment is not impacted by function upgrades.