Escalando krodox.com

Este post no es sobre las Aplicaciones Web de Krodox, sino sobre Krodox.com, nuestro "sitio de contenido", el lugar donde promocionamos nuestros servicios y ecosistema, publicamos ayuda y otros contenidos, reclutamos nuevos Krodoxs, y más. En última instancia, es el lugar donde contamos nuestra historia al mundo.

Cuando la gente piensa en escalabilidad web, a menudo piensa en solicitudes, servidores y balanceadores de carga. Usamos (y amamos) Elastic Beanstalk, así que esto no es un problema para nosotros. El verdadero problema son las personas: a medida que Krodox ha crecido, el desafío es crear un sistema en el que muchas personas de diferentes equipos (redactores, vendedores, desarrolladores, etc.) puedan contribuir a las diversas partes de nuestro sitio.

Cada equipo que alcanza un cierto tamaño enfrenta este problema, y es un desafío de escalabilidad mucho más difícil que agregar servidores. Los equipos que lo superan tienen excelentes sitios web, donde el contenido se actualiza y la historia evoluciona sin esfuerzo con el equipo.

En Krodox, hemos encontrado una forma de desplegar rápidamente cambios en nuestro sitio de contenido. Los compañeros no técnicos pueden participar y ver sus actualizaciones en tiempo real, sin cuellos de botella y sin solicitudes a los desarrolladores. Todo lo que hacemos está controlado por versiones con Git, incluso los cambios de texto. Prácticamente cada equipo contribuye de alguna manera al sitio cada semana, y lo hacemos sin un desarrollador web dedicado. Estamos ahorrando tanto tiempo que podemos escribir publicaciones de blog sobre ello.

Aquí está cómo lo hacemos:

Todos aprenden Markdown; todo el contenido está en Markdown

Markdown es la habilidad mínima requerida para contribuir a Krodox.com. No necesitas saber programar. Afortunadamente, si puedes escribir, puedes escribir en Markdown. Todos en Krodox leen este artículo de Daring Fireball para familiarizarse con las convenciones. Si necesitas usar un fragmento de HTML, como un código de incrustación de video, Markdown lo analiza sin problemas.

Cada página de nuestro sitio se basa en un archivo Markdown: cada página de aterrizaje, cada artículo, cada oferta de trabajo, cada producto y cada aplicación de exhibición. Literalmente, cada palabra en nuestro sitio está en un archivo Markdown que cualquier miembro de nuestro equipo puede editar.

Hacemos nuestros cambios en Github

Nuestro contenido (páginas, artículos, documentación, etc.) está organizado en repositorios privados de Github a los que todos los equipos (en Krodox) tienen acceso. Por ejemplo, los redactores tienen acceso al repositorio donde están los artículos; los vendedores al repositorio donde están las páginas de aterrizaje; el equipo de RRHH donde están las ofertas de trabajo, etc.

Crean y editan los archivos Markdown directamente a través de la interfaz web de Github. Los compañeros técnicos pueden clonar el repositorio localmente y usar cualquier herramienta o IDE que elijan.

Los compañeros no técnicos no necesitan saber Git. De hecho, no necesitan habilidades técnicas de ningún tipo. Solo necesitan saber que "commit" básicamente equivale a "guardar" y que no pueden romper nada porque todo está controlado por versiones.

¿Por qué es esto tan importante? La gran mayoría de los redactores solo necesitan una cuenta de Github y un navegador web. Damos acceso a nuestro contenido enviando una "invitación" de Github a nuestro repositorio. ¡Eso es todo!

En Krodox.com, nadie tiene acceso a un "backend". En realidad, no existe tal cosa. No tenemos que lidiar con permisos, contraseñas, y todos los dolores de cabeza y recursos que eso podría implicar. ¡Lo mantenemos simple!

Además, el editor de Github renderiza el Markdown después de confirmar los cambios, por lo que nuestros compañeros de equipo pueden ver que su formato de Markdown funcionó. Pero aún mejor, hemos encontrado una manera de mostrarles a nuestros compañeros sus cambios inmediatamente en el sitio web.

Así es como…

Nuestro servidor de pruebas es en tiempo real

Usando los Post-Receive Hooks de Github, cada vez que alguien hace un commit, Github avisa a nuestro servidor de pruebas para que extraiga y despliegue una nueva versión del contenido. La persona que agregó el contenido puede ver inmediatamente su cambio (en tiempo real) en nuestro servidor de pruebas y compartirlo con el equipo si requiere retroalimentación.

Antes de desplegar, probamos y aprobamos

Antes de que empujemos cualquier cambio a nuestro servidor de producción, un Editor en Jefe hace el QA (aseguramiento de calidad) correspondiente en el servidor de pruebas para asegurarse de que los enlaces resuelvan, los recursos (fotos, videos, tweets, enlaces) se carguen y no haya errores.

Desplegando a Krodox.com

Nuestro Editor en Jefe es el responsable de aprobar y hacer commit a Producción fusionando los cambios con la rama "aprobada". Github instantáneamente avisa a nuestro servidor de producción para que extraiga y despliegue una nueva versión del contenido en esa rama.

Así que el contenido llega a nuestro sitio de contenido sin ninguna interacción de ninguno de nuestros desarrolladores y, lo que es más importante... ¡Seguro!

El trabajo en Github se sincroniza con nuestra app de colaboración online (Basecamp)

No es sorprendente que usemos Basecamp para rastrear todo el trabajo que estamos haciendo en toda la empresa. Cada vez que alguien guarda/hace commit, agrega el id de tarea relevante de basecamp #task_id al mensaje de commit; esto comenta la historia asociada en Basecamp con un enlace al commit en Github, mostrando a todo el equipo que el trabajo se ha hecho.

¿Y la media (fotos, videos, etc.)?

Bueno... Eso es una bestia completamente diferente... Volveremos sobre ello en otro artículo.