git config --global core.editor "code --new-window --wait"
Installing git on Windows
The default editor can be configured in the installation wizard in Windows. Uncheck ‘Only show new options’ to ensure that this step is shown.
2026-02-27 - Ship smaller OTA updates: bundle diffing comes to EAS Update in SDK 55
2026-02-26 - How to upgrade to SDK 55
2026-02-24 - 5 OTA Update best practices every mobile team should know
2026-02-20 - Automating OTA Updates: How Onespot deploys to 200+ apps without touching
2026-02-18 - The production playbook for OTA updates
2026-02-12 - Automate mobile CI/CD with EAS Workflows and custom builds
2026-02-11 - Building an AI-first Photos app with Expo and Coreviz SDK
2026-02-06 - What our web team learned using Claude Code for a month
2026-02-06 - How to modernize mobile retail apps with Expo
2026-02-03 - Building high-quality UIs with Expo and NativeWind
2026-01-30 - 5 tips to increase mobile app downloads and retention in 2026
2026-01-29 - How Sanas built a real-time video translation app in 3 months using Expo
2026-01-28 - The solo dev playbook: ship faster with Expo, EAS Build, and OTA Updates
2026-01-21 - Channel surfing for Expo Updates: How to switch update channels at runtime
2026-01-20 - Strapi: low-code CMS for Expo and React Native
2026-01-15 - Making AI feel human in a mobile app with Expo, Reanimated, and Skia
2026-01-13 - How the Minecraft Speedrunning Community stays fast with Expo
2026-01-08 - Cutout camera effects in React Native with Expo Camera and MaskedView
2026-01-06 - The offline first, multilingual audio tour app built with Expo
2025-12-18 - How I built a dev server entirely in the browser
2025-12-17 - AI-powered code reviews for your Expo projects
2025-12-16 - How to turn every pull request into an instantly installable preview
2025-12-15 - Expo now supports Maestro Cloud testing in your CI workflow
2025-12-11 - From web to native with React
2025-12-10 - How to implement iOS widgets in Expo apps
2025-12-09 - How Expo streamlined Hipcamp’s native and over-the-air update processes
2025-12-04 - How MTA uses Expo to keep New York City moving
2025-12-02 - How Lingvano scales sign language education to 4 million learners with
2025-11-25 - How to create Apple Maps style liquid glass sheets in Expo (the real way)
2025-11-20 - Optimize user experience and drive engagement with Vexo & Expo
2025-11-19 - Going Universal: From a brownfield React Native and Next.js stack to one
2025-11-13 - How to integrate EAS Workflows with GitHub Actions for faster mobile CI
2025-11-11 - How Phantom ships a secure, high-performance crypto wallet with Expo
2025-11-04 - EAS Hosting is a faster, simpler way to deploy your app and API together
2025-10-30 - Building a MIDI-over-Bluetooth app using Expo Modules
2025-10-28 - Faster, more reliable video uploads with Expo Modules
2025-10-23 - Expo is more than a dev framework, it’s a business strategy
2025-10-21 - Become an AI-native developer with the Expo MCP server
2025-10-20 - The React Foundation: A new chapter for React and React Native
2025-10-16 - How to add native code to your app with Expo Modules
2025-10-14 - No rewrite required: How to bring Expo into mature native apps
2025-10-06 - The 2025 Expo App Awards: A celebration of the best Expo apps
2025-10-02 - The future of AI apps is on the device: How to run AI models with React
2025-09-30 - From Swift tattoo to React Native migration lead: a business-first
2025-09-25 - Building beautiful components faster with Storybook 9 and Expo
2025-09-23 - How to organize Expo app folder structure for clarity and scalability
2025-09-16 - Expo File System gets a major upgrade in SDK 54
2025-09-15 - Expo App Integrity
2025-09-12 - Liquid glass app with Expo UI and SwiftUI
2025-09-11 - Expo Router v6
2025-09-10 - Expo SDK upgrade guide
2025-08-28 - What synced in-app SQLite brings to Expo apps
2025-08-20 - Introducing Expo Launch
2025-08-13 - How Mollie uses Expo to power its multi-platform payments app
2025-08-07 - EAS Update best practices
2025-08-05 - Building Dyfna with Expo
2025-07-31 - 5 Expo SDK features
2025-07-29 - 6 reasons to use EAS Update
2025-07-24 - Precompiled React Native for iOS
2025-07-22 - Build 2D game-style physics with Matter.js and React Native Skia
2025-07-17 - Camera-powered sommelier with Expo
2025-07-31 - 5 Expo SDK features
2025-07-29 - 6 reasons to use EAS Update
2025-07-24 - Precompiled React Native for iOS
2025-07-22 - Build 2D game-style physics with Matter.js and React Native Skia
2025-07-17 - Camera-powered sommelier with Expo
2025-07-15 - Accelerating continuous integration with fingerprint repack in EAS Workflows
2025-07-10 - How to build seamless subscriptions with Expo and RevenueCat
2025-07-08 - Unistyles 3.0: beyond React Native StyleSheet
2025-07-03 - How to build apps fast
2025-07-01 - Real App Store apps using AI and Expo
2025-06-24 - Expo RevenueCat in-app purchase tutorial
2025-06-19 - App architecture with Expo Router, ElysiaJS, and NativeWind
2025-06-17 - Simplifying auth flows with protected routes
2025-06-12 - What if useState was your backend
2025-06-10 - Mobile game development with Expo
2025-06-03 - Which Android apps are built with Expo
2025-05-26 - How to get your AI app to the App Store
2025-05-23 - What are environment variables
2025-05-21 - Diagnose and debug errors faster with issues and replays from Sentry in Expo
2025-05-15 - Expo IoT device provisioning with HTTPS via WiFi
2025-05-14 - Real-time audio processing with Expo and native code
2025-05-08 - Build cache providers in Expo
2025-05-05 - Expo Router v5
2025-05-01 - Introducing Expo Maps: a modern maps API for Expo developers
2025-05-01 - Goodbye Background Fetch, hello Expo Background Task
2025-05-01 - Mobile app payment processing best practices
2025-04-29 - Migrating to React Native with Expo
2025-04-24 - Apple SDK minimum requirements
2025-04-22 - Best practices for reducing lag in Expo apps
2025-04-21 - Out with the old, in with the New Architecture
2025-04-17 - How to build universal app voice agents with Expo and ElevenLabs
2025-04-15 - Deploying an Expo app to web with EAS Hosting
2025-04-09 - Replit, Expo, and Grok
2025-04-04 - Use Expo, ship faster
2025-04-03 - Build offline-first mobile apps
2025-04-02 - Understanding and comparing fingerprints in Expo apps
2025-03-28 - How we built a TikTok for Bluesky with Expo
2025-03-26 - Ship fast, learn faster: introducing Vexo Funnels for Expo apps
2025-03-19 - Build and launch AI apps with Create and Expo
2025-03-17 - How Tempo and Expo redefine mobile app development
2025-03-11 - Idea to app in 40 hours
2025-03-06 - How to build a solid test harness for Expo apps
2025-02-27 - 4 must-have Radon IDE features for even more convenient Expo development
2025-02-20 - From idea to app with Replit and Expo
2025-02-19 - How to build custom tabs with Expo Router UI
2025-02-14 - Learn from user behavior with LogRocket and Expo
2025-02-12 - Bolt Expo integration announcement
2025-02-06 - Increase your Expo power with Ignite generators
2025-02-04 - Universal and app links
2025-01-30 - DOM component use case
2025-01-28 - How to build beautiful React Native bottom tabs
2025-01-26 - One codebase, three brands: how Awaze shipped 3 enterprise apps fast with Expo
2025-01-21 - How I migrated my bare React Native app to Expo
2025-01-17 - EAS SOC2 Type2
2025-01-14 - Expo announces EAS Hosting service
2025-01-07 - Modern SQLite for React Native apps
2024-12-19 - Why Expo is a great fit for new and existing React Native apps
2024-12-18 - 2024 year in review
2024-12-17 - How we promote social sharing on Marathon with Expo
2024-12-12 - Upcoming Apple Push Notification Service certificate change
2024-12-10 - The real world impact of shared objects
2024-12-03 - Expo Video: a simple, powerful way to play videos in apps
2024-11-27 - Upgrading to Expo SDK 52
2024-11-26 - Edge-to-edge display now streamlined for Android
2024-11-22 - Environment variables
2024-11-21 - Local-first application development with LiveStore
2024-11-20 - Expo Workflows: automate your release process
2024-11-19 - The magic of Expo DOM components
2024-11-14 - Universal React Server Components developer preview
2024-11-12 - How to add an animated splash screen with Expo custom assets
2024-11-07 - What is the best React Native list component
2024-11-05 - The architecture of a conference application built with Expo
2024-10-29 - Build mobile apps faster with Expo and thirdweb
2024-10-22 - How to bring your React Native apps to life using sensors
2024-10-15 - Build a daily workout tracker with Clerk, Convex, and Expo
2024-10-08 - Payhip boosts seller experience with Expo-powered mobile app
2024-10-01 - How to synchronize reactive local-first apps with TinyBase
2024-09-23 - How to incrementally adopt Expo
2024-09-17 - Why I gave Expo a second chance
2024-09-12 - Expo Go vs development builds
2024-09-10 - The beauty of mathematics in crafting stunning animations
2024-09-05 - From idea to Google Play Store in 100 days
2024-08-29 - Create and run fast end-to-end tests using Moropo and Expo
2024-08-26 - How Rosebud decided to go native with Expo
2024-08-22 - What to do without CodePush
2024-08-19 - How to build a Bluetooth Low Energy powered Expo app
2024-08-15 - How Expo helps my startup grow faster
2024-07-30 - What is Continuous Native Generation
2024-07-23 - From RNC CLI to Expo
2024-07-18 - Build fast, flexible calendars in React Native with Flash Calendar
2024-07-16 - Increase iteration speed with PR previews
2024-07-11 - From Web to Native with React
2024-07-09 - Rebuilding a 10-year-old iOS app with Expo
2024-06-20 - From web to native with React Native and Expo
2024-06-19 - FCM v1 migration deadline changed to July 20th
2024-06-06 - How Belka built Mangayo app in just 3 months with Expo
2024-05-23 - Introducing Expo Atlas
2024-04-11 - Expo Quick Actions
2024-04-06 - Push receipt ID format will change
2024-04-02 - Security notice for EAS Submit
2024-03-29 - Expo Orbit now available as a preview for Windows
2024-03-25 - Incident.io harnesses the power of native modules and CNG
2024-03-21 - How to replace App Center and CodePush
2024-03-20 - March Madness Expo app
2024-03-14 - 12 tips for setting up your next Expo project
2024-03-11 - Expo adds support for FCM HTTP v1 API
2024-03-06 - Launching EAS Updates with Orbit
2024-02-29 - Orchestrate advanced workflows with custom builds
2024-02-27 - Offline-first apps with Expo and Legend State
2024-02-23 - Expo push notifications: migrating to FCM v1
2024-02-20 - Expo Fingerprint GitHub Actions
2024-02-15 - How to build TV apps
2024-02-13 - Expo Camera Next
2024-02-08 - Dev tools plugins
2024-02-06 - Fingerprint your native runtime
]]>syncyarnlock, but I couldn’t find any equivalent tool for npm. So I wrote one.
syncpackagejson synchronizes the installed versions of Node.js dependencies as specified in package-lock.json into package.json.
The package is intended to be used together with npm upgrade, like this.
npm upgrade && npx syncpackagejson && npm install
This is still very much a 1.0 release. When you find a bug or something missing, please file an issue.
]]>GatsbyContentfulFluid_tracedSVG or GatsbyContentfulFluid_withWebp, but you have to choose between one or the other. Fortunately is not that difficult to add a fragment query this allows having both.
Create a file with shared query fragments, e.g. fragments.ts. Just make sure that Contentful can see the file. Mat Clutter has more information about Using GraphQL fragments across multiple templates in GatsbyJS.
import { graphql } from "gatsby"
// The name of this constant isn't important.
export const tracedSvgAndWithWebp = graphql`
fragment GatsbyContentfulFluid_tracedSvg_withWebp on ContentfulFluid {
tracedSVG
aspectRatio
src
srcSet
srcWebp
srcSetWebp
sizes
}
`
Replace your exiting fragments with new GatsbyContentfulFluid_tracedSvg_withWebp, e.g.
export const imageQuery = graphql`
image {
fluid(maxWidth: 1680, maxHeight: 1050) {
...GatsbyContentfulFluid_tracedSvg_withWebp
}
description
}
`
The fragments that gatsby-contentful-source comes with are all defined in their fragments.js file. GatsbyContentfulFluid_tracedSvg_withWebp is a combination of GatsbyContentfulFluid_tracedSVG and GatsbyContentfulFluid_withWebp.
I create a commit after each step, so that I can easily undo or debug, if necessary, and I generally test running the app after each stop to make sure it still work. Upgraded packages sometimes require minor changes to the code.
The Expo CLI will do the most of the work upgrading the app, so start out by making sure I have the latest version of that command line tool.
yarn add --dev expo-cli@latest
Expo CLI can upgrade Expo and all packages that it knows about, respecting Expo’s specific version requirements. expo upgrade updates the version numbers in package.json and installs them afterwards to keep the yarn.lock in sync.
yarn expo upgrade
Make a note of the packages there weren’t upgraded by Expo. Here’s an example of the list of unknown packages.
The following packages were not updated. You should check the READMEs for those repositories to determine what version is compatible with your new set of packages: @react-navigation/native, @react-navigation/stack, prop-types, tslib, @babel/core, @types/expo__vector-icons, @typescript-eslint/eslint-plugin, @typescript-eslint/parser, eslint, eslint-config-prettier, eslint-plugin-prettier, eslint-plugin-react, expo-cli, prettier, sharp-cli
Upgrade the unknown packages and any transitive dependencies that weren’t touched by expo upgrade.
yarn upgrade
yarn upgrade doesn’t upgrade packages to new major versions. Verify if there is anything not up to date, and if so, consider upgrading. For my Expo projects this is typically the ESLint related packages. I update the version manually in package.json and then run yarn install.
Some of the know packages might show up as deprecated, but do not updated those. Expo has been tested with specific versions of these packages, and they are naturally a little behind the latest releases.
# Look for major updates to unknown packages. These are the red lines, where the package was listed as unknown in step 1.
yarn outdated
package.jsonI like being able to see the exact version of the packages that I have installed by looking in package.json, so I use syncyarnlock to synchronize the versions from yarn.lock to package.json. Run a yarn install after modifying package.json to sync the modifications back to yarn.lock.
npx syncyarnlock --keepPrefix --save && yarn install
git config --global core.editor "code --new-window --wait"
The default editor can be configured in the installation wizard in Windows. Uncheck ‘Only show new options’ to ensure that this step is shown.
The source code related to the series is available on GitHub. If you prefer reading code, you can browse the commit history instead.
Creating the Azure Function in TypeScript has been split into seven parts. If you already know about Azure Functions in JavaScript you might want to skip ahead to part 2. The tests are very simple, so part 3, 4 and 5 are mostly about configuring CircleCI and creating an ARM template. The 6th part, refactoring,was the most exciting one to write.
Part 1: JavaScript version. Install the prerequisites and create a serverless function in JavaScript triggered by HTTP.
Part 2: Switch to TypeScript. Convert the JavaScript function to TypeScript.
Part 3: Add a Test. Add a local test and create a continuous integration pipeline that runs the test.
Part 4: Continuous Deployment. Extend the continuous integration pipeline into a continuous deployment pipeline, finally deploying the code to Azure.
Part 5: Add an End-to-end Test. Use the public endpoint on Azure to create an end-to-end test.
Part 6: Refactor. Now that we have test coverage we can refactor the code with ease of mind.
Part 7: Node Module. Demonstrate how to use a Node Module.
Azure Functions require a long term support (LTS) version of Node.js. The latest version, version 12, is an LTS version, but it’s still quite new, so for now to be safe I recommend sticking version 10, since that’s the one that Microsoft mentions in the previous link. When installing older versions with Homebrew we have to forcibly tell it to set that version to the default one. Remember to re-link if you upgrade Node.js. You can use nvm if you need to switch between different versions of Node.js.
$ brew install node@10
$ brew link node@10 --force --overwrite
Install Yarn. Yarn is a better npm. I am particularly fund of the really fast installs on a project where the dependencies are up to date, because this allows you include yarn install as part of the build, making sure that you are always using the correct versions.
$ brew install yarn
Install the command line tools for Azure Functions, Azure Functions Core Tools. This is the func shell command. The tools are installed as a local Node.js package instead of a global tool because we will be using the func command later on in our continuous integration pipeline. Installing it locally also has the benefit that if you’re a team of developers, it easy to keep everybody on the same version.
I always install exact versions of the Node.js packages that I use (--exact) because I like being able to see the versions of the installed packages in package.json. With the command line tool npm-check-updates installed you can upgrade all the packages with the command ncu -u && yarn upgrade. I recommend keeping upgrades in their own commits to make it easy to revert an upgrade, should it break something.
$ mkdir azure-functions-typescript
$ cd azure-functions-typescript
$ yarn add --exact --dev azure-functions-core-tools
Initialize the project and create an HTTP triggered function called greet.
$ yarn run func init --worker-runtime node
$ yarn run func new --name greet --language JavaScript
# Press 8 to create an HTTP triggered function.
This results in the following folder structure. A few notes
host.json.function.json file.local.settings.json are only used when hosting the functions locally. They are not copied to Azure when publishing.├── greet
│ ├── function.json
│ ├── index.js
│ └── sample.dat
├── node_modules
│ └── ...
├── host.json
├── local.settings.json
├── package.json
└── yarn.lock
The local Azure Functions host is started with the command yarn func host start. The yarn prefix is necessary since the func command is installed locally. This is bit long to type, so we add a start script command to package.json. We can now start the local host with this command:
$ yarn start
Open a browser window, go to http://localhost:4000/api/greet, add a name as a query parameter, and you will see it echoed back.
The full code base after part 1 has a few more files added to it. They consist of the three things below. If you want more details, then take a look at the commit history.
The Azure Functions extension for VSCode requires that the Azure Functions Core Tools are available as a global command. I recommend installing the tools with Homebrew, since that makes it easy to maintain the package together with Node.js and Yarn (brew install azure-functions-core-tools). It’s fine having the tools installed both locally and globally.
It’s possible to debug and hit breakpoints in Visual Studio Code. Set a breakpoint and start the local host with VSCode’s debugger panel. This will run yarn start and attach a debugger to Node.js. Remember to trigger the function by calling the http://localhost:4000/api/greet URL.
If you prefer reading code, this is the code base after part 2.
To keep things organized we put the source files in a folder named src and we will be building into a distribution folder named dist.
├── node_modules
│ └── ...
├── src
│ ├── greet
│ │ ├── function.json
│ │ ├── index.ts (renamed from .js)
│ │ └── sample.dat
│ ├── host.json
│ └── local.settings.json
├── package.json
└── yarn.lock
We’re now ready to compile. This will require installing the TypeScript compiler.
$ yarn add --exact --dev typescript
The TypeScript compiler is configured with a tsconfig.json file.
module and moduleResolution is configured to compile into JavaScript output that is compatible with the Azure Functions host.outDir and rootDir are the output and input folders.sourceMap means that we want TypeScript to generate map files along with the js files. This allows us to debug the TypeScript source files, instead of debugging the generated JavaScript files.target instructs the compiler to output JavaScript that is compatible with the very recent ECMAScript version 2018. This is possible since Node.js version 10 supports ECMAScript 2018.// tsconfig.json
{
"compilerOptions": {
"module": "commonjs",
"moduleResolution": "node",
"outDir": "dist",
"rootDir": "src",
"sourceMap": true,
"target": "es2018"
}
}
Note that you strive to always turn on TypeScript strict mode that enables a handful of very nice compile time checks. We will do this when refactoring the code in part 6.
Building the solution consists of two things:
src to dist.We create a build command to handle this, and we update our start command so that the solution is built before starting the host. The start is also updated to switch to the dist folder.
// In package.json
"scripts": {
"build": "tsc && cp src/*.json dist && cp src/greet/*.json dist/greet",
"start": "yarn run build && (cd dist; func host start)"
}
We still use yarn run start to start our local Azure host, but now the code is compiled first.
The command for copying the json files cp src/*.json dist && cp src/greet/*.json dist/greet would have to be updated every time we add or rename a function. This is avoided by using the small copyfiles command line tool.
// In package.json
"build": "tsc && copyfiles --up 1 \"src/**/*.json\" dist",
Right now the build command is very simple, but as the project grows it might become beneficial to introduce a build tool like Webpack. We explore using Webpack in part 7.
The code after this third part.
Since we’re coding in TypeScript we also have to install ts-jest and @types/jest when installing jest.
$ yarn add --exact --dev jest ts-jest @types/jest
(Side note: Installing Jest blows up the number of Node packages from 108 to 448. These guys really like using packages.)
Our test is pretty straight forward: It creates fake request and context objects and calls the run function to verify that the response is indeed Hello Jan Aagaard as expected.
// greet/index.test.ts
import { run as greet } from "./index";
describe("greet function", () => {
test("returns correct greeting", async () => {
const request = {
query: {
name: "Jan Aagaard"
}
};
const context = {
log: () => undefined,
req: request
};
await greet(context, request);
const response = (context as any).res;
expect(response.body).toBe("Hello Jan Aagaard");
});
});
The code base includes a script command to run the tests, so that they can be executed by typing yarn test. Instead of relying on an external command to run the tests, I recommend installing the excellent Jest extension for Visual Studio Code. I will run the tests continuously in the background, and show the results in VSCode’s status bar.
The default setting is to show a ‘Debug’ link above the tests that are failing, but I like being able to step into my code at any time. Adding the following line to .vscode/settings.json makes the ‘Debug’ link show permanently.
// In .vscode/settings.json
"jest.debugCodeLens.showWhenTestStateIn": ["fail", "pass", "skip", "unknown"],
Instead of relying on that the developers remember to run the tests locally, we will set up a continuous integration pipeline that executes the tests and blocks the pull request, should any of them fail. CircleCI is one of the options for automating builds when having code hosted on GitHub, and it seems like it’s currently gaining a lot of traction. Create your CircleCI account by signing in via GitHub, and then create a config.yml file that configures pipeline. These are the steps in the pipeline:
It isn’t necessary to build the code before running the tests because ts-jest takes care of that when running them. But it’s nice to include the build step anyways to catch any compile errors, and likewise we also include a lint step.
# .circleci/config.yml
version: 2.1
jobs:
build:
docker:
# Match the version in azure-resource.json. See https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-node#node-version.
- image: circleci/node:10.14.1-stretch
steps:
- checkout
- run:
name: Install Node modules
command: yarn install --frozen-lockfile
- run:
name: Build
command: yarn run build
- run:
name: Lint
command: yarn run lint
- run:
name: Run tests
command: yarn run test
The final config.yml has a few more steps, adding a cache of the node_modules folder to speed up the build time and presenting the test results in CircleCI.
node_modules.node_modules.CircleCI requires that test results are stored as JUnit XML files, and Jest uses json by default. The command for saving the test results ended up being quite long.
// In package.json
"test-save-results": "cross-env JEST_JUNIT_OUTPUT=test-results/test-results.xml jest --ci --runInBand --reporters=default --reporters=jest-junit"
The code after this fourth part.
We could log in to the Azure Portal, create the necessary resources, and upload the code manually, but instead we will deploy by scripting the process so that we get infrastructure as code where everything is checked into our source tree.
Azure’s Asset Resource Management templates are tricky at first, but once you have used a development setup with automated deployment, I guarantee that you will not want to go back to manual deployments. If you want to know more about all the benefits, the great Martin Fowler has a series about continuous integration where he explains all the benefits.
You need an account on Azure. You can create one for free on portal.azure.com. If you’re new to Azure I recommend that you try some of the manual tutorial out there to get a feel for how the portal works.
Each branch in our source code has an associated unique environment on Azure. New environments are automatically spawned when new branches are created. With such a setup there is are no specific development, test or staging environments. Instead, each branch environment takes each of these role corresponding to the state of the task. So while you’re developing the task it’s a dev environment, when the tests run it’s a test environment, and when the task is tested manually it’s a staging environment.
The production environment is simply the one associated with the master branch. Well, almost. In real world applications, the production environment probably has more resources and nicer URLs than the branch environments, and that leads to also having a test environment that mimics the production setup. But in this tutorial we have the luxury of keeping all environments identical, thus simplifying the infrastructure code and fully respecting dev/prod parity.
Example:
master.azure-functions-typescript-master.https://aft-master-functions.azurewebsites.net/api/greet/.
Create or update Azure resources in config.yml calls create-azure-resources.sh with the branch name as a parameter.create-azure-resources.sh uses the Azure Command-Line Interface (the az command) to create a resource group and then the resources inside the group. The resources are described in azure-resources.json.Publish code to Azure in config.yml calls publish-to-azure.sh with the branch name as a parameter.publish-to-azure.sh uses the Azure CLI to copy the compiled JavaScript to Azure.As you can tell just from the length of the official Naming conventions for Azure resources, naming resources in Azure is surprising difficult.
Here are the main restrictions:
We can use uniqueString() to generates a unique string, making sure that we don’t have a name clash with someone else, and at 13 characters it’s short enough to fit into the storage account name.
"[concat('aft', uniqueString(resourceGroup().id), 'sa')]"
becomes aftjmjv7xd3kilis-appsa.
The function apps resource uses the branch name as part of the resource:
[concat('aft-', skip(resourceGroup().name, length('azure-functions-typescript-')), '-functions')]
becomes aft-master-functions.
Using the branch name as part of the function app name puts some restrictions on the branch names:
*) Max_function_app_length - (length(atf-) + length(-function))
= 60 - (4 + 9)
= 47.
A test should verify 1) that a branch name adhere to these rules, and 2) that it doesn’t clash with the name of another branch before the resources are published. This has not been done.
It’s quite complicated to install the Azure CLI on CircleCI, but fortunately the Azure CLI orb handles that. The orb uses the two parameters AZURE_PASSWORD and AZURE_USERNAME when signing in to Azure, so add them as environment variables in CircleCI.
A complete solution should of course also clean up after itself and delete the branch environments when a branch is delete. CircleCI does unfortunately not support executing a job when a branch is deleted, so a more complicated solution would have to built. Other CI systems like GitLab’s integrated CI/CD supports triggering jobs when branches are deleted, so hopefully CircleCI will add this feature too.