¿Existen compañías serias que no usan control de versiones e integración continua? ¿Por qué?

Un colega mío tenía la impresión de que nuestro departamento de software era muy avanzado, ya que utilizamos un servidor de compilación con integración continua y un software de control de versiones. Esto no coincidía con mi punto de vista, ya que solo conozco una empresa que hice software serio y que tampoco tenía. Sin embargo, mi experiencia se limita solo a un puñado de empresas.

¿Alguien sabe de alguna compañía real (más de 3 programadores) , que esté en el negocio del software y no use estas herramientas? Si tal empresa existe, ¿hay alguna buena razón para que no lo hagan?

No estoy seguro de que los llame un acto serio, pero MySpace es bastante pobre en este frente: consulte http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill- myspace.html .

Te sorprendería ver lo que la realidad puede hacer al sentido común ;-)

Creo que todavía hay algunas compañías que no usan un sistema de control de versiones. Curiosamente, en todos los casos que he visto hasta ahora, ¡no es porque se opongan voluntariamente al uso de tales sistemas, sino porque no saben que existe algo como SVN! En cuanto a mí: estoy totalmente de acuerdo con usted y no puedo imaginar una situación en la que no quiera usar ningún tipo de control de versiones. Demonios, incluso estoy empujando mis propios archivos personales (documentos de texto, etc.) en la PC de mi casa en un repositorio GIT.

En el caso del sistema de integración continua, es un poco más común no emplearlos en las operaciones diarias. A veces también porque la gente no sabe que tal sistema existe, pero también he visto casos en los que la excusa, muy cuestionable, para no usarlos es que "no somos lo suficientemente complejos" o "funciona muy bien sin una integración continua, Entonces, ¿por qué molestarse en agregar otra tecnología? " Por supuesto que no resiste una evaluación realista - pero para responder a la pregunta original: Todo no es que fuera de lo común.

Casi todas las empresas de mi industria (banca) utilizan actualmente el control de versiones. Pero ciertamente es posible desarrollar software exitosamente sin control de versiones. Hace 20-30 años. Hicimos exactamente eso.

Yo diría que muchos bancos, tal vez incluso la mayoría, no usan un servidor de compilación con integración continua. Si ya está entregando software con éxito sin una integración continua, es perfectamente racional continuar por ese camino.

Solo para contrarrestar la respuesta de @ RoadWarrior:

Yo trabajo para un banco. He pasado los últimos 3 años implementando el control de versiones y ahora he logrado ponerlo en alrededor del 20% de nuestra base de código (que es bastante grande, tenemos aproximadamente 20 desarrolladores y hemos desarrollado nuestros sistemas durante> 16 años)

A través de mis contactos en la industria (Banca), sé de un muchos otros institutos financieros que no tienen lo que cualquier persona sensata llamaría control de versiones.

Sí, nuestra industria (desarrollo de software) es mucho más triste de lo que a la mayoría le gustaría admitir.

control de versiones: en mi primer trabajo hace 25 años no había un sistema de control de versiones como tal, pero este era RSX11 en PDP-11. Sin embargo, hubo un nivel muy alto de control de calidad con revisiones formales de diseño y código (esto fue en la industria nuclear).

Todos los trabajos desde entonces han utilizado sistemas de control de versiones, incluidos SCCS, PVCS, clearcase, cvs y forzar.

Entonces, en mi experiencia, el uso del control de versiones es bastante universal en el desarrollo de software serio.

Integración continua: esto es más un problema, especialmente en lugares que tienen mucho código heredado que probablemente ni siquiera tiene mucho en el camino de las pruebas automatizadas. Se necesita una gran inversión para trasladar el código existente a un entorno de CI, y aunque probablemente valga la pena al final, es difícil lograr que la administración se comprometa a dicha inversión sin ganancias a corto plazo.

Trabajé en un lugar (un gran banco) que tenía CI para algunos proyectos, e implementamos un tipo de sistema de CI en nuestro proyecto que hizo las cosas mucho más fáciles, pero me llevó unos 6 meses.

Me imagino que la mayoría de las empresas no usan estas cosas, porque no entienden los beneficios y sus desarrolladores no quieren aprender o tienen miedo de "revolver el pozo" haciendo cosas diferentes a cómo han sido hecho antes.

Aunque ahora soy un empleado, solía ser autónomo como consultor de bases de datos. Durante esos muchos, muchos años, estuve en algún lugar entre 800 y 1000 empresas, desde el nivel familiar hasta los Fortune 100.

Vi relativamente pocos lugares que hicieron una integración continua, pero no recuerdo haber visto nunca una compañía que no utilizara el control de versiones. Vi algunos en los que no había un depósito centralizado para el código controlado por versión. Los programadores individuales utilizaron el control de versiones en sus propias computadoras o mantuvieron el código controlado por versiones en algún lugar debajo de su directorio de inicio en el servidor.

No creo que ninguna de estas compañías estuviera en el negocio del software, pero sus programadores ciertamente lo estaban.

Un colega mío tenía la impresión de que nuestro departamento de software estaba muy avanzado, ya que utilizamos tanto un servidor de compilación con integración continua como un software de control de versiones.

No, odio decirlo, pero esto es cierto. Los dos últimos lugares donde trabajé (una división de un banco y una compañía financiera), fui quien implementó el sistema de control de versiones. Varios lugares (especialmente las tiendas que no son de software) no entienden por qué es realmente necesario para el desarrollo a largo plazo. El equipo normalmente comienza como una o dos personas y luego crece a partir de ahí, aunque dolorosamente. Con una o dos personas pueden pasar (no bien) sin ella porque pueden estar en comunicación casi constante entre sí.

La construcción continua es un caso completamente diferente. Si tuviera que adivinar, apostaría a que casi el 90% de los lugares donde se realiza el desarrollo no tiene una solución de CI. Voy a conferencias y la mayoría de las personas se sorprenden de que una organización que no sea MS o Google lo tenga. Lo que he encontrado es que la administración no quiere gastar la pequeña suma de dinero para ponerlo en funcionamiento, aunque puede ahorrar mucho tiempo.

Las principales razones que he encontrado para esto son:

1. Las personas en la gerencia han subido de rango en la misma organización. Nunca lo usaron y no lo necesitaban, ¿por qué tendrían que cambiar ahora? Algunos que he encontrado tienen miedo al cambio. Algo nuevo da miedo, y evitaría que desempolven su viejo compilador y ayudaría a los más jóvenes en caso de necesidad. Otras veces (y con mayor frecuencia), tienen presupuestos que siempre son ajustados, y tienen que tomar decisiones sobre dónde gastar dinero. Para nosotros, implementar esto es una necesidad obvia, pero eso es porque los hemos usado antes. Conocemos los beneficios, ellos no.

2. Los gerentes son personas que no son de TI, y todo lo que hacen aquí es que quieres gastar dinero en algo que no se ha necesitado antes.

La mayoría de los argumentos que he escuchado de las personas se centran en las mejores prácticas, etc., y esos son ciertos, pero lo que la mayoría de los desarrolladores no entienden es que tienes que enmarcarlo en términos de una situación financiera en este escenario. Con esta cantidad de dinero que va a gastar, vamos a ahorrar X cantidad de tiempo, y necesita números para respaldarlo. Esto no siempre es cierto, pero ha sido mi experiencia en el pasado.

Yo diría que muchas personas no usan el control de fuente porque pueden estar codificando por su cuenta y están acostumbrados a hacer una copia de seguridad de la base de código en un servidor central o disco duro USB periódicamente. Hace un año me obligué a comenzar a usar SVN porque sabía que sería beneficioso a largo plazo. Me llevó un tiempo acostumbrarme, pero ahora tengo toneladas de historial de códigos a los que puedo hacer referencia constantemente. Desearía haberlo implementado hace cuatro años cuando comencé.

¿Integración continua? Úselo solo si lo necesita. Para mí, solo hay dos ingenieros de software, por lo que no nos beneficiaríamos de la integración continua porque trabajamos en nuestro propio software por nosotros mismos.

¿Crees que estás avanzado porque tienes SCM y un sistema de CI? Déjame decirte que es hora de aficionados cuando se trata de eso.

Muchas empresas hacen lo mínimo requerido, porque eso es todo lo que realmente necesita . Si funciona y obtiene buenas versiones reproducibles sin un gran esfuerzo, entonces no hay nada que deba solucionarse. Lo último que desea hacer en tales circunstancias es comenzar a "arreglar" las cosas, especialmente cuando se trata de quitar recursos administrativos de su trabajo para configurar y administrar sus nuevos servidores y sistemas de compilación.

Sin embargo, algunas compañías requieren sistemas un poco más estrictos, una vez que no solo hacen la compilación, sino que controlan los requisitos hasta la implementación a través de planes de prueba y resultados de prueba, teniendo en cuenta la revisión del código, los procedimientos de registro de estilo de flujo de trabajo y gestión del paquete de trabajo designado por el líder del equipo. Esa es la gestión de la configuración real, y ¡alégrate de no tener que trabajar en ese tipo de entorno!

He trabajado en algunas compañías, y no puedo pensar en ninguna que no tuviera algún tipo de SCM. Algunos de ellos eran más completos que otros, pero todos tenían un sistema que funcionaba bien para ellos, incluso los que usaban VSS.

Incluso con dos programadores cuando trabajas en aplicaciones complejas y una lista de tareas, puede ser difícil no obstaculizar los cambios de los demás.

Incluso nuestro antiguo software de administración de versiones mostró los cambios uno al lado del otro y permitió que se aplicaran en cualquier dirección. Los cambios se habrían perdido en más de una ocasión sin él.

Veo una serie de beneficios que provienen de CI, pero no puedo imaginar por qué una compañía no haría uso del software de control de versiones.

El último trabajo en el que trabajé sin control de versiones fue en 2006 (soy desarrollador web, FWIW). La compañía solo tenía unos 2 o 3 desarrolladores antes de contratarme, pero yo fui el primero de aproximadamente 10 desarrolladores contratados en solo un par de meses. Una de las primeras cosas que hice cuando fui contratado fue introducir el control de versiones (CVS, ¡porque en ese momento no sabía cuánto apestaba!), Pero muchos de los desarrolladores contratados después de mí no pudieron hacer que funcionara en su desarrollo ambientes, así que no lo usé. Ah, ¿mencioné que ni siquiera tenían instancias locales de la aplicación ejecutándose? Piratearon código en el servidor. Y no hay pruebas automatizadas, por supuesto. Me estremezco cuando pienso en ello.

Antes de eso, hice un trabajo de programación AS / 400 sin control de versiones. No sé si incluso había un VCS decente disponible para ese entorno.

Ahora uso Git para todos mis proyectos individuales, y mis últimos trabajos también lo han usado.

CI es un asunto diferente. Es genial tenerlo, y lo aliento, pero es menos esencial que el control de versiones, al menos para proyectos más pequeños en idiomas interpretados. Sin embargo, la mayoría de mis trabajos recientes han tenido servidores CI; entre otras cosas, significa que nadie puede olvidarse de ejecutar el conjunto de pruebas completo antes de la implementación.

Definitivamente me he encontrado con algunos aquí y allá, pero en su mayoría pequeñas empresas. El problema que veo con más frecuencia son las empresas que realmente tienen SCM, pero consideran que muchos proyectos son demasiado pequeños o sin importancia para seguirlos.