Pick one thing you want to learn that is not SQL Server. Write down ways and means to learn it and add it as another skill to your resume. If you are already learning it or know it – explain how you got there and how it has helped you. Your experience may help many others looking for guidance on this.

In my day job, one of my hats is systems architect and integrator. One of those systems is a traditional on-premises ERP, while others are web applications and native mobile applications.  We’re a small team, but we make an honest effort to perform scalable and repeatable development practices.  The next improvement we’re making is a move towards **continuous deployment (CD). **As a team lead, I don’t enforce process changes with unknown consequences, so the CD shift requires me to get my feet wet with NodeJS.

We build a decent-sized chunk of our application architecture in Azure, which seems to be a good place to focus on continuous deployment.  Overall, our development processes need to shift in ways that allow us to automate deployment, testing, and integration.

What I want to learn:

• Developing Azure Functions for RESTful APIs from VS Code
• Continuous deployment for Azure Functions
• Basics of NodeJS web apps
• Continuous deployment for Azure web applications

Developing Azure Functions for RESTful APIs from VS Code

My usual learning process is:

• outline the main steps of a specific example that I want to complete
• search for tutorials and documentation that cover each step, read them all and put high-level notes on each in a document with their links so I can reference them again
• work through my example, adding to the necessary references and notes
• work through another example – similar but with new challenges
• consider how I can use concepts learned to improve previous projects, go back and make changes
• get quickly distracted by something else new

we have a thing, on our team
to encourage skill growth as a conscious activity
we have a Jira issue type for “learning”
by cataloging the resources and major takeaways
we have a collective knowledge of the collective knowledge

I started working with Azure Functions intermittently over a year ago, and it inspired me to give a lightning talk on it at a local SQL Saturday on interactions between Azure Functions and SQL Server.  Since then – my use for Azure Functions has grown more demanding – but I’m glad I took the time to get comfortable on the ground floor.

The v2 Azure Function framework runs C# functions on DotNet Core, allowing those C# functions to be developed and debugged from VS Code on Windows, Mac, or Linux.  The vast majority of our API endpoints need to connect to either an on-premises SQL Server or transform the results of other HTTP endpoints.

By following this document through “test the function locally” I was able to build multiple functions without deploying or monkeying around in the Azure Portal.  https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-first-function-vs-code

As far as building RESTful API endpoints with Azure Functions, this post by Mark Heath completely knocked it out of the park for me.  (and he shares a code repo!)  https://markheath.net/post/azure-functions-rest-csharp-bindings

Since starting to build C# Azure Functions right from VS Code, I’ve had 2 more rounds of integration points to build.  The latest is an endpoint for generating push notifications for our web and mobile applications.  It never ceases to amaze me the system components that you can create through serveless components like Azure functions or Lambda functions.

Continuous Deployment for Azure Functions

Admittedly, I stumbled across this capability while researching Azure API Management. While you can publish your Azure Functions directly from VS Code to an Azure subscription, it felt manual and clunky.  It certainly didn’t get us much closer to the CI/CD pipeline of my dreams.

We already store the majority of our project source code in GitHub, so when I came across that the deployment options for Azure Functions includes GitHub as a first-class-citizen (as in I don’t have to bootstrap webhooks or write custom connectors) I was pretty excited.   https://www.brianbunke.com/blog/2018/02/28/github-integration-with-azure-functions/

To get this completed was pretty quick – push your Azure function project from VS Code to a GitHub repo (public or private).  Create a new Function App in the Azure Portal, then pop into the “Platform features” tab. The “Deployment Center” takes you through a quick 2-step process to connect the function app to your source code – the function app will listen for a webhook from the branch you specify, and automatically build the function app from that repository branch.

**Note: **the _local.settings.json _file in your VS Code Azure Functions project should/will not be committed to GitHub and deployed to Azure.  Any app settings that you created in that file (like a database conneciton string!) can be set via the Azure Portal or the Function management API.

Basics of NodeJS Web Apps

Deploying to Azure Functions from GitHub was working out so well I took a quick look at our other upcoming projects and spotted a few NodeJS web apps. NodeJS is a skillset I’ve been blissfully without since our development team, though small, has some truly competent and wide-skilled individuals that drive us to succeed on a wide range of projects. Before I set our NodeJS developer up with a new deployment process, I wanted to get a better grasp on NodeJS.  (anything is better than almost nothing!)

I started a side project for viewing the releases and downloads for my open source projects on GitHub utilizing NodeJS.  Using some tutorials leveraging Express and brushing up on my AJAX I’ve been able to get the project nearly complete. (I need to buckle down and finish it one evening)

Continuous Deployment for Azure Web Applications

Fortunately, if you know to look for deployment options for web applications in the Azure portal, it’s pretty obvious how to connect your web application to source code.  After creating a new app service in the Azure Portal and open the “Deployment Center” pane.  The same Kudu deployment/build engine used to deploy from GitHub to Azure Functions is used to deploy to Azure app services.

Fortunately for me, the developer I get to work with at my day job has already finished his project, and by pushing it to the source code repository we linked to a Azure web app – has deployed it into production.

I already have the next learning step line up for NodeJS – working through a similar example with newer challenges. In 2019 we’re going to be increasing transparency to the management team with a web application for viewing Jira Epics and current status.  It will incorporate Azure Active Directory and multiple views.

What’s Next for Me?

• Azure functions seem to come up constantly at work, so I continue in the cycle of building on the foundational skills for new projects
• The first NodeJS project I started needs to be finished and I already have another project on the horizon, keeping my thirst for the skill alive.
• I take responsibility for the best practices of our development team, and even though we’re a small business there are ways to bring best practices to our scale.

Link to the original invitation: http://www.sqlservercentral.com/blogs/malas-data-blog/2018/10/29/t-sql-tuesday-108-invitation-non-sql-server-technologies/