Running a Workshop on Deployment Using Azure - "Localhost to Live!"
After launching the SimulAite pilot, one of my friends (who's also really interested in computing) asked me a simple question:
"How did you actually deploy the code?"
That gave me the idea to run a workshop for our Computing Club on exactly that: how do you take something running on localhost and actually get it live? Over 30 minutes, I walked through the deployment process step-by-step, covering the different pieces that sit between local code and a real application running on Azure.
What I loved most was putting the workshop together. These were concepts I had picked up gradually over years of building - often learning individual pieces only when I suddenly needed them. Now, I was stepping back and connecting them into one clear progression. Watching those scattered bits of knowledge come together into a single diagram across the whiteboard was strangely enchanting.
And it was great to be able to give my friends a head start on deployment - hopefully saving them some of the confusion I had when first discovering everything that happens behind the scenes between localhost and live.
Here are the notes people could take away with them:
A Complete Guide on how to Deploy an App with Azure
1. Azure account and subscription
First, you need an Azure account. This can be created using a personal Microsoft account or a company email address.
The important thing is that Azure resources live under an Azure subscription, which acts as the billing, access-control, and management container.
The starting structure is:
Microsoft account → Azure subscription → Azure portal access
The subscription is where cloud resources are billed, managed, and permissioned.
2. Resource organisation
Once the subscription exists, the infrastructure should be organised clearly.
A common setup is to use one resource group per environment:
Azure Subscription
└── Resource Groups
├──
Development resource group
├── Staging
resource group
└── Production resource group
Each resource group acts as a container for that environment’s infrastructure.
This avoids dev, staging, and production sharing one messy bucket of resources. Instead, each environment has its own isolated Azure resources.
3. App hosting with Azure App Service
For the main application, a common hosting option is Azure App Service.
You would usually create separate App Service instances for each environment, such as:
Development App Service
Staging App Service
Production App Service
Each App Service is where the application code actually runs.
Azure App Service supports deployment from repositories and CI/CD pipelines, allowing an application to be automatically built, tested, and deployed when code changes are merged into a designated branch.
4. App Service Plans
Each App Service needs an App Service Plan.
The App Service Plan is the compute layer. It defines the CPU, memory, scaling tier, and pricing model.
You might use:
Development App Service Plan
Staging App Service Plan
Production App Service Plan
In some cases, development and staging may share a cheaper plan, while production gets its own stronger plan.
Conceptually:
App Service Plan = server capacity
App Service = the web app running on that capacity
5. Environment-specific app settings
Each App Service needs its own configuration.
For example:
Development:
DATABASE_URL = development database
API_BASE_URL = development API
DEBUG = true
Staging:
DATABASE_URL = staging database
API_BASE_URL = staging API
DEBUG = false
Production:
DATABASE_URL = production database
API_BASE_URL = production API
DEBUG = false
In Azure App Service, these values are usually stored as app settings or environment variables. The application reads them at runtime.
This allows the same codebase to behave differently depending on whether it is running in development, staging, or production.
6. Supporting services
Depending on how the application is built, additional Azure resources may also be needed, such as:
Database
Storage account
Key Vault
Application Insights
Log Analytics workspace
AI service resources
The key idea is that production should not accidentally use
development resources.
A clean structure might look like this:
Development environment
├── Development App Service
├── Development database
├── Development storage
└── Development secrets and configuration
Staging environment
├── Staging App Service
├── Staging database
├── Staging storage
└── Staging secrets and configuration
Production
environment
├── Production App Service
├── Production database
├── Production storage
└── Production secrets and configuration
7. Source control
The application code should live in a Git repository.
That could be hosted in:
Azure Repos
GitHub
Bitbucket
A typical workflow looks like this:
Feature branch → Pull request → Main branch
Day to day, the process is:
Create a branch
Make changes
Push the branch
Open a pull request
Review and test
Merge into the main branch
Pipeline runs
8. Azure DevOps project
Next, Azure DevOps can be used to manage the CI/CD process.
Inside Azure DevOps, a project may contain:
Repos
Pipelines
Environments
Service
connections
Variable groups
Build history
Release and deployment history
Azure DevOps acts as the CI/CD control centre.
9. Service connection from Azure DevOps to Azure
Azure DevOps cannot deploy to Azure unless it has
permission.
A service connection allows the pipeline to authenticate
into Azure and deploy to the required App Services.
Conceptually:
Azure DevOps Pipeline
↓
Service Connection
↓
Azure Subscription
↓
App Services
Without this, the pipeline can build the application but
cannot deploy it into Azure.
10. Pipeline creation
An Azure Pipeline is usually defined using a YAML file, such
as:
azure-pipelines.yml
This file describes the automation.
A typical pipeline may include stages such as:
Build
Deploy to Development
Deploy to Staging
Deploy to Production
Pipeline stages help divide the process into major sections
such as build, test, and deployment. Stages can also be controlled with checks
and approvals.
11. Build stage
When code is merged into the main branch, the pipeline
starts.
The first stage is usually the build stage.
It may do things like:
Check out the code
Install dependencies
Run linting
Run tests
Build the application
Package the output
Publish a build artifact
For example, a JavaScript-based app may run:
npm install
npm run build
npm test
A Python app may install requirements and run tests. A .NET
app may restore, build, and publish.
The key idea is:
Source code → tested build artifact
The artifact is the deployable version of the application.
12. Deploy to development
Once the build succeeds, the pipeline deploys the artifact
to the development App Service.
Build artifact
↓
Development App Service
Development is where the latest merged version can be tested
quickly. It is usually the least protected environment.
This often happens automatically after code is merged into
the main branch.
13. Deploy to staging
After development succeeds, the pipeline can deploy to
staging.
Build artifact
↓
Staging App Service
Staging should mirror production as closely as possible.
This is where you test:
Does the app work end to end?
Do environment variables work?
Do database connections work?
Do external APIs work?
Does the user journey work?
Staging is the final rehearsal before production.
14. Deploy to production
Once staging has passed, the same artifact is promoted to
production.
Build artifact
↓
Production App Service
A key best practice is that production should receive the
same build artifact that was tested in development and staging, not a freshly
rebuilt version.
This gives confidence that what was tested is what gets
released.
Production may also have an approval gate. Approval checks
are commonly used to control production deployments.
A typical flow may be:
Merge to main
↓
Build
↓
Deploy to development automatically
↓
Deploy to staging automatically or manually
↓
Approval
↓
Deploy to production
15. Azure DevOps environments
Azure DevOps can also define logical environments, such as:
Development
Staging
Production
These are deployment targets used by the pipeline.
Instead of simply running a random deployment script, the
pipeline can say:
Deploy this artifact to the Development environment
Deploy this artifact to the Staging environment
Deploy this artifact to the Production environment
This gives deployment history, traceability, and approval
controls.
16. Domains and DNS
At some point, the production app may need a real domain
instead of the default Azure hostname.
Azure provides a default App Service URL, but users
typically access the application through a custom domain, such as:
example.com
www.example.com
app.example.com
To do this, DNS records are configured.
Usually this involves:
CNAME record → points a subdomain to the Azure App Service
hostname
A record → points the root domain to the correct Azure
endpoint
TXT record → proves domain ownership
Azure App Service custom domain setup typically involves
verifying domain ownership and binding the domain to the app.
17. SSL and HTTPS
After the domain is connected, HTTPS should be enabled.
Azure App Service can bind certificates to custom domains so
users access the application securely using HTTPS.
For example:
https://example.com
Without HTTPS, browsers may show security warnings or block certain app features.
Summary
The overall flow is:
Create Azure account and subscription
Organise resources by environment
Host the app using Azure App Service
Configure separate app settings for each environment
Store code in a Git repository
Set up Azure DevOps and service connections
Create a pipeline to build, test, and deploy
Deploy to development, then staging, then production
Connect a custom domain
Enable HTTPS
This takes an application from running locally on a
developer machine to running securely in a live cloud environment.
