¿Deberíamos alojar código en línea?

Estamos buscando una buena solución de control de fuente y gestión de proyectos en mi lugar de trabajo y he sugerido crear una organización GitHub y repositorios privados. Amo GitHub por muchas razones, pero no se trata de GitHub (de hecho, mis colegas van a presentar puntos a favor de las plataformas de la competencia), se trata de almacenar nuestro código privado en línea .

Estoy tratando de entender si es una buena idea o no. Definitivamente parece ventajoso porque elimina la necesidad de costos de servidor (al menos directamente) y también facilita la búsqueda de código (todo está en línea).

Sin embargo, nuestro equipo está indeciso y me lleva a mi pregunta, ¿qué deberíamos considerar para tomar esta decisión?

Como profesional,

Si la oficina de su empresa se quema, el código todavía está en el servidor.

Si la oficina de su empresa no se quema, pero el servidor en el que se encuentra su repositorio git sí, entonces todavía tiene una copia local.

Si aloja su repositorio en su servidor en el edificio de oficinas de su empresa (como lo haría con una unidad compartida de red ...), entonces si la oficina de la empresa se incendia, perderá ambos.

Por supuesto, aún necesita copias de seguridad como de costumbre ...

Siéntase libre de reemplazar "quema" con "se infecta con ransomware".

Básicamente, la disponibilidad está arriba.

Como una estafa,

Tendría que compartir sus archivos con el tercero que alojará su código. Si tienes secretos de empresa realmente grandes, esto podría no estar permitido. Por ejemplo, si tiene una base de datos que contiene información personal de ciudadanos europeos, es posible que no se le permita alojar su código en un tercero de los EE. UU., Porque estarían sujetos a la ley de los EE. UU. Y, por lo tanto, no se podría confiar en que respetar las leyes de privacidad de la UE. Incluso si no se trata de un problema legal, debe tener en cuenta que se puede sobornar a un tercero para que entregue sus archivos privados. Esto probablemente sería realmente malo para el tercero (penalización de gran reputación), pero podría suceder.

Básicamente, la confidencialidad está baja.

Si está de acuerdo con el intercambio de confidencialidad por disponibilidad, es una buena idea alojar su código privado en línea con un tercero. De lo contrario, no lo hagas. Podría explicar las compensaciones para permitir que su jefe tome una decisión inteligente, pero es posible que escuche "no". Eso es lo que puede pasar si le das una decisión a alguien. Si tu jefe dice que no, entonces eso es todo. No creo que convencer a la fuerza a tu jefe sea una muy buena idea.

Obviamente es una cuestión de confianza en el proveedor y cuánto valora su código fuente.

Sin embargo, creo que está claro que, al menos en el pasado, las personas sobrevaloran su código fuente.

• Para productos de 'automatización de procesos de negocio'; donde un equipo interno crea sitios web y otro software específicamente para las necesidades del negocio. El valor de ese software para otras personas es generalmente muy bajo.

• Para software vendible; es el binario que está vendiendo, y que se puede copiar y hackear sin acceso al código fuente.

En segundo lugar: también debe considerar si almacenar su código con un tercero realmente aumenta su exposición por encima de su nivel actual. En muchos casos no lo hará

• Por ejemplo; Si su producto es un sitio web sin código de fondo, su código ya es público.
• Si su código compilado se distribuye, se puede descompilar.
• Si su código es un sitio web o servicio y lo está alojando con un tercero. Entonces el tercero puede descompilar su código.
• Si almacena sus copias de seguridad con un tercero, tienen acceso a su código.

En resumen, la mayoría de las empresas modernas confiarán en una variedad de terceros con sus actividades diarias; incluso cosas que son vitales y únicas para ellos.

Una parte de este proceso de decisión podría ser una pequeña prueba, prueba y error. Tome un pequeño proyecto y haga que algunos miembros prueben algunos de los diferentes sitios. Esto debería cubrir la usabilidad del equipo, pero hay otras consideraciones.

1. Infraestructura actual: algunas empresas ya tienen servidores, conexiones a Internet, VPN y personal con las habilidades para alojar servidores, por lo que algunos de los costos y las preocupaciones se pueden absorber mucho más fácilmente. Una startup puede estar más inclinada a usar algo como Github porque no tiene que hacer este tipo de inversiones y puede comenzar a funcionar antes.
2. Presupuesto: muchos aspectos del n. ° 1 se incluirán aquí, pero puede haber otras soluciones con un alto precio. Algunas compañías pueden justificar los costos. Obviamente con un presupuesto bajo, se eliminan muchas opciones.
3. Distribución del equipo: cuando todos trabajan fuera de la misma oficina durante las mismas horas, es posible que no necesite github. Si su servidor de archivos no está demasiado cargado, simplemente coloque Git en él.
4. Seguridad: probablemente pueda encontrar muchos sitios seguros, pero las percepciones de seguridad para algunos clientes son más importantes. Tener su propia red ironclad puede ser lo correcto para ganar su confianza. Insignias de seguridad, escáneres de retina y guardias armados solo gritan seguridad a algunos clientes.
5. Capacitación: no solo se trata de cómo usar la aplicación, sino de las reglas y procedimientos que su empresa / equipo desea implementar. Tener una idea de cómo quieres hacer las cosas puede impulsar qué herramientas usar. Atraer a miembros adicionales del equipo se vuelve un poco más fácil si les gusta cómo haces las cosas.

Comience a trabajar en todo el proceso de codificación y entrega. Cuantas más personas participen en este proceso, mejor. No desea adoptar una plataforma de control de fuente basada en ciertos criterios solo para que alguien en la administración cambie todo. "Esta cosa ágil distribuida no funciona, así que necesitaremos que todos comiencen a trabajar desde la oficina a las 8-7 a partir del lunes, de acuerdo".

No digo necesariamente que no deba alojar el repositorio de su empresa en la nube, pero personalmente he experimentado algunas desventajas y problemas con el alojamiento en la nube.

¿Qué tan rápido y confiable es su conexión a Internet?

Para mí, esa es la mayor consideración. Por ejemplo, mi empresa está ubicada en una bonita zona rural. Si bien nuestras velocidades dentro de la red son increíblemente rápidas, nuestras velocidades entre redes son lentas en el mejor de los casos, francamente flakey en el peor.

Dependiendo de qué VCS esté usando, parte del dolor puede mitigarse. Los sistemas de control de versiones distribuidos, como Git, no son tan malos porque aún puedes trabajar localmente. Incluso puede iniciar un nuevo repositorio en una unidad de red si realmente necesita compartir algún código con un compañero de trabajo. En comparación, no puedes hacer ninguna de esas cosas con Team Foundation (a pesar de todo el espacio de trabajo local).

Pero ese es solo el código. Hay mucho más en su repositorio alojado en la nube que solo el código. ¿Qué pasa con sus elementos de trabajo (características / lista de errores)? ¿Qué pasa con su documentación (wiki)? ¿Qué pasa con su construcción de integración continua? Es probable que todas estas cosas también estén alojadas en la nube junto con su código. Si su conexión a Internet se cae, ¿cómo va a trabajar sin estas cosas?

Gitlab proporciona una versión gratuita local que probablemente proporcionará más de lo que su equipo necesita. Recomiendo una instalación en las instalaciones. Reducirá los riesgos considerablemente.

¿Qué deberíamos considerar para tomar esta decisión?

Deberías considerar las desventajas. Yo (junto con otros) animé con éxito a mi empleador actual a que dejara de alojar las joyas de la propiedad intelectual de la corona de la compañía en un repositorio privado de Github. No me malinterpretes; Github es fantástico para el software de código abierto.

En el caso del software de código cerrado, ¿ha hecho que github.com (o alguna alternativa) firme un acuerdo de confidencialidad (NDA) para no divulgar su código fuente al mundo? ¡Buena suerte con eso!

En mi opinión, es una locura revelar las joyas de la propiedad intelectual de la corona a otra entidad hasta que esa otra entidad haya firmado un NDA con usted. Está planeando usar un servicio como github que no firma NDA con sus clientes. En cambio, ofrecen una vaga promesa en forma de un EULA (acuerdo de licencia de usuario final) muy largo.

Github se da cuenta de que esto puede ser un problema importante y, como resultado, ofrecen Github Enterprise como mecanismo para alojar el código fuente (y otras cosas privadas) en el propio servidor.