August 2015 Summaries

In this episode of To Be Continuous, Edith Harbaugh and Paul Biggar discuss the concept of continuous delivery in software development. They talk about how it can help teams move faster by allowing them to release small changes frequently instead of large batches infrequently. They also touch on the importance of decentralization and trust within a team when implementing continuous delivery practices. Additionally, they explore the relationship between continuous delivery and product management processes, as well as the challenges that arise from managing risk in software development.

Google employs a canary release strategy for ensuring the stability and high quality of its products. This involves rolling out new features to some users, monitoring their performance, and reverting them if necessary. Google's first canary is its own employee base, followed by external users. The company uses extensive unit tests and continuous integration for major products like Google Mail. By using real-world users as a staging environment, Google ensures that it designs for the actual world rather than a laboratory setting. This approach provides stability through having a release to roll back to and valuable feedback from users.

The author has recently started working at LaunchDarkly after graduating from NYU. Despite moving across the country, they have found a sense of belonging in San Francisco. As the fifth member of the team, their role involves wearing many figurative hats, including coding for the website and organizing T-shirts for Meetups. The work environment is engaging and collaborative, with regular coffee breaks to maintain sanity and prevent overworking. The team members are close-knit, supporting each other in their tasks and fostering a learning atmosphere. The author is excited about the future of LaunchDarkly and looks forward to exploring new frontiers with the team.

The text discusses the integration of an application with Stripe's API for payment processing. It praises the polish of Stripe's API, documentation, and SDK ergonomics but highlights two issues during development/testing: testing webhook processing and webhooks from one test environment being sent to another. The author provides a detailed explanation on how to handle webhooks from Stripe, including verifying their authenticity and avoiding replay attacks. They also discuss the difficulty of integration testing due to delays in sending invoice webhook events by Stripe. To resolve this issue, they suggest disabling the authenticity check in test mode. The text further explores how other companies handle multiple environments for testing purposes and suggests improvements that could be made to Stripe's system.

LaunchDarkly is a feature flag management service that allows users to control software releases by separating deployment and rollout processes. It enables various use cases such as rolling out features to specific user groups, gradual feature release with metric tracking, disabling problematic features without redeployment, granting access based on user attributes, and enabling maintenance without taking the entire application offline. While event tracking is important for some of these use cases, LaunchDarkly's primary focus is on feature flags as a service to help build better software faster.

Facebook's engineering success is attributed to their "Move Fast With Stable Infra" approach and the in-house system called Gatekeeper. This system allows them to quickly iterate features based on feedback, separate deployment from rollout, and maintain stability. Key components of this strategy include internal usage for quick feature feedback, staged rollouts, dynamic configuration, right hand side units for microservices, shadow production for load testing, data-informed decisions, advance country launches, and soft launches. By using feature flags and Gatekeeper, Facebook can quickly isolate the impact of a change, make data-informed decisions, and control user visibility.

The author has been working at LaunchDarkly for six months and finds the company's culture to be its best attribute. They appreciate the supportive, non-pretentious environment where everyone is encouraged to learn and grow. The team values work/life balance and prioritizes community involvement and celebrating achievements. The company is expanding with new features and employees, and the author looks forward to what the future holds for LaunchDarkly.

The text discusses the author's experience with using Docker for local development and concludes that it is not beneficial for most development stacks due to its complexity and lack of benefits. The main issue arises from the need for separate "non-production" container definitions, which negates one of the primary advantages of using containers. Additionally, the author found no compelling advantages in using Docker for local development after setting up a working solution with docker-osx-dev and boot2dorker. The author suggests that running backing services like databases, caching, storage, etc., in Docker makes sense but not for local development of compiled languages.

LaunchDarkly introduces support for multiple environments, enabling users to manage feature flags throughout their entire continuous delivery pipeline. Upon account creation, two environments are provided - Test and Production. Flags can have different targeting and rollout rules for each environment, allowing for separate testing and deployment stages. Each environment has its own API key, with the option to create, rename or delete custom environments. This feature aims to help users build better software faster using feature flags as a service.