React

Software Delivery

# Un acercamiento sencillo a feature flags en una aplicación React con TypeScript

Aunque ya he escrito en otras ocasiones sobre feature flags y como su uso nos
puede ayudar a alcanzar un flujo de entrega continua, en este artículo me
gustaría compartir una implementación sencilla en React utilizando TypeScript.

En esencia, una feature flag es un interruptor que nos permite activar o
desactivar una funcionalidad concreta bajo una serie de condiciones. Los tipos
de condiciones pueden ser muy variados: entorno de ejecución de la aplicación,
tipo de usuaria, porcentaje de tráfico, etc. Además, el cálculo de esa condición
puede realizarse dentro de la propia aplicación, o bien delegarse en otro
sistema.

Este concepto posibilita, entre otras cosas, desacoplar nuestro repositorio del
proceso de entrega de software. Siempre y cuando nuestras funcionalidades
incompletas estén protegidas bajo una feature flag, podremos integrar
continuamente nuestros cambios en la rama principal (aunque eso implique su
despliegue a producción o cualquier otro entorno).

## Publicando feature flags

El primer paso para comenzar a utilizar feature flags es definirlas en algún
sitio. Aunque existan servicios específicamente creados para trabajar con ellas
(que, además, ofrecen flujos y procesos mucho más refinados), yo siempre
recomiendo comenzar con un enfoque humilde, gestionando las feature flags
directamente en la aplicación. En este caso, vamos a crear un módulo que exporte
las diferentes feature flags y una función para obtener su estado:

```tsx
export const Features = {
  newSettingsPage: () => process.env.NODE_ENV === "development",
};
```

La única razón de asociar una función a la feature flag en lugar de directamente
un booleano es dotarle de cierta flexibilidad (realmente, sería incluso más
interesante hacer que la función devolviese una promesa -de esa manera,
estaríamos cubriendo el caso en el que, para calcular el valor de una feature
flag, tuviésemos que realizar una petición a un servicio externo).

## Integrando la aplicación React con las feature flags

Ahora que ya tenemos un módulo encargado de publicar las feature flags de la
aplicación, es hora de hacerlo accesible desde los componentes React.

El enfoque más directo, sería importar el módulo desde las diferentes páginas o
componentes que lo utilicen y realizar después las operaciones para
mostrar/ocultar alguna parte de la interfaz. Aunque este enfoque funcionaría
estaríamos creando una dependencia no explícita entre nuestros diferentes
componentes y un elemento global (el módulo de `Features`) lo que hará que
probar nuestros componentes en cada uno de los estados sea más complejo.

Vamos a verlo con un ejemplo:

```tsx
import { Features } from "../lib/Features";

export function Menu() {
  return (
    <nav>
      <ul>
        <li>
          <a href="/dashboard">Dashboard</a>
        </li>

        <li>
          <a href="/profile">Profile</a>
        </li>

        {Features.newSettingsPage() && (
          <li>
            <a href="/settings">Settings</a>
          </li>
        )}
      </ul>
    </nav>
  );
}
```

En esta implementación, `Menu` utiliza directamente el módulo de `Features` para
saber si tiene que mostrar o no la opción de ajustes. A la hora de probar este
componente, tenemos que tener en cuenta esta dependencia y utilizar un _stub_
para poder ajustarlo a ambos escenarios:

```tsx
/**
 * @jest-environment jsdom
 */

import { render, screen } from "@testing-library/react";
import { Features } from "../lib/Features";
import { Menu } from "./Menu";

describe("Menu", () => {
  it("doesn't show Settings if the feature is disabled", async () => {
    render(<Menu />);

    expect(screen.queryByText("Settings")).toBeNull();
  });

  it("shows Settings if the feature is enabled", async () => {
    jest.spyOn(Features, "newSettingsPage").mockImplementationOnce(() => true);

    render(<Menu />);

    expect(screen.queryByText("Settings")).not.toBeNull();
  });
});
```

Los stubs (o test doubles en general) son recursos muy útiles pero me gusta
reservar su uso para situaciones donde no tengo ninguna otra opción más
idiomática para probar el sujeto bajo test. En este caso, lo ideal sería
convertir esa dependencia no explícita en algo que pudiésemos controlar desde el
exterior, utilizando inyección de dependencias. En React, tendríamos varias
opciones para conseguirlo. Veamos un par de ellas.

### Obtener las feature flags a través de una prop

Por ejemplo, utilizando una prop `features` para poder recibir el objeto
completo de feature flags. El problema con este enfoque es que podría haber
muchos componentes intermedios que necesiten propagar esta prop sin necesidad de
utilizarla. Este fenómeno se denomina
[Prop Drilling](https://kentcdodds.com/blog/prop-drilling) y, aunque no es malo
_per se_, puede convertirse en algo difícil de gestionar cuando nuestra
aplicación crezca en número de componentes.

```tsx
import { Features } from "../lib/Features";

export function Menu({ features }: { features: typeof Features }) {
  return (
    <nav>
      <ul>
        <li>
          <a href="/dashboard">Dashboard</a>
        </li>

        <li>
          <a href="/profile">Profile</a>
        </li>

        {features.newSettingsPage() && (
          <li>
            <a href="/settings">Settings</a>
          </li>
        )}
      </ul>
    </nav>
  );
}
```

Ahora que el componente `Menu` obtiene la información de las feature flags a
través de una prop, podemos ajustar los diferentes escenarios para las pruebas
sin necesidad de utilizar test doubles:

```tsx
/**
 * @jest-environment jsdom
 */

import { render, screen } from "@testing-library/react";
import { Menu } from "./Menu";

describe("Menu", () => {
  it("doesn't show Settings if the feature is disabled", async () => {
    render(<Menu features={{ newSettingsPage: () => false }} />);

    expect(screen.queryByText("Settings")).toBeNull();
  });

  it("shows Settings if the feature is enabled", async () => {
    render(<Menu features={{ newSettingsPage: () => true }} />);

    expect(screen.queryByText("Settings")).not.toBeNull();
  });
});
```

### Obtener las feature flags a través de la API de contextos

Bien utilizada, la
[API de contextos de React](https://reactjs.org/docs/context.html) puede servir
como un contenedor de inyección de dependencias que permita aislar a los
componentes padre de las dependencias concretas de sus componentes hijo. En este
caso, vamos a crear un nuevo contexto que publique las feature flags disponibles
dentro de la aplicación y que permita acceder a ellas a través de un hook
concreto, `useFeatures`.

Lo primero, es definir el propio contexto encargado de devolver las feature
flags existentes. Junto a él, también definiremos el hook que se utilizará
después desde nuestros componentes. Este último es una simple capa de
abstracción que centraliza la lógica común de acceso.

```tsx
import { createContext, useContext } from "react";

export const Features = {
  newSettingsPage: () => process.env.NODE_ENV === "development",
};

export const FeaturesContext = createContext(Features);

export function useFeatures() {
  return useContext(FeaturesContext);
}
```

Los contextos en React se crean con un valor por defecto. En caso de que no
exista ningún proveedor que sobrescriba el valor para el contexto, nuestros
componentes recibirán ese valor al acceder a él. En este caso, hemos creado el
contexto utilizando como valor por defecto el propio objeto exportado por
`Features`.

```tsx
import { useFeatures } from "../lib/Features";

export function Menu() {
  const features = useFeatures();

  return (
    <nav>
      <ul>
        <li>
          <a href="/dashboard">Dashboard</a>
        </li>

        <li>
          <a href="/profile">Profile</a>
        </li>

        {features.newSettingsPage() && (
          <li>
            <a href="/settings">Settings</a>
          </li>
        )}
      </ul>
    </nav>
  );
}
```

Ahora que nuestro componente `Menu` utiliza el nuevo contexto, sólo necesitamos
envolver el componente en diferentes proveedores cuando queramos probar
distintos escenarios:

```tsx
/**
 * @jest-environment jsdom
 */

import { render, screen } from "@testing-library/react";
import { FeaturesContext } from "../lib/Features";
import { Menu } from "./Menu";

describe("Menu", () => {
  it("doesn't show Settings if the feature is disabled", async () => {
    render(
      <FeaturesContext.Provider value={{ newSettingsPage: () => false }}>
        <Menu />
      </FeaturesContext.Provider>,
    );

    expect(screen.queryByText("Settings")).toBeNull();
  });

  it("shows Settings if the feature is enabled", async () => {
    render(
      <FeaturesContext.Provider value={{ newSettingsPage: () => true }}>
        <Menu />
      </FeaturesContext.Provider>,
    );

    expect(screen.queryByText("Settings")).not.toBeNull();
  });
});
```

## `<FeatureFlag />`, un componente para abstraernos por completo

Si utilizamos la API de contextos, podemos ir todavía un paso más allá y
abstraernos por completo de la gestión de funcionalidades disponibles. En este
caso, vamos a crear un componente `FeatureFlag` que recibirá la flag sobre la
que queremos trabajar y los nodos que queremos ocultar en caso de no estar
disponible:

```tsx
import { ReactNode } from "react";
import { Features, useFeatures } from "../lib/Features";

type FeatureFlagProps = { children: ReactNode; flag: keyof typeof Features };

export function FeatureFlag({ children, flag }: FeatureFlagProps) {
  const features = useFeatures();

  if (features[flag]()) {
    return <>{children}</>;
  }

  return null;
}
```

Al definir la prop de `flag` como `keyof typeof Features` estamos tomando
ventaja de la ayuda del compilador de TypeScript, que nos dirá automáticamente
que funcionalidades existen y evitará que utilicemos flags que no se encuentran
en el objeto global de `Features`.

```tsx
import { FeatureFlag } from "./FeatureFlag";

export function Menu() {
  return (
    <nav>
      <ul>
        <li>
          <a href="/dashboard">Dashboard</a>
        </li>

        <li>
          <a href="/profile">Profile</a>
        </li>

        <FeatureFlag flag="newSettingsPage">
          <li>
            <a href="/settings">Settings</a>
          </li>
        </FeatureFlag>
      </ul>
    </nav>
  );
}
```

Con este último enfoque, nuestras pruebas anteriores utilizando el proveedor del
contexto de feature flags seguirán funcionando (ya que es el mecanismo sobre el
que se construye todo) a la vez que tomamos ventaja de un diseño mucho más
idiomático, encapsulando la gestión de feature flags en su propio componente
React.


Un acercamiento sencillo a feature flags en una aplicación React con TypeScript

# Desacoplando la entrega de software de los sistemas de control de versiones

Como una extensión más de la
[ley de Conway](https://es.wikipedia.org/wiki/Ley_de_Conway), es muy habitual
encontrarse con proyectos donde la estrategia de _branching_ del sistema de
control de versiones está fuertemente relacionada con la estrategia de entrega
de software. Esta relación entre ambos mundos puede parecer conveniente (por
ejemplo: utilizar una rama para representar el código _vivo_ en producción o
_staging_, congelar los cambios que van a desplegarse en una rama `release/*`,
etc.) pero, con el paso del tiempo, puede traer consigo efectos
contraproducentes:

- **Viola el principio de responsabilidad única**. Si algo nos queda claro sobre
  el _Single Reponsability Principle_ es que cada abstracción sólo debe tener
  _una única razón para cambiar_ (en palabras de Robert C. Martin). Si cambios
  en los procesos de entrega de software (flujos de resolución de _hotfixes_,
  nuevos entornos) implican cambios en la estructura de nuestro repositorio (o
  cambios en la manera de interactuar con él), los límites entre ambos contextos
  no están bien establecidos.
- **Todo se vuelve innecesariamente complejo**. Aún con flujos muy populares
  como `git-flow` (y herramientas muy sofisticadas a su alrededor, construidas
  como una capa de abstracción sobre `git`), se _hackea_ el sistema de control
  de versiones para dejar de ser una herramienta de _tracking_ y colaboración
  por un sistema de despliegue y configuración.
- **Resta flexibilidad**. Si es el sistema de control de versiones el encargado
  de determinar qué funcionalidades se van a liberar al final de una iteración,
  se pueden dar situaciones en las que una rama se quede _congelada_ por
  contener funcionalidad defectuosa que inevitablemente contamina al resto de
  cambios de esa misma rama, bloqueando la entrega de nueva funcionalidad.

![Imagen de un repositorio que utiliza git-flow](/static/articles/decoupling-vcs-from-software-delivery/git-flow.jpg "Este repositorio utiliza el sistema de control de versiones como una herramienta de entrega de software para la próxima iteración (aplicando un flujo similar a git-flow)")

Para aliviar los problemas anteriores, una solución pasa por mover la
responsabilidad de decidir qué funcionalidades están disponibles en cada entorno
desde el sistema de control de versiones a la propia base de código. Es decir,
decidir programáticamente si una funcionalidad está habilitada o no en función
de en qué entorno se está ejecutando la aplicación.

Una representación habitual de este principio es a través del uso de
[Feature Flags](https://featureflags.io), que no dejan de ser, conceptualmente,
bloques condicionales que se sitúan en algún punto de nuestra base de código y
deciden si un camino de ejecución debe evaluarse o no.

Con esta estrategia, únicamente necesitaríamos una rama `master` donde fusionar
las _feature branches_ de funcionalidades terminadas y una configuración de
_feature flags_ que defina los entornos en los que estarían disponibles. Por
ejemplo: habilitar la funcionalidad únicamente en entornos de _staging_ para
realizar pruebas de rendimiento, labores de _quality assurance_, etc. La
resolución de hotfixes, se podría realizar igualmente sobre la rama `master`,
pues es esta la que siempre se despliega y define qué funcionalidades estarían
disponibles en cada momento y para cada entorno.

![Imagen de un repositorio con una única rama master y múltiples feature branches](/static/articles/decoupling-vcs-from-software-delivery/with-feature-flags.jpg "En este ejemplo, el repositorio es agnóstico de la capa de entrega de software, que estará gestionada por la propia base de código mediante el uso de feature toggles.")

Siguiendo esta dirección, también se obtendrían beneficios adicionales como, por
ejemplo, poder realizar _merges_ de manera mucho más recurrente (al estar el
entorno de producción siempre protegido a través de _feature flags_). Esto
podría derivar, a su vez, en procesos de _code review_ con un número menor de
cambios y ciclos de _feedback_ más cortos, siempre que lo combinemos con
técnicas como _continuous integration_ y _continuous delivery_.

## Otras lecturas relacionadas

- [Decoupling Deployment from Release - ThoughtWorks’ Technology Radar](https://www.thoughtworks.com/radar/techniques/decoupling-deployment-from-release)


Desacoplando la entrega de software de los sistemas de control de versiones

# Branch by Abstraction en Componentes React

En ocasiones, nos vemos en la situación de tener que actualizar varios
componentes de nuestra interfaz de usuario para ajustarlos a nuevas directrices
de diseño. Otras veces, necesitamos reemplazar su implementación para hacer
frente a nuevos requisitos de negocio. Si el número de cambios es lo
suficientemente alto, es posible que no se puedan realizar de manera atómica (o
tengan que ser sincronizados con eventos fuera del control del equipo de
desarrollo como, por ejemplo, la publicación de una nueva imagen de marca) a la
vez que necesitamos continuar entregando valor en forma de nuevas
funcionalidades, corrigiendo defectos o aplicando alguna que otra mejora.

En este artículo vamos a hablar sobre una estrategia que nos permita obtener un
flujo de integración continua evitando, por tanto, mantener los cambios en
nuestros componentes en una rama independiente en el sistema de control de
versiones durante el transcurso de su desarrollo.

¿Cómo lo conseguiremos? Haciendo uso de dos técnicas muy habituales en equipos
que trabajan con prácticas como _continuous integration_ o _continuous
delivery_: [Feature Flags](http://featureflags.io/) (o Feature Toggles si
[leéis a Martin Fowler](https://martinfowler.com/bliki/FeatureToggle.html)) y
[Branch By Abstraction](https://martinfowler.com/bliki/BranchByAbstraction.html).

Ambas estrategias nos permitirán fusionar código de manera regular sobre la rama
principal, aún con funcionalidades parcialmente terminadas, evitando así
mantener ramas en paralelo que podrían estar días (o semanas) sin integrarse con
el trabajo realizado por el resto del equipo.

> Las feature flags son, conceptualmente, bloques condicionales que permiten
> habilitar o deshabilitar una funcionalidad (o un camino de ejecución) en base
> a un conjunto de condiciones (como pueden ser: el entorno de ejecución, el
> perfil del usuario o un porcentaje de tráfico)

Pongamos como ejemplo que, en nuestra aplicación, llevamos ya un tiempo
utilizando `<AwesomeCalendar />` (un componente de terceros) como _widget_ de
calendario. En los puntos donde es necesario mostrar un calendario, importamos
el componente y lo insertamos en el _layout_ de la página.

```tsx
import React from "react";

import { AwesomeCalendar } from "awesome-calendar";

function Page() {
  return (
    <Page>
      <Header />

      <Body>
        <AwesomeCalendar date={new Date(2018, 6, 21)} />
      </Body>
    </Page>
  );
}
```

Debido a una serie de requisitos, tenemos que crear un nuevo componente para
mostrar un calendario que sustituya a `AwesomeCalendar` y le añada un _extra_ de
funcionalidad para dar cabida a nuevas historias de usuario. El desarrollo del
componente se extenderá durante varias semanas.

El primer paso para poder integrar nuestro componente de manera continua es
asegurar que somos capaces de controlar cuándo y cómo se utiliza para poder
aislar a los consumidores de `AwesomeCalendar` de los cambios en el mismo. Para
ello, vamos a empezar creando una nueva _abstracción_ `Calendar` que pasará a
ser utilizada por el resto de componentes y mantendrá la misma interfaz que
ofrecía `AwesomeCalendar`:

```tsx
import React from "react";

import { AwesomeCalendar } from "awesome-calendar";

export function Calendar({ date }: { date: Date }) {
  return <AwesomeCalendar date={date} />;
}
```

Como vemos, la manera de consumir este nuevo componente sería muy parecida a la
versión anterior:

```tsx
import React from "react";

import { Calendar } from "../components";

function Page() {
  return (
    <Page>
      <Header />

      <Body>
        <Calendar date={new Date(2018, 6, 21)} />
      </Body>
    </Page>
  );
}
```

> En este punto, ya podríamos fusionar nuestros cambios con la rama de código
> principal para que el resto de trabajo en curso pueda ir haciendo uso de
> nuestro (no tan) _nuevo_ componente.

A continuación, vamos a crear una implementación muy sencilla de nuestro propio
calendario, que empezará apoyándose en una implementación nativa de `datetime`
pero respetando la interfaz original del componente `AwesomeCalendar`:

```tsx
import React from "react";

export function NewCalendar({ date }: { date: Date }) {
  const value = /* implementation details */;

  return <input type="datetime-local" value={value} />;
}
```

Una vez hemos eliminado la responsabilidad de elegir qué calendario utilizar de
los consumidores del componente, podemos utilizar _feature flags_ para
determinar qué calendario mostrar en cada momento.

En este caso, vamos a permitir que cualquier entorno que **no sea producción**
utilice siempre nuestro propio calendario, con el objetivo de obtener _feedback_
sobre su experiencia de uso a medida que avanzamos en su desarrollo:

```ts
export function isNewCalendarEnabled() {
  return process.env.NODE_ENV !== "production";
}
```

> Este caso, representamos la feature flag con una simple función que comprueba
> el entorno de ejecución actual, pero existen
> [sistemas más sofisticados](https://github.com/Unleash/unleash) para gestionar
> el estado de los _toggles_ en nuestra aplicación.

Ahora, nuestra nueva abstracción `Calendar` (que hace las veces de factoría)
puede hacer uso de esta función para determinar qué componente de calendario
utilizar, manteniendo al resto de consumidores aislados de toda complejidad:

```tsx
import React from "react";

import { AwesomeCalendar } from "awesome-calendar";

import { NewCalendar } from "./components";

import { isNewCalendarEnabled } from "../features";

export function Calendar(props: { date: Date }) {
  return isNewCalendarEnabled() ? (
    <NewCalendar {...props} />
  ) : (
    <AwesomeCalendar {...props} />
  );
}
```

A partir de este momento, todas las pantallas de nuestra interfaz de usuario que
necesiten de un calendario, utilizarán la abstracción `Calendar` y será esta
misma abstracción la que se encargará de utilizar la implementación concreta del
calendario que corresponda en función del entorno de ejecución.

Como vemos, aplicar técnicas como _branch by abstraction_ y _feature flags_ nos
permite alcanzar un flujo de integración (y entrega) continua en nuestros
componentes aportándonos beneficios cómo:

- Minimizar la superficie de cambios a fusionar cuando integramos trabajo en
  curso
- Tomar el control sobre cuándo se ejercita un camino de ejecución y poder
  habilitarlo y deshabilitarlo en base a una serie de condiciones
- Dotar a los equipos de negocio de visibilidad sobre el trabajo en curso en
  tareas de larga duración (sin sacrificar ninguna de las premisas anteriores)


Collection: Software Delivery

2020

2019

Browse all collections