March 2023 Summaries

LaunchDarkly has introduced a new integration with GitHub called GitHub Actions Flag Evaluations. This solution, along with their existing Code References integration, makes GitHub and LaunchDarkly an incredibly powerful duo for developers as they construct their build, deploy, and release workflows. The integration allows actions to evaluate the values from feature flags when it is called, enabling conditional jobs and steps, dynamic values usage, and context targeting in Continuous Integration/Continuous Delivery (CI/CD) processes. This feature is available in beta today and can be integrated into GitHub repositories by developers with a few simple configurations.

A staging environment is crucial in the software development process as it serves as the final step before an application gets deployed in a production environment. It closely resembles a production environment, allowing for testing of software updates to ensure quality and identify potential issues before release. Staging environments are used to conduct various tests such as unit testing, regression testing, integration testing, and chaos testing. They play a key role in development but have limitations in fully replicating every possible scenario. Feature flags can help test in production by enabling or disabling specific functionalities without the need to deploy code, allowing for quick rollback of problematic features.

LaunchDarkly is an AI platform that helps teams understand user reactions to updates through data-driven experimentation. The platform offers various features for testing, learning, and refining ideas. In this post, five talks are highlighted that delve into experimentation with LaunchDarkly. These include an overview of the general landscape of LaunchDarkly's experimentation offering, a deep dive into instrumentation for developers, using feature flags to make data-driven decisions, overcoming challenges faced by product teams in running experiments, and five proven strategies for better experiments.

In a recent webinar, Forrester Principal Analyst Chris Condo and LaunchDarkly Senior Director of Product Marketing Ravi Thariyasi discussed how to connect DevOps Research and Assessment (DORA) metrics with business value. DORA metrics include deployment frequency, lead time, mean time to resolution, and change failure rate. While these metrics can help improve efficiency, it's essential for organizations to ensure they are being more efficient with the right activities that align with overall business objectives. The webinar also covered two stages of DORA metric adoption, beyond DORA metrics: speed != value, and how feature flags and feature management make experimentation easier.

Releases can be challenging and even scary, especially as companies scale. LaunchDarkly aims to make releases uneventful by transforming them into something more like watching paint dry. To achieve this, they suggest going slowly and sneaking around, waiting for safety, and exploring easier caves first. However, these approaches add friction and hinder agility. Instead, using feature flags can mitigate the effects of a failed release without impacting users. Automating complex rollouts allows teams to explore more sophisticated strategies and control releases step by step. Parent-child feature flags, progressive rollouts, scheduled maintenance windows, and custom workflows are some strategies that LaunchDarkly customers use for fine-grained control over their releases. Chronosphere uses LaunchDarkly to manage complex release programs, separating business decisions from engineering ones.

The Technology Acceptance Model (TAM) explains how people adopt new technology based on perceived usefulness and ease of use. Adopting feature flags can be challenging due to inertia, but a common pattern for successful adoption includes stages such as recognition, boolean era, great configuration, expansion, and experimentation. In the recognition stage, teams realize that their current branching strategy is unmanageable and start looking into concepts like trunk-based development. The boolean era involves changing workflows to accommodate feature flags, while the great configuration stage sees teams moving beyond simple toggles to multivariate flags and advanced targeting. In the expansion stage, feature management becomes a cross-functional practice, and in the experimentation stage, teams use feature flags for server-side experimentation to validate hypotheses with data. Taking time and not rushing the process is crucial for successful adoption of feature flags.

Containerization is a software development process that involves bundling an application's code with all the files and libraries needed to run on any infrastructure, making it easier to consistently deploy applications across different computing environments. Containers are self-sufficient software packages containing everything required to run an application, including executables, binary code, libraries, dependencies, and configuration files. Containerization enables developers to create and manage containers using tools based on the Open Container Initiative (OCI) image specification. Key benefits of containerization include portability, efficiency, agility, faster delivery, improved security, quicker startup times, and flexibility.

This article provides a comprehensive overview of database migrations, including terminology, motivation for migrating databases, common pitfalls along with their solutions, and strategic steps to accelerate the migration process. Database migration refers to moving data from one database to another while changing applications to consume data from and write data to the newly-migrated database. Homogeneous database migration involves moving an application and its data from one database to another with the same underlying DBMS, while heterogeneous database migration involves a change in the underlying DBMS engine. The article also discusses best practices for database migrations, such as thinking small, decoupling release from deployment, and feature flagging the data access layer. Additionally, it covers three release strategies: kill switch, progressive release, and strategic release.

Site reliability engineering (SRE), platform engineering, and DevOps are all related concepts aimed at optimizing and structuring different aspects of software delivery and deployment lifecycles. While there is some overlap between these roles, their primary areas of focus differ. SREs focus on site reliability, scalability, and availability of applications or products, while platform engineers build and maintain platforms that enable self-service for developers. DevOps aims to bridge the gap between software development and operations teams by improving collaboration, streamlining the software delivery lifecycle, and automating repetitive tasks. Platform engineering can support both SREs and DevOps by making it easier for developers to ship production-ready code while abstracting away the intricacies of software delivery.