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

17

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?

daramarak
fuente
3
Esos molestos actores de software.
Lightness compite con Monica el
1
¿Son los actores de software diferentes de los desarrolladores de software?
Aditya P
"¡No soy un software pero juego uno en la televisión!" --Actores de software.
FrustratedWithFormsDesigner
1
Está Jayne Seymour, es una actriz de software seria ... o al menos interpretó a Solitare en Live and Let Die :)
Kevin D
3
Donde trabajé hace diez años, teníamos versiones nocturnas en todos los sistemas compatibles. Nunca se acercaron a la compilación. Nunca.
David Thornley

Respuestas:

5

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 .

Steve
fuente
1
+1 Están en la liga mayor al menos. No pensé que eso fuera posible. Una empresa tan grande sin control de versiones. Imagínate.
daramarak
Loco. No lo hubiera creído, pero ese blog y las referencias del artículo son confiables.
Steve
Culpa al perro.
JeffO
2
Un sitio web para adolescentes que comienzan una banda en un garaje está escrito al estilo de un programador que trabaja desde su garaje. Cifras.
quant_dev
13

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.

perdian
fuente
11
¿Es posible que un desarrollador de software promedio no haya escuchado sobre el software de control de versiones? ¿De dónde contratan estas empresas a las personas? ¿El lado oscuro de la luna?
daramarak
77
@daramarak: Muchos (si no la mayoría) de los desarrolladores de software no leen libros, no navegan en blogs de desarrollo y no se comunican con otros desarrolladores (fuera de su empresa). Si se inicia en el desarrollo enseñándose a sí mismo con uno de esos libros de "aprenda visual básico en 21 días", entonces es poco probable que escuche sobre el control de versiones. De hecho, no recuerdo haber aprendido sobre el control de versiones en la universidad, solo hace 10 años.
Joeri Sebrechts
@joeri: afortunadamente no es cierto donde trabajo, pero puedo creerlo en general.
Steve
@perdian: usted dice "bastantes compañías" pero no da detalles específicos ... ¿tiene algún enlace a artículos, blogs, etc. para nombrar y avergonzar? No estoy diciendo que yo no le creo (de hecho yo no le creo), pero los datos siempre es buena ...
Steve
@ Steve Haigh - No, no tengo ninguna evidencia "sólida". He visto unas pocas empresas a mí mismo que no utilizan CI oder control de versiones (cuyos nombres voy a mantener a mi mismo g ) y con un poco de extrapolación Asumo que hay mucho más "allá afuera". Creo que es mucho más fácil encontrar compañías que usan CI, simplemente mirando la lista de referencias en la página de Jenkins, por ejemplo. Pero al revés? No hay mucha gente publicitando "Hey, nosotros no usamos tecnología X" ;-)
perdian
12

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.

Guerrero del camino
fuente
3
No estoy de acuerdo con que sea perfectamente racional "continuar por ese camino". Sí, haber entregado software durante los últimos X años no significa que no funcionará en los próximos años sin ningún cambio. Sin embargo, después de haber introducido CI en productos de software existentes (y bastante maduros), siempre hay algo que ganar con esto.
perdian
1
@perdian: siempre hay algo que ganar de muchas iniciativas. Por lo tanto, debe equilibrar CI con todo lo demás. No puede simplemente afirmar que CI le brinda más beneficios que todo lo demás. También debe medir los costos de oportunidad.
RoadWarrior
1
@ SK-logic: RCS era completamente desconocido en ese momento en la industria bancaria del Reino Unido. Y desarrollamos algunos sistemas muy grandes y robustos sin ningún control de fuente.
RoadWarrior
1
-1: "Casi todas las empresas" es una afirmación demasiado amplia que está mal. He visto en el último año algunas compañías que no usan ninguna herramienta de control de versiones, confiando en copias de versiones en un directorio compartido. Sí, esto me hizo llorar. Dijeron que "svn es demasiado difícil de usar". DIOS MIO. Pero todavía encuentro algunas compañías que son así. No generalice, no todos en la industria saben qué es un sistema de control de fuente, ni aprenden nada en línea, ni saben qué es una integración continua. (Estoy de acuerdo en que es un infierno. Feliz de no estar más allí).
Klaim
1
@ SK-logic - ... lo que dijo RoadWarrior, excepto en la industria marina / energética aquí. No daré nombres, pero conozco al menos dos empresas que son dominantes en su sector (un desarrollo de software especializado) para quienes creo que nunca usaron VCS de ningún tipo (en su sentido). Tenían sus formas de distinguir un buen código del código de trabajo en progreso.
Rook
7

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.

Dan McGrath
fuente
Mis condolencias. Parece que al menos algunas partes de la industria carecen seriamente de las herramientas. Supongo que es la historia de los niños zapateros otra vez. ¿Puedo preguntar qué llamaría una persona loca el control de versiones?
daramarak
66
Tomar manualmente una copia del código antes de editarlo. Por ejemplo, MyProg -> MyProd.old4
Dan McGrath el
Lamentablemente, esta práctica es más común de lo que la gente piensa
Craig T
3

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.

Chris Card
fuente
Para los lugares con código heredado, ¿hicieron compilaciones automatizadas o tenían un plan manual de construcción / implementación?
daramarak
3

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.

Wayne Molina
fuente
3
¡Absolutamente! He escuchado la respuesta (o tal vez deberíamos llamarla excusa poco convincente) "no la hemos usado hasta ahora y dado que funcionó (de alguna manera) no la necesitamos". Es una pena lo resistentes que están las personas en contra de cambiar sus herramientas.
perdian
1
No soporto a la gente así; lamentablemente ese es el tipo de "desarrollador" que he encontrado con demasiada frecuencia en mi carrera, y simplemente no puedo lidiar con su ignorancia y siempre trato de dejar una empresa donde prevalecen esos tipos de desarrolladores. A riesgo de sonar francamente hostil, ese tipo de personas son un cáncer para esta profesión.
Wayne Molina
2

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.

Mike Sherrill 'Retiro del gato'
fuente
1

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.

kemiller2002
fuente
Me imagino que surgen problemas como este cuando hay poca comunicación del desarrollador y hacia arriba en las gestiones. Afortunadamente, no todas las empresas son así. Donde trabajo, se espera (si no está obligado) que le digamos a la gerencia si algo podría hacernos más efectivos.
daramarak
1

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.

Brian
fuente
1
Se supone que la integración continua identifica errores cuando ocurren. Incluso dos desarrolladores necesitan eso.
daramarak
1
@daramarak: No si los dos ingenieros trabajan independientemente en dos productos separados que no están integrados.
Brian
1
CI es una de esas cosas de las que estoy dispuesto a prescindir. Personalmente, me encantaría tenerlo en mi trabajo, pero no va a suceder pronto. Sin embargo, tenemos compilaciones automáticas 1-2 veces al día, y eso realmente es suficiente para nuestras necesidades.
Michael K
1
Con una construcción automatizada estás a medio camino. El hecho de saber que todo lo que registró compila puede ser una alegría a veces ( "Se compila en mi máquina")
daramarak
1

¿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.

gbjbaanb
fuente
jajaja firmado: un profesional.
deadalnix
Estoy de acuerdo, SCM y un rastreador de errores es el equivalente de desarrollo de usar pantalones para trabajar. CI es automatización básica de una función crítica. Como copias de seguridad automáticas pero para lanzamientos. Ah, reuniones de CCB. Todas las semanas, como un reloj.
Tim Williscroft
1

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.

DHorse
fuente
1

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.

Marnen Laibow-Koser
fuente
'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 '. Convenido. CI solo es realmente necesario cuando está haciendo compilaciones frecuentes y / o complejas y comienza a ocupar mucho tiempo, o si desea ejecutar un conjunto de pruebas, o si desea poder organizar múltiples ramas, etc. un proyecto PHP con una docena de desarrolladores, sin un conjunto de pruebas, y si avanza a producción una vez por semana, probablemente desee centrarse en un buen flujo de trabajo de control de calidad antes de comenzar a preocuparse por CI.
siliconrockstar
Y probablemente desee centrarse en un buen conjunto de pruebas antes de comenzar a preocuparse por el control de calidad o cualquier otra cosa.
Marnen Laibow-Koser
Tal vez en teoría, pero si está utilizando software de código abierto, a menos que se envíe con un conjunto de pruebas, esto es prácticamente imposible. No he trabajado una vez en un proyecto PHP que tuviera una cobertura de prueba completa y adecuada, pero cada proyecto en el que he trabajado ha tenido algún nivel de control de calidad.
siliconrockstar
@siliconrockstar Estaba hablando de tener un buen conjunto de pruebas para su propio código; El nivel apropiado de prueba para el código de la biblioteca es otra cuestión.
Marnen Laibow-Koser
@siliconrockstar Por lo que vale, la mayoría de los proyectos de Rails en los que he trabajado han tenido una excelente cobertura de prueba para desarrolladores (las excepciones estaban tratando activamente de mejorarlo); No todos han tenido un control de calidad formal. Es mucho menos necesario tener un control de calidad formal con buenas pruebas, aunque sigue siendo una muy buena idea. Sin embargo, el desarrollo sin pruebas en el lugar es increíblemente arriesgado, por eso digo que mejorar las pruebas debe tener prioridad sobre cualquier otra cosa.
Marnen Laibow-Koser
0

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.

JohnFx
fuente