Tag Archives: GitHub

Copying an Azure Function App using the Portal, GitHub and Cloud Shell

I’ve got an Azure Function App with some functions that I built for a demo for a conference session. I first used this at AngularMix and had named the function app AngularMix2017. Then when I did it for DevIntersection this past week, I recreated it as DevIntersection2017 because you can’t rename a function app. I’m doing it yet again next week at another conference (NetConf.co) and decided it was time to create it as a reusable name: DataApiDemo.

While you can’t flat out copy a function app if you are working strictly in the portal (which is how I’ve been working during my first learning stages of building function apps), you can easily enough duplicate it by downloading and uploading it again.

Keep in mind that if you are developing functions in VS 2017 or VS Code (combined with the Azure CLI) you can just use the tooling to publish the function apps along with the settings. But I don’t like to take the easy path. I learned a lot of new tricks and tools by going this route. Even if I leverage the tooling on my next go round, I’ve learned a lot which gives me a better understanding overall, more control and troubleshooting skills.

My first step was to create the new function app (dataapidemo).

The Overview blade of an Azure function app has a “download app content” option. That will pull down all of the relevant files onto your machine. So next, I go to the overview of the DevIntersection2017 function app and click on the download app content link.

When downloading the app content, you have an option to also grab the app settings. I have a number of secrets stored in my settings ..things like keys to my databases , account ids and more. If you check that, the settings will get downloaded to a local settings file. If you were using this feature to continue your development locally, e.g. in VS2017, then you’ll want them. But for my scenario, they are not useful and even potentially a security issue (you’ll see shortly) so I’m going to leave that unchecked.

I can see the files in the designated folder on my computer.

I’ve already created a Github repository to store these files in: https://github.com/julielerman/DataApiAzureFunctions.

At the command line in the new folder, I’ll git init, add all of the files into the local repo and commit them. Then I can run the git commands to connect that folder to my GitHub repo and then push my local repository into the online repository.

When that’s complete, the files are all in my GitHub repo.

Since I’m using a public repository, this is why I didn’t want the local.settings.json file filled with my secrets to download. Of course I could have deleted it locally or told Git to ignore that file. A few other points about this. If I were developing this locally, then I can have that file locally and use VS2017 or Azure CLI tools to publish my app along with the settings to the portal. But that is not my goal here.

Now I can take advantage of a long-time feature of the Azure Portal: connect it to a repository to auto-deploy from the repository to my app (in the case to my function app).

Back in the portal, I select the new function app again, then from its Platform Features page, open the Deployment Options. Choose Setup new deployment and follow the steps to connect the function app to your repository. When you’ve completed the setup, you can use the Sync button to force the deployment to happen. All of the files are now in my new dataapidemo function, including the function.json files that contain the function setting (e.g. integrations etc) and any other files I may have added to my functions.

Because I am using Twilio, one of my functions has a reference to Twilio in a project.json file and I need to restore that package to this function app. I did that by opening up the project.json and making a small mod to it..adding or removing a blank line, then saving it. That triggers the package restore to happen.

What’s not there however are the function app settings. These are settings that are defined to the app and used by one or more of the functions. There are some default settings created by Azure but I also have some others …those secrets, such as the account and telephone number for my Twilio integration as well as a key for the function.

Some of these settings are my own custom settings that I want in the new function. I could add them in via the portal app settings interface, but I don’t like that path when I have a slew of settings.

That means moving on to yet another amazing tool in the Azure Portal — Cloud Shell. Here you can run Bash or Powershell commands from the Azure CLI directly on services in your subscription. You can also do this locally on your machine with the extra caveat that there you must provide credentials and other metadata.

In the portal, open the Cloud Shell. This is gives you an interactive terminal window.

If you have multiple subscriptions, you want to be sure that it’s set to the one where your app function is stored.

You can do this by listing the subscriptions with the az account list command.

If the one you want is not default, then set it with:

az account set -s [ID]

This shell can do auto-complete so if the id starts with a123, you can type

az account set -s a123

then hit the tab and the id will get finished . Hit enter and it becomes the default subscription to work in.

I’ll use the azure functionapp commands to get the settings into my function app.

First I’ll list the existing settings. You do this with the command

az functionapp config appsettings list --name [functionname] --resource-group [resource name]

The parameter shortcuts for name and resource-group are -n and -g. Mine are both the same name: dataapidemo. Here’s what the command looks like (except for the wrapping that my blog is forcing):

az functionapp config appsettings list -n dataapidemo -g dataapidemo

The appsettings are listed out as JSON by default although you can affect the output format with the output parameter.

I’ll need to see the settings I want to copy from the other function app so I run:

az functionapp config appsettings list -n devintersection2017 -g devintersection2017 -o tsv

which give me the list of settings from which to choose.

In addition to listing the settings, you can add new ones with the set verb and delete with delete verb. Both would go in place of the verb list.

You use SET by combining the SET command and the –settings parameter. After the –settings parameter, you can list one or more setting with this format:

az functionapp config appsettings set -n dataapidemo -g dataapidemo --settings "property1name=value", "property2name=value"

Note that this is wrapping here on the blog post but not in the shell window.

So I added the handful of settings I wanted to add which looked more like:

az functionapp config appsettings set -n dataapidemo -g dataapidemo --settings "TwilioSID=myvalue", "TwilioAccount=myvalue"

There were others I had to add. For example, my function needs to know how to get to my Cosmos DB document database, so it has a setting that uses the db name as the property name and the dbs account endpoint as the value.

Once I had done that, I was able to get rid of the function apps that were named for each conference and use a common one no matter where I am sharing it.

And boyohboy did I learn a lot of new things!

Cloning a GitHub Repo in Visual Studio 2017 …and a Quiz

When showing off some VS2017 features at our VTdotNET meetup, I made a last minute decision to demo the ability to clone a repository right from GitHub. Then I thought I would combine that with other things I planned to demo.

I already had just the right repo sitting in my GitHub account. A small ASP.NET Core project that was built with Visual Studio 2015 using project.json for its metadata. It’s at https://github.com/julielerman/NetCoreSolutionToMigrateToVS2017.

I had this same solution on my laptop already to use for another demo: showing off VS2017’s ability to auto-migrate a project.json based solution to the new csproj based format for .NET Core projects.

Clever me, I decided to kill two birds with one stone. Clone the repo and have the migration run as it was opening that solution.

So I started up Visual Studio 2017 (since I wanted to show how fast that is) and began the process of cloning the solution from my GitHub repo. I already had my credentials set up and was able to go to File, Open and Open from Source Control.

2017-03-21_21-52-52

This opens the Team Explorer window and I clicked the Clone option, which then opened a window showing all of the accounts I’m connected to.

2017-03-21_22-06-28

I expanded my own account and scrolled down to the repo I wanted, selected it and clicked the Clone button.

2017-03-21_22-11-20

The solution got cloned and then it opened up in Visual Studio.

2017-03-21_22-13-53

But it never triggered the migration! And if you look at the solution, you can see that the project I expanded still has its xproj file and its project.json file. At the time I was confused but now that I know what happened, the answer to why this didn’t migrate is very visible in that screenshot of the Solution Explorer. However, one of the developers who was watching this and had just done another demo with Visual Studio 2017, identified the problem quickly.

Let’s move on for some more clues.

I closed the solution. Then from File/Open, I browsed to the place where it had been saved on my computer, and selected the sln file to open. This time, the same exact solution opening up in VS2017, did indeed trigger the migration, which is quite obvious thanks to this screen.

2017-03-21_22-18-17

Then I let the migrate feature do its job. When it was finished, you can see that the project no longer has its xproj and project.json files.

2017-03-21_22-21-42

Now, look at this new Solution Explorer screenshot compared to the previous one.

And then take a look at the list of new VS2017 features in the Release Notes (https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes) under the section IDE and see if you can tell what the cloning did differently when opening the solution than just opening the solution directly from the drive.

Also, I will find out if this is by design or possible a behavior that can get modified to behave the way I had expected. 🙂