The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
I designed and implemented the full deployment pipeline for SyncBeat using Azure DevOps:
Source control & pipeline trigger — code pushed to the repo automatically kicks off the CI/CD pipeline in Azure DevOps
Build & containerization — the app is built and packaged into a Docker image
Azure Container Registry (ACR) — the image is pushed to ACR as the central image store
Azure Web App — the pipeline deploys the container directly to Azure App Service, so every merge results in an automatically updated live app
Why it matters
This setup means zero manual deployment steps — a code change goes from commit to live in minutes, with a consistent, repeatable process. It's the same workflow small teams use to avoid "it works on my machine" problems and reduce deployment risk.
Tech stack
Azure DevOps · Docker · Azure Container Registry · Azure App Service · Git
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
ESG reporting is a workflow problem as much as a data problem: teams need applicability rules, evidence, consolidation, review, and approvals before a report is ready.
For OriginSustain, I built NestJS/TypeScript backend services, PostgreSQL and Redis/BullMQ processing, and AWS/Docker delivery with CI/CD. OpenAI API and RAG support part of the reporting flow. The screens here are from the product’s illustrative command center; the numbers are demo values, not client outcomes.
The full backend case study: https://contra.com/p/WvNXbmQR-origin-sustain-or-multi-tenant-esg-reporting-backend
Switching a client site to automatic production deploys is rarely a decision anyone made. It was the platform default, left on, then defended later as philosophy.
What it saves is a click and the awkward message asking a client to open the preview URL again. Both land on the developer. What it costs is the publish decision, handed to whoever merges next, with whatever the branch holds.
On a product team that's fine. On client work the merger owns the code and the client owns the brand.
Every host ships the fix. Netlify locks the published deploy. Vercel stages the push once you turn off auto-assigned production domains. Actions uses environment protection rules when the approver shouldn't be the author.
If your live deploy turned out to be wrong right now, could you name the deploy ID you'd roll back to?
https://www.duskolicanin.com/blog/manual-production-deploy-client-websites
A good donation flow needs dependable systems behind the screens. For Gabriel SGO, I built the NestJS/PostgreSQL backend for donor and school workflows, with PayPal donation processing, Redis/BullMQ background jobs, Mailgun email, and AWS delivery.
The public experience helps Ohio donors estimate a contribution, choose a school, and understand the tax-credit process. I documented the backend work and real site screens here: https://contra.com/p/Ls6L2o7Y-gabriel-sgo-or-donation-and-school-allocation-backend
