Effective Release Management for Early Stage Startups

Building exceptional software solutions and managing their successful release are two sides of the same coin. The significance of well-planned release management can't be overstated as it bridges the gap between development and deployment.

Today, we're delving into release management, exploring essential steps before merging pull requests into the main branch, and the ideal deployment process. We'll discuss everything from green builds and code reviews to deployment environments and continuous integration and deployment (CI/CD).

Pull Requests and Essential Pre-Landing Checks

Before landing a pull request into your main branch, certain prerequisites should be met:

  • Build is green: All builds must pass, indicating that your code compiles and runs as expected1.
  • Linter is green: Linters should indicate no errors, signifying that your code conforms to predefined coding standards2.
  • Unit tests are passing: All unit tests should pass, implying that individual components of your software work as intended3.
  • Code review and approval: Pull requests should be thoroughly reviewed and approved by another team member4.
  • Storybooks are passing (Frontend ): This ensures UI changes do not cause any unwanted deviations5.
  • Integration tests are passing: These high-level tests indicate your APIs function well in an environment similar to production6.

Deploying to Production in a Large Org

Once your pull request merges into the main branch, it's time to deploy to production. Start by deploying to a minimal number of machines before gradually increasing the deployment scale.

At large orgs, the deployment process often follows these patterns:

  1. Canary environment: A few machines receive the new version first7.
  2. Incremental deployment to data centers/regions: Begin with deploying to 1%, then 2%, then 5% of the machines across various regions. For instance, start with us-west, then us-east, then Europe, and so on8.

Between every step, manual approval or automated metrics-based approval should confirm that deployment to the next stage is safe. For mobile apps, internal releases followed by a gradual rollout on the App Store and Google Play is recommended9.

Generally speaking, these steps are too much overhead for a startup, and following our release practice of good manual and automated QA before and after releases is sufficient. Do what you can, know where things will eventually end up. But even large organizations may want to avoid some of these steps if they unnecessarily slow them down. It is all about context.

Deciding Deployment Cadence

The spectrum of deployment approaches ranges from CI/CD, where each pull request lands and gets deployed immediately, to scheduled deployments performed by on-call engineers.

While CI/CD promises single pull request deployments, easier outage detection, development time savings, and engineering excellence incentives, it increases the likelihood of unattended deployments10.

Scheduled deployments, on the other hand, tend to pile multiple pull requests per deployment, potentially increasing outage chances and creating an on-call engineer bottleneck11.

For smaller startups, a blend of CI/CD and on-demand deployments done by engineers is preferred. This approach ensures deployments are attended to and happen when desired. It minimizes having many pull requests per deployment and prevents on-call engineer bottlenecks.

Mapping Out Your Deployment Environments

Here are the recommended environments for your deployment process:

  • Development: On a developer machine. Ideally, everything needed on the local machine should be runnable in just one command.
  • Staging: An environment similar to production, but with non-production database/auth/configuration.
  • Next: Part of production, usually not exposed to the outside world.
  • Production: The public environment used by users/customers.

By aligning your processes with these guidelines, your startup's software release management will be a structured, efficient, and effective operation. It's all about striking a balance between rapid release cycles and ensuring the stability and quality of your software in production.

Footnotes

  1. Continuous Integration: Improving Software Quality and Reducing Risk - Duval et al
  2. Clean Code: A Handbook of Agile Software Craftsmanship - Robert C. Martin
  3. Pragmatic Unit Testing in Java 8 with JUnit - Jeff Langr
  4. Best Kept Secrets of Peer Code Review - Jason Cohen
  5. Storybook: UI component explorer for frontend developers
  6. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation - Humble et al
  7. Canary Deployments To Kubernetes Using Istio and Friends - Jason R. McVetta
  8. Release It!: Design and Deploy Production-Ready Software - Michael T. Nygard
  9. How to Successfully Roll Out Your New Mobile App - Forbes
  10. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation - Humble et al
  11. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win - Gene Kim