¿Es razonable pedirle a un ingeniero de software que haga CI manualmente para una empresa?

Trabajo como ingeniero de software en una empresa que tiene una infraestructura de construcción obsoleta. Cosas como la integración continua son prácticamente imposibles. Por cierto, no usamos Git.

Hay una empresa con una gran base de código y cualquiera puede entregar al repositorio, independientemente de cuán rota esté la compilación. Como puede imaginar, cuando llega el momento de crear una compilación etiquetada, normalmente lleva varios días. Tratando de arreglar la compilación mientras otras personas la están rompiendo al mismo tiempo.

En este momento, hay una persona valiente que aborda este problema rastreando los registros de compilación y luego llama a las personas responsables y les pide que corrijan sus errores. Básicamente hace lo que hace la integración continua. Esto puede tomar todo el día de esa persona.

Me pidieron que fuera esta persona. Para mí, esto parece algo que no es y no debería ser parte de mi trabajo. Omita el hecho de que es un trabajo muy molesto. Básicamente es administrar a otros programadores y decirles que corrijan sus errores. Parece que no tiene nada que ver con el proceso de desarrollo de software.

Finalmente, mi pregunta : ¿Crees que esto es algo razonable para preguntarle a un ingeniero de software? ¿Alguna vez te has encontrado con algo similar?

Pregunta editada : como muchas personas mencionaron correctamente, mi pregunta original se basa en una opinión. Por lo tanto, modificaré mi pregunta para que sea respondible. Si estrictamente no quería aceptar este papel, ¿hay alguna forma legal de negarme sin renunciar?

¿Será esta tu única responsabilidad o seguirás haciendo otro trabajo?
@sf02 Continuaría con otro trabajo. Sin embargo, esta actividad puede ocupar fácilmente todo el día. De cualquier manera, no creo que esto sea relevante.
Tampoco usamos Git. Usamos SVN, que está bien para nosotros. E introduje compilaciones nocturnas aquí gradualmente, un paso a la vez. Cuando comencé, no teníamos un proceso coherente de compilación e implementación. Ahora tenemos. Antes de configurar un entorno de servidor de CI, empiece por estandarizar el proceso de creación (local).
Votar para cerrar ya que la insistencia del autor de la pregunta de recibir una opinión sobre esta descripción combinada con su rechazo a las sugerencias que describen cómo un ingeniero de software enfrentado a tal necesidad podría mejorar la situación hace que esto no sea algo que pueda abordarse en la práctica, sino más bien una pregunta puramente prohibida. de opinión Resolver el problema (y hacerlo de la manera manual más difícil a medida que evoluciona) es productivo, discutir sobre quién debería quedarse con su versión sin resolver no lo es.
@ChrisStratton Creo que también se puede salvar fácilmente si OP pregunta qué creo que realmente quiere preguntar: si tiene que hacer el trabajo, si hay alguna forma de salir de él y volver a lo que él considera tareas de desarrollo de software.
VTC: tal como está redactada actualmente, esta pregunta está fuera de tema según las pautas del sitio. Si tiene un problema real que le gustaría que le ayudemos a resolverlo, considere revisar su pregunta. ¡Gracias y bienvenida!
Divertido: hay montones de resultados para el repositorio RTC y la integración continua. También hay algunos resultados que se refieren a Jenkins, que puede no ser la herramienta más brillante, nueva o mejor del bloque, pero todavía se usa en muchos lugares y hace el trabajo.
@HorusKol En realidad, no quería explicar por qué es tan difícil ya que no era relevante para la pregunta. El proceso ha aumentado la dificultad debido al resto de la infraestructura.
Como un desafío de marco a su pregunta, sugeriría que si bien su actitud parece ser que este es un trabajo que está por debajo de usted, quizás pueda verlo como una oportunidad. Ser el que "dirige a otros programadores y les dice que corrijan sus errores" puede ser una posición muy poderosa e (irónicamente) suena más como si te estuviera dando un alto grado de control y propiedad sobre el producto final, en lugar de simplemente estar ocupado. . Sin mencionar el valor que puede agregar al ayudar a otros a arreglar las cosas, y los problemas que aprenderá a evitar en su propio código al ver que otras personas los crean.
Si trabaja en Suecia o para una empresa sueca, existen leyes suecas que podría usar para obligar a la empresa a comenzar a hacer DevOps.
¿Ha sugerido automatizar el proceso? Por ejemplo, usamos Jenkins y envía por correo electrónico los detalles de una compilación rota a un supervisor y a todos los que han confirmado el código desde la última compilación. Personalmente, me encantaría implementar un CI automatizado , pero no hacerlo manualmente. ¿Ha sugerido eso, y qué dijeron?
Sí, es razonable, siempre y cuando se le permita automatizar el proceso usted mismo y su empleador lo autorice a hacerlo. Además, dijiste que no usaste Git, pero espero que estés usando algún tipo de sistema de control de versiones. No tiene que ser Git.
Simpatizo contigo. Realmente no importa si pensamos que es razonable, la pregunta es ¿ qué quieres hacer al respecto? ¿Cuál es tu objetivo? Entonces, podemos ayudarte.
Con qué frecuencia te integras. Un día entero no suena tan irrazonable, si es una vez por semana. Menos aún si tiene el resto de la semana para mejorar las herramientas a su alrededor.

Respuestas (7)

¿Razonable en general? Es necesario. ¿Algo que quieras emprender? Cuestionable.

Esta es una combinación de control de calidad manual, DevOps, trabajo administrativo y tratar de cambiar una cultura en la que los desarrolladores se comprometen con un abandono imprudente. A nadie le importa la calidad hasta el punto de que ni siquiera pueden generar una compilación, por lo que lo han designado a usted como conserje digital para limpiarlo.

Una cosa sería si esta es una tarea de prueba para ver si puedes administrar el equipo. Si está preparado para un ascenso en la empresa, vaya y hágalo. Pero lo están utilizando como sustituto de la administración, las herramientas y las pruebas básicas. A muchas personas les importa un carajo, así que aquí hay un trapeador.

Parece que no tiene nada que ver con el proceso de desarrollo de software.

Lo hace, solo porque la empresa está utilizando personas para hacer lo que las máquinas han hecho durante mucho tiempo.

Esto es lo que necesita para decidir:

Si se queda a largo plazo, haga la tarea e intente hacer IC, incluso si realmente no funciona. Es difícil de evitar si no planea irse dentro de unos meses.

Si puede irse fácilmente sin consecuencias, simplemente sea incompetente y se le asignará a otra persona. La experiencia en esto significará que te pedirán que lo hagas más y pasarás incluso menos tiempo en el desarrollo. Dedique tiempo a limpiar el buen viejo currículum.

La verdad triste. Cuanto mejor seas para limpiar la basura de otras personas, más te obligarán a hacerlo, porque otras personas ni siquiera pueden limpiar su propia basura.
Esto es como una versión triste, obsoleta y terriblemente ineficiente de la revisión de código. Empresas como esta me asustan, especialmente si tienen datos confidenciales.
@Nelson, a menos que quiera ser un consultor de rescate de proyectos bien pagado, parece una existencia deprimente.
@MatthewGaiser si una empresa es demasiado barata para el personal de control de calidad superior, de todos modos no pagarán por el consultor. Simplemente irán a la quiebra.

¿Crees que esto es algo razonable para pedirle a un ingeniero de software?

Sí. Se le ha pedido que maneje y mantenga la calidad del software, está perfectamente en línea con lo que se espera de un desarrollador, aunque sea desagradecido.

¿Alguna vez te has encontrado con algo similar?

Muchas veces. Y lo que hice fue tomar posesión de la calidad e implementar verificaciones automáticas que le gritarán al propietario del código roto. Esta es su oportunidad de brillar y, en lugar de quejarse de la falta de IC, implementarlo.

Cosas como la integración continua son prácticamente imposibles.

No compro esto por un segundo. Si una persona puede navegar por los registros y enviar correos electrónicos a las personas, también puede hacerlo un script. Comience poco a poco, con algo extremadamente básico como borrar cada compromiso, o simplemente verificar si se construye, y construir a partir de ahí. Es un proceso, y aparentemente ahora eres TI para iniciarlo.

Usamos un sistema de versiones muy exótico que hace que sea muy difícil hacer lo que dices. Hay muy poca documentación y apoyo. De cualquier manera, nadie me permitirá hacer esto, porque significaría que tendría que hacer DevOps a tiempo completo.
@FilipMinx ya pasamos de imposible a realmente difícil, eso es un progreso infinito en el lapso de 28 minutos. No estoy seguro de qué respuesta está buscando aquí, después de leer algunos de sus comentarios si se trata de cómo hacer la integración real, está fuera de tema aquí. Si se trata de "¿cómo puedo salir de esta tarea?", modifique su pregunta y pregunte eso.
Nunca pregunté cómo hacer ninguna integración o cómo implementar CI. Solo pedí una opinión sobre si esto es algo razonable para preguntarle a un ingeniero de software.
La opinión de @FilipMinx, por muy útil que sea, está fuera de tema en este sitio. Por lo tanto, debe tener muy claro qué pregunta está haciendo: Tymoteusz ofrece dos opciones, pero tal vez su pregunta podría ser diferente; pero no para opiniones.
@FilipMinx ¿Qué consideras "muy exótico"? ¿Algo de cosecha propia? ¿Quieres decir que no es git? Si es comercial, creo que hay muchas posibilidades de que alguien aquí tenga experiencia con él, ya sea antiguo (rcs, cms, svn), comercial (AccuRev, Perforce) o ambos (ClearQuest). Si tiene una interfaz de línea de comandos, se puede programar.
@FilipMinx No le pidas permiso a nadie. Ni siquiera lo pienses. Mucho más fácil pedir perdón y mucho más fácil hacerlo cuando tienes un sistema que funciona. No importa cuán exótico sea su SVC, aún puede importar el código fuente a un repositorio git local, incluso si tiene que ponerlo en un trabajo cron. Entonces su CI puede pagar como lo haría normalmente.

Es perfectamente razonable pedirle a usted o a cualquier otro desarrollador que sea esa persona. No importa, si esta tarea es molesta o frustrante, siempre hay tareas en el trabajo que entran en esa categoría.

También es su oportunidad de comenzar a implementar un entorno de CI. Mis sugerencias:

  • comience con la configuración de un servidor de compilación; si no hay una máquina de compilación real, puede comenzar en su propia máquina. Mi recomendación es www.jenkins.io ya que hay complementos para todo y encuentras un tutorial o instrucciones para casi todas las tareas.

  • agregue gradualmente más funciones al servidor de compilación, por ejemplo, pruebas unitarias o de integración, cobertura de código, análisis de código, empaquetado/implementación, etc.

  • una migración a Git no siempre es necesaria, podría ayudar, pero ese es probablemente el mayor cambio que muchos equipos pueden querer evitar

En realidad tenemos todo eso. Excepto que usamos un sistema de versiones muy exótico. Ninguno del que hayas oído hablar. Todo esto no impide que las personas realicen cambios importantes. De hecho, la empresa está trabajando en la migración a Git, pero esto lleva mucho tiempo. Tengo un rol muy específico y nadie me va a poner a cargo de DevOps.
@FilipMinix: apuesto a que he oído hablar de eso.
@Filip Minx: ¿Dimensiones Serena/PVCS o ClearCase?

En primer lugar, en teoría, es razonable preguntar esto. Lo que quiere decir que garantizar la calidad del código debe ser responsabilidad de alguien . Idealmente, por supuesto, debe ser responsabilidad de todos , pero parece que su empresa está jodida, por lo que se arreglarán con "alguien". En este caso, eres "alguien" y por eso te eligieron.

Mi pregunta es, ¿por qué CI es una imposibilidad para su empresa? Como mínimo, ¿qué sucede si escribe (o le dice a otros que escriban) pruebas unitarias para su código para asegurarse de que su código sea correcto y ejecutar automáticamente esas pruebas antes de una implementación? ¿Tiene una sola persona (o un grupo de personas de tamaño O(1) en relación con su organización de tamaño O(n)) responsable de la implementación? A esas personas se les puede indicar que ejecuten las pruebas unitarias antes de la implementación y rechacen la compilación si las pruebas fallan. Eso es como hacer CI manualmente, y es mejor que nada (definitivamente está lejos de ser ideal, pero es mejor que lo que tiene actualmente).

¿Cuánto poder tiene en esta empresa y qué tan abierta está la gerencia a escuchar las inquietudes de los desarrolladores? Si fuera a la gerencia y dijera "esto es insostenible, hay demasiados problemas y nadie los está solucionando, nuestro software se rompe constantemente", ¿qué dirían? ¿Podría tener margen para priorizar, al menos, solucionar los problemas existentes y agregar pruebas unitarias al menos para esas soluciones para asegurarse de que no se presenten en regresión? ¿Y podría hacer que la gerencia se comprometiera a penalizar a los desarrolladores que se nieguen a adherirse a esas prácticas? Debe tener una reunión con la gerencia (o al menos con la persona que le pide que asuma este rol) y hacerles estas preguntas.

En cuanto a la gestión del código, dijiste que no usas Git pero tienes un repositorio. Hay muchas empresas que usan alternativas a Git, como Subversion, y funcionan bien. Si no tiene una buena razón para usar Git específicamente, no es algo que le preocupe en particular.

La razón por la que tenemos que conformarnos con "alguien" es que a "todo el mundo" no le importa. Los ingenieros a menudo no verifican si sus confirmaciones rompieron algo. Ni siquiera los culpo. Trabajamos en muchas transmisiones simultáneamente y, a veces, simplemente se olvida. Es por eso que necesita una herramienta automatizada para alertarlo. Usamos RTC como repositorio, que tiene cero integración con herramientas modernas. Tengo energía cero. La empresa comprende la necesidad de esto y está trabajando activamente para mejorar las cosas, pero debido al enorme sistema, es muy difícil.
@FilipMinx En un sistema muy grande, es difícil identificar categóricamente uno por uno si su compromiso rompió algo. Es por eso que realiza pruebas de unidad e integración, porque sus pruebas deben cubrir sus casos de uso comunes y, si no están rotos, entonces su compromiso probablemente esté bien. Si realiza pruebas unitarias y de integración de su código, debe ser responsabilidad, como mínimo, del desarrollador original, el revisor del código y el especialista en implementación asegurarse de que esas pruebas no produzcan errores. Si no realiza la prueba ahora, comience a hacerlo lo antes posible.

¿Eres el nuevo empleado? Si es así, podría ser un rito de iniciación o una forma de novatada, por así decirlo. Obtienes el trabajo más bajo y te abres camino si te quedas.

Mi pensamiento: esto no es algo grandioso. Solo diría que es probable que sea una posición de alto rendimiento si te obligan a realizar esta tarea. Lo más probable es que estés en esta posición porque el otro chico quiere hacer las "cosas geniales".

Lo que creo que deberías hacer: renunciar ahora, mientras estás adelante. No estoy seguro de por qué la gente de este foro le dice a la gente que se quede e intente cambiar las cosas. No estamos trabajando para la NASA resolviendo problemas mundiales o dispositivos médicos. Hay una gran cantidad de otros trabajos que ofrecen roles desafiantes que no implican convencer a las personas para que hagan las cosas bien. Pregúntele a cualquier persona de AA cuál es el primer paso para resolver una condición alcohólica y le dirán que debe admitir que tiene un problema y necesita resolverlo. Si su lugar de trabajo no está dispuesto a admitir que tiene un problema y es terco en verlo, entonces ciertamente no será "ese tipo" que lo hizo. No necesita trabajar en el último marco de trabajo súper genial ni necesita un gran proceso de CI para lanzar productos. La gente lo ha estado haciendo desde los años 80 con gran éxito y no implica días preparar un lanzamiento para averiguar quién hizo qué. Hubo compilaciones nocturnas durante décadas antes de GIT o cualquier otra cosa que veamos hoy. Una simple rama o etiquetado funcionará bien con la mayoría de los lanzamientos de SVN. Si su lugar de trabajo está tan desorganizado que no puede hacer eso, diría que no es una buena idea quedarse.

Se puede hacer un caso decente para los actos heroicos si van a ascender, tienen una participación en la empresa o si se trata de una situación extraordinaria única, pero este es un trabajo de limpieza programado regular que claramente no es deseado ya que se le tuvo que pedir a alguien que lo hiciera. hazlo.
@MatthewGaiser No solo parece que los compañeros de trabajo ingresan regularmente código roto en el SVN. Entonces, si actualiza svn, es posible que pase un día entero averiguando qué se rompió y por qué y luego acudir a esa persona. Hace que el trabajo sea más duro y duro que lo que figura en el OP. Imagino que mientras tus compañeros de trabajo hacen otras tareas, pueden ignorarte durante días o incluso semanas antes de volver a arreglar lo que sea. Luego, cuando lo suelte, volverá a sufrir un código roto y quién sabe qué.
La confirmación de código roto hace que esto sea un problema de nivel de gestión. Evidentemente no pueden ser molestados.

Es poco probable que ganes mucha simpatía de este grupo. Muchos de nosotros comenzamos antes de que CI fuera una cosa. Nuestro "CI" solía ser dos tipos que ejecutaban pruebas manualmente durante 3 semanas. Muchos de nosotros hemos automatizado lentamente este tipo de problemas a lo largo de los años. Se puede hacer, y se puede hacer a nivel de base, pero es un proceso lento.

Nuestro pequeño equipo configuró nuestro propio servidor CI antes de que tuviéramos uno "oficial". Nuestro éxito con el experimento junto con otros equipos es la forma en que pudimos convencer a la gerencia para que financiara uno oficial.

Tenía mi propio repositorio git personal además de nuestro VCS "exótico" cuando teníamos problemas con compilaciones rotas constantes similares a las que usted describe. Eso me permitió mantener los cambios rotos fuera de mi rama estable cuando necesitaba hacer el trabajo. Mi éxito y el éxito de otros en ese tipo de experimentos es una de las razones por las que usamos git oficialmente hoy.

Las cosas están mucho mejor para nosotros ahora, pero son los cambios más complicados, como las actualizaciones de dependencia y las pruebas inestables, los que rompen la compilación ahora, y las personas aún no siempre se dan cuenta de cuándo es su culpa. Todavía tomo un día regular y voluntariamente para ser el "policía de compilación" para ayudar a mi equipo a tener una compilación limpia para terminar nuestras características, incluso mientras busco formas de mejorar la automatización para que la vigilancia no sea tan necesaria. La mayoría de las personas con antigüedad lo hacen. No creemos que esté por debajo de nosotros, y tú tampoco deberías hacerlo.

  • si, me he encontrado con algo parecido
  • Supongo que usas otro control de versión que git
  • Mi consejo: Cámbialo poco a poco. Lidia con las peores cosas primero. Por lo general, se puede convencer a las personas para que cambien
El problema de cambiar de " a very exotic versioning system", como lo describe el OP en un comentario, es que es probable que pierdan su historial de confirmación y no puedan recrear compilaciones anteriores. (Dicho esto, todavía siento firmemente que deberían hacerlo: pasar a SVN (git, si es necesario) y presentar a Jenkins. De lo contrario, busque a alguien menos calificado y enséñele cómo (recuerdo cuando "construir maestro" fue un trabajo); pero no desperdicie el tiempo de un desarrollador en él de manera regular.
¿Es razonable pedirle a un ingeniero de software que haga CI manualmente para una empresa?
RespuestasAquíPolítica de privacidad1y, 0v