Loading…
Topic
160 posts about Deployment. Every summary links to the original.
See the idea
A/B testing trades traffic, time, and exposure risk for evidence. This explainer maps the benefit of a controlled comparison, the real cost of running one, and the condition that decides when measuring beats shipping on judgment.
Bun packs a runtime, package manager, bundler, and test runner into one binary. Here is how those four parts fit together and where the seams still show.
CloudFormation is a declarative reconciler: you describe the target state in a template, and it provisions, updates, and reports on the stack that results. Here is the loop.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Flyctl v0.0.137 introduces an app-centric command structure while deprecating the apps subcommand, whose operations now have top-level equivalents such as init, destroy, move, restart, resume, suspend, and list apps. The release changes move, restart, resume, suspend, and status to accept an app name as a final argument, while retaining status -a; list also gains app-name fragments and status or organization filters, and list orgs shows accessible organizations. The init flow offers builders or Dockerfile use, can generate a simple hello-world deployment, and supports --dockerfile to skip the builder query, while info and version gain scripting-oriented output controls. Secret changes block operations on suspended deployments and can monitor deployments unless --detach is used. Platform fixes concatenate multiple HTTP/2 cookie headers during HTTP/1 downcasting, add Via headers to requests and responses, and improve deployment image optimization.
This Fly Changelog records significant changes to the Fly platform, tooling, and websites for the week of 29 May 2020. flyctl 0.0.124 adds apps pause and apps resume commands, which remove all running instances or start one running instance, respectively; regions set replaces the regions in a region pool list; and -v/--verbose provides more detailed command output. The release also improves flyctl apps list by displaying each application's status, while the Deno Buildpack supports unstable Deno builds when an .unstable directory is added to the application directory. Earlier in the month, flyctl 0.0.123 introduced open, which finds a deployed application's hostname and instructs a web browser to open it.
Fly’s 1 May 2020 changelog records enhancements to flyctl, a new Open Source page, and a revised load-balancing allocation algorithm. Version 0.0.117 added flyctl auth docker, allowing deployments of images directly to Fly by adding registry.fly.io to Docker’s authenticated registries, and introduced --image-label for selecting a specific image label at deployment time. The release also increased the timeout at the end of deployment monitoring to prevent erroneous “No Deployment” messages and changed deploy version negotiation to resolve API compatibility errors. For global applications with large numbers of instances, the new algorithm directs each incoming connection to an instance from the closest least-loaded service among three randomly selected healthy services in the app’s three nearest regions.
Shopify describes its release culture as a combination of beliefs and behaviors shaping how developers ship software, with trust, velocity, and safeguards as stated goals. The team measures developer experience through biannual happiness surveys, shipping Slack channels, dogfooding, internal support, and UX research that includes shadowing developers and testing prototypes with interns and new hires. Its release pipeline runs from a pull request and /shipit command through the merge queue, Master, a Canary environment receiving 5% of incoming requests, and Production after a 10-minute testing period without intervention or automated alerts. Developers own releases without managers, sign-offs, or release windows, while /shipit --emergency provides a single fast recovery path. Shopify also uses Beta Flags for gradual rollouts and measures /shipit success through survey feedback and average pull-request time-to-production.
Datasette makes SQLite datasets accessible through a web interface, with SQL queries, JSON and CSV export, and a REST/JSON API. This tutorial imports New York Central Park Squirrel Census CSV data into SQLite, runs it locally with Datasette, and publishes the database to Fly using the datasette-publish-fly plugin. It then renames the database’s X and Y columns to Longitude and Latitude, installs datasette-cluster-map, and redeploys with the plugin to produce an interactive map of squirrel sightings. The deployments expose Datasette online at Fly hostnames, with HTTPS, automatically generated Let’s Encrypt certificates, custom domain support, global deployment options, and edge networking with SSL termination. The mapped deployment lets users inspect individual sightings and view their details.
Fly Answers Questions compiles responses about custom domains, configuration recovery, Turboku deployment, database latency, TLS termination, global databases, continuous deployment, and idle-app scaling. Fly allows multiple custom hostnames per application and automatically provisions Let’s Encrypt certificates after validation; a deleted fly.toml can be restored with flyctl config save -a , with -c supporting another filename. For Turboku, Heroku slugs run as containers in a nearby datacenter rather than at the edge, while region selection can reduce database latency and retain edge SSL termination. The service supports TLS-only termination up to HTTP/1.1, GitHub Actions deployment, Redis for local caching, and a replication system for distributing changes, while keeping one running instance for idle apps instead of scaling them to zero.
Developers frequently use ngrok to establish fast, introspectable tunnels to localhost when building Zoom Marketplace applications instead of configuring complex reverse proxies like NGINX or Apache. However, using basic ngrok tunnels in production exposes systems to short URL expiration windows, single points of failure, and scalability bottlenecks. To maintain application availability, developers can purchase an ngrok license to secure a service-level agreement and support. Additionally, teams should reserve dedicated subdomains rather than using auto-generated endpoints, run ngrok as a monitored background service on a cloud provider or data center, and place a load balancer in front of the tunnel to handle heavy traffic.
Flyctl adds a new -p option to flyctl apps create, allowing users to set an app’s internal port during initial creation. The numeric value is written to the generated fly.toml configuration, replacing the default port of 8080. This addresses workflows using prebuilt Docker images, where users may not control the port and previously had to create the app, edit fly.toml, and change the internal port manually. Available from Flyctl release 0.94, the flag removes that edit and is shown in the first Fly Friday video. The post defines the internal port as the port an application uses to communicate with the world, while the command-line setting supplies that value before deployment configuration is generated.
flyctl now supports building and deploying NodeJS, Rails, Go, and Java applications to Fly with two commands. The feature uses Cloud Native Buildpacks from buildpacks.io, turning an application into a Docker image during deployment without requiring users to understand Buildpacks. Cloud Native Buildpacks are described as an evolution of Heroku and Cloud Foundry systems, but are not compatible with their older buildpacks. After installing the latest flyctl, users can initialize an app with flyctl init --builder cloudfoundry/cnb:bionic and run flyctl deploy, then open it with flyctl open. Buildpack support complements Dockerfile-based image builds, while listed builders provide different language coverage and image sizes; the post recommends heroku/buildpacks:18 for its wider coverage.
Shopify describes the challenge of scaling mobile development without slowing feature delivery as teams and projects adopt divergent tools, making knowledge sharing, cross-project contribution, and incident response harder. It extends ServicesDB, previously used to track production services, to treat mobile apps as services with owners and explicit expectations encoded in configuration files. Automatic checks cover ownership, contact information, CI and Shipit Mobile deployment configuration, internal-tool versioning, and production error and crash monitoring. Failed checks generate GitHub issues with remediation instructions, while the contract helps the Mobile Tooling team identify compatible projects and helps developers understand why tooling may not work. The implementation currently has basic checks, with planned work including mobile-app service-level objectives, easier project creation, and shorter build times.
Shopify’s single monolith supports changes 40 times a day and roughly 400 commits to master daily, making safe trunk-based development difficult at the scale of 1,000+ developers. Its first Merge Queue limited deployment drift and batch size, but queued pull requests did not receive CI, soft conflicts could break master, and a browser extension enabled accidental direct merges. Merge Queue v2 replaces that workflow with GitHub comments and webhooks, programmatic branch protection, an emergency /shipit --emergency path, and a predictive branch where queued changes receive CI before merging. A reconciliation algorithm synchronizes that branch through GitHub’s GraphQL API, while failure-tolerance thresholds handle flaky tests and remove repeatedly failing pull requests. CI starts when requests enter the queue; batches of eight and three concurrently tested batches balance throughput, risk, and resource use, while the changes improved user experience, deployment safety, and deploy throughput.
Heroku’s Runtime team replaced a manual, coordination-heavy deployment process after team growth and Common Runtime sharding expanded work from one infrequently changed application in two environments to multiple services across 12 environments. Existing Heroku Pipelines deploy merged, CI-passing changes to staging, while the Go-based cedar-service-deployer reconciles differences between pipeline stages and promotes them when a series of safety checks pass. Those checks include a 30-minute age gate, deployment and incident controls, master-branch verification, Librato alerts, and HTTP 200 checks for configured URLs, including platform integration tests. The stateless system can handle concurrent rollouts, and the team added practices such as isolated early stages, feature flags, and separated database-migration changes. After about two years, it managed 23 services, allowing engineers to merge and rely on healthy systems for global release.
Shopify describes running its Core monolith on the unreleased Rails 6 master branch, or “Edge of Rails,” since February 2019, with the goal of continuously using the framework’s latest revision. Instead of annual upgrades, weekly changes reduce diff size and let developers use upstream features quickly, while a 130,000-plus-test suite finds edge cases and informs patches to Rails and related projects such as Zeitwerk. Solid Track automates weekly Rails bumps, opens GitHub pull requests, and triggers git bisect when CI fails to identify the breaking commit. Green builds move through ten-minute canary deployments before reaching the remaining servers. The approach trades the stability of released dependencies for faster fixes and features, relying on monitoring, tests, and controlled deployment to manage risk.
Shopify’s tax engine grew from a simple system into difficult code as tax rules and ownership spread across Cart, Checkout, and Order. The team first learned the surrounding code and tax domain with help from a tax subject matter expert, then mapped dependencies using regular expressions, scripts, manual investigation, and tax-related bug work. They moved tax source files into a dedicated component behind explicit TaxesRequestSchema and TaxesReponseSchema interfaces, with simple-type request and response schemas, protected boundaries, and expanded unit, integration, and end-to-end tests. During release, the old and new engines calculated taxes concurrently so discrepancies could be measured; after iterative fixes, Shopify rolled the component out gradually from a small group of shops to all shops over several days, with no downtime or merchant impact reported.
As machine learning adoption expanded at Grab, individual teams created fragmented model serving solutions that duplicated engineering effort and required data scientists to handle underlying infrastructure. To resolve these inefficiencies, Grab developed Catwalk, a self-service machine learning model serving platform. The system runs TensorFlow Serving containers across a managed Kubernetes cluster integrated with Grab's observability stack. Data scientists deploy or update models simply by saving files using the tf.saved_model API to dedicated Amazon S3 buckets, while Kubernetes automates orchestration, ingress routing, and pod autoscaling. Catwalk abstracts server management away from data scientists, shortens deployment timelines, and provides high availability during model version rollouts.
Shopify built Shipit Mobile to replace error-prone, manual mobile app releases with a shared platform for creating, viewing, and managing releases. The process creates a release branch from master, builds a candidate for each commit, increments build numbers, and starts separate CI pipelines for testing and release builds. Shipit Mobile uploads the same binary and metadata to distribution channels including Google Play, the App Store, and internal support access, using store APIs and Fastlane, while Slack notifications make release status visible beyond the release captain. Developers can bypass CI when necessary for emergencies, and configuration favors convention over configuration for project metadata. After more than six months in production, the platform reduced release complexity, shortened the release cadence from three weeks to one week, and helped more people become release captains.
Shopify describes a merge queue added to Shipit to reduce failures in its large monolithic Rails application, where growing pull request volume made manually checking whether master was safe unsustainable. The queue adds pull requests from GitHub, merges them when master is healthy, waits for required CI statuses, and can reject stale branches using configurable divergence thresholds. It is encouraged rather than enforced, while changing the browser extension’s visual emphasis helped make queued merging the default workflow; over 90% of core application pull requests use it. Shipit also handles unsafe deployment commits by allowing explicit marking and automatically detecting reverts of undeployed commits, marking the original and intermediate commits unsafe. These changes let deployment continue safely around reverted work without requiring developers to manually unlock the pipeline.
Jekyll can be deployed on Heroku to use its plugin system, but relying on jekyll serve would use Ruby’s single-threaded WEBrick rather than a production-oriented web server. The setup installs Ruby with ruby-install and chruby, then installs Bundler and Jekyll, creates a site, and tracks it in Git. Heroku’s official Ruby buildpack handles dependencies and runs a Rake assets:precompile task that executes jekyll build, while the Static buildpack serves the generated _site/ directory according to static.json. The example pins Ruby 2.4.2, adds Rake, enables clean URLs and HTTPS, and completes with a successful deployment of the generated site to a Heroku URL.
Kickstarter upgraded its main Rails application to Rails 5, alongside payments app Rosie, to support site security and performance while moving a nine-year-old legacy codebase forward. The team planned a three-month project, upgraded Ruby 2.2.5 to 2.4.x, classified release-note changes, resolved dependency conflicts, used Rails’ upgrade script, and moved through twelve documented steps. Work included merging Rails 4.2-compatible fixes, repairing nearly 4,000 CI test failures from a roughly 70 percent coverage baseline, removing deprecations, smoke-testing major flows, backporting more than thirty pull requests, and preparing reviewers and deployment contingencies. The upgrade met its timeline without rollbacks or major downtime, although untested bugs increased Zendesk tickets and exposed issues involving ActionController::Parameters, tracking events, and mobile applications. A retrospective emphasized planning, documentation, cross-team communication, and broader native-team participation for future upgrades.
Grab manages continuous delivery for its iOS applications using four build configurations per target: Adhoc QA, Hot Dogfood, Dogfood, and Testflight. The engineering team moved away from Fastlane in favor of custom bash scripts under 100 lines that execute clean builds and archives via xcodebuild. To eliminate manual logins for build execution, Grab developed a server-side Swift application integrating SlackKit and a bot named Iris. Incoming Slack commands are parsed and scheduled onto a serial DispatchQueue to trigger the appropriate build scripts. Deployment and rollback of updates to Iris and its build scripts are handled through Capistrano.
The best engineering reads, once a week.
