Razones buenas y simples para tener múltiples entornos

La respuesta: Money

No me importa cuál es la razón real. El dinero DEBE estar en la raíz de todos sus razonamientos, especialmente cuando se trata de la administración.

Si los dos nos sentamos en una habitación durante 2 horas, podríamos encontrar docenas de razones por las que es mejor tener múltiples entornos.

Aquí está el problema: si las razones no se basan en el dinero, ninguno de ellos importa .

Los programadores no son contratados para ser inteligentes. No son contratados para ser creativos. Se los contrata para aumentar los ingresos , ya sea ganando dinero o ahorrando dinero. Si no está haciendo ninguno de los dos, será mejor que reúna su currículum.

Cuando lo miras desde ese punto de vista, la respuesta es simple:

  

Tener un solo entorno aumenta nuestro tiempo de inactividad y da como resultado   pérdida de ingresos. Los entornos múltiples nos permiten proteger nuestras ganancias.   Al dar a nuestros usuarios una interfaz de usuario que es igual de confiable y   Confiable como nuestra empresa.

Repítelo todos los días.

Hay algunos comentarios excelentes a continuación que agregan un valor real a esta respuesta, así que los mencionaré:

• Karl Bielefeldt tuvo un gran punto cuando mencionó que el análisis de costo / beneficio es un factor importante. Un economista podría referirse a él como el costo de oportunidad de perseguir múltiples entornos. Si bien puede ser sorprendente escuchar, hay escenarios en los que ¡múltiples entornos pueden no ser la respuesta! Si el sitio web de su compañía es una adición muy pequeña, el tiempo de inactividad inesperado puede ser la manera más rentable. de hacer negocios. Esto no suena como la posición en la que se encuentra, pero vale la pena mencionarlo.

• BlairHippo tuvo un buen punto en el sentido de que debería sentirse libre para hacer que parezca una catástrofe (y si pierde sus datos, ¡lo es!). La responsabilidad es una gran herramienta para persuadir a los gerentes, pero aún por la misma razón, las demandas son costosas. Evitarlos ahorra dinero.

Como un anexo, encontré que este artículo es Bastante bien. No responde directamente a su pregunta, pero le permite reconocer cómo se ve a los programadores en la administración, lo que a su vez, conduce a esta respuesta. Buena lectura.

Punto único de falla

Al no tener un entorno de desarrollo o de prueba, tiene un Punto único de falla para esas aplicaciones heredadas. La gerencia lo escuchará si describe las aplicaciones heredadas en esos términos.

Debes poder lanzar tu mensaje en bytes de sonido que tengan sentido para ellos. Saque de la discusión a " Programmer Speak " y sustitúyalo por " Manager Speak ". También imagina que tienes un viaje en ascensor de 30 segundos para cruzar tu punto.

Tuve una situación en la que mi jefe era un Infantry Marine. Seguía diciéndole que necesitaba herramientas de software y entrenamiento en computación para mis infantes de marina para ser más productivo. Él no lo entendió. Finalmente, fui a su oficina un día y le dije que las cosas habían mejorado.

Le dije algo al efecto ... "Si estuviera peleando una guerra, estaría usando palos, rocas y ramas de árboles. Lo que necesito son granadas, bazucas y ametralladoras". Él recibió el mensaje.

¿Es realmente crítico?

Puedo entender el deseo de utilizar entornos separados. La pregunta no obvia es:

¿Es realmente crítico migrar un sistema heredado ?

Creo que la mayoría de las personas con mentalidad técnica tienden a centrarse en la cuestión académica de qué manera es mejor, lo que está bien en el mundo académico. En los negocios, aunque lo mejor no siempre gana. No estoy diciendo que esto sea negativo, ni que comience una guerra de fuego. Estoy declarando lo obvio, o lo que debería ser obvio para aquellos de nosotros que hemos estado en el software business durante algunos años.

Por lo general, todas las decisiones comerciales se toman en función del costo / beneficio percibido. Entonces, la pregunta que el negocio probablemente está haciendo es:

¿Vale la pena beneficiarse del costo del sistema adicional y la inversión en desarrollo en una aplicación heredada en lugar de poner esa misma inversión en otro proyecto / producto?

Tengo y sigo haciendo un análisis de costo-beneficio regular para hacer determinaciones no solo en la migración / reescritura de software, sino en las decisiones cotidianas en las que normalmente se involucra un candidato. He dejado de reescribir / migrar el software antiguo porque tenía Vida limitada y por tanto valor.

Separación de entornos

Las razones comerciales para ambientes separados.

• Menos riesgo en lanzamientos y correcciones de errores. Demuéstralo con números. ¿Cuántas veces ha fallado el producto y ha costado los ingresos del cliente debido a un error de lanzamiento / error?
• Menos riesgo en el desarrollo. La eliminación accidental de la base de datos de desarrollo es diferente de la eliminación accidental de la base de datos de producción
• La capacidad de separar claramente los roles y el acceso, es decir. mejor seguridad. limitar el número de dedos en el pastel de producción es bueno
• La capacidad de separar entornos, y las prácticas y procedimientos que acompañan a este estilo de desarrollo permiten la construcción futura en los sistemas de nube.
• La separación del entorno debe forzar eficiencias en los entornos de replicación que pueden ser útiles en la escala programada y dinámica.

Parece que ya tiene todos los argumentos "correctos" en su lugar. En cambio, estás experimentando una "pista falsa", por así decirlo. O, "persiguiendo a la zanahoria"

  

la gerencia realmente no tiene tiempo ni interés en escucharme hasta que   hay un problema critico

Eso es lo que considero el problema real. En mi experiencia, si una empresa tiene prácticas de desarrollo por debajo de la media tan deficientes como usted describe. No es simplemente una cuestión de "no sabíamos nada mejor". Más bien, es una compilación de la deuda técnica causada por un equipo de administración superior que no sabe (¿se preocupa?) Sobre los problemas que presenta.

En tales casos, una buena charla no va a cambiar repentinamente las cosas en su dirección. Tal vez un trauma severo (falla del producto visible para el cliente y directamente relacionada con las prácticas deficientes), pero estoy seguro de que los expertos lo harán antes de que hayas probado el tema.

Mi sugerencia es que lo absorban y tomen las cosas por lo que son o que busquen una nueva posición.

¿Cuántos grupos de personas planean trabajar en la aplicación a la vez? Usualmente, he visto un ambiente para cada grupo de personas. Estos son los desarrolladores (obtienen un entorno DEV y un entorno de integración DEV; algunos dirían que no es 100% necesario, yo diría que varía según el proyecto), dos entornos de prueba (un grupo de evaluadores que realizan pruebas muy detalladas y otro para evaluadores de control de calidad de alto nivel (generalmente son usuarios reales de negocios, no evaluadores capacitados). También suele haber un entorno de pruebas de rendimiento aislado (para que pueda probar grandes volúmenes de datos, simular grandes volúmenes de usuarios, etc.).

¿Por qué todos estos entornos? Así que diferentes grupos pueden probar diferentes características sin pisar los dedos de los demás. Si los desarrolladores y evaluadores trabajan en el mismo entorno, es una pesadilla: un probador puede abrir un defecto en una función que un desarrollador está cambiando activamente cada minuto. Si hay dos niveles de pruebas, pueden enfocarse en actividades diferentes y no preocuparse por desordenar los datos de los demás. Tener un entorno de rendimiento aislado le permite ejecutar pruebas que pueden colgar la máquina, pero si está aislada, ningún otro comprobador se verá afectado.

Cuando demasiadas personas intentan hacer demasiadas cosas diferentes en el mismo entorno, terminas con una gran cantidad de tiempo perdido mientras un grupo espera a que finalice la prueba de otro grupo para que puedan realizar la suya. Y eso desperdicia el tiempo, y el tiempo perdido puede llevar al desperdicio de dinero, lo que Stargazer712 señaló podría ser el argumento más fuerte.

Otra razón (no tan común) son los datos: si su aplicación tiene datos personales confidenciales o datos de tarjetas de crédito, por lo general no puede poner eso en entornos de prueba, y generalmente hay requisitos de enmascaramiento para todo excepto los entornos de control de calidad y producción.

Parece que has invertido mucho esfuerzo para lograr un cambio cultural en tu lugar de trabajo. Este es un gran logro, ya que el cambio es difícil en el mejor de los casos, pero el cambio cultural no consiste simplemente en cambiar la mentalidad de las personas, sino en cambiar hábitos, romper prejuicios y, en última instancia, en abrir mentes potencialmente cerradas a mayores posibilidades. Entonces, la pregunta que debe hacerse en este punto es "¿Qué me perdí?". La respuesta fácil es que es posible que no esté completamente involucrado con la administración.

Obtener la aceptación de la administración es fácil, pero aún más difícil es obtener aceptación. Independientemente de los argumentos sobre el dinero, etc., la realidad es que debe poder influir en la opinión de la gerencia sobre la prioridad. Su gerente tendrá un presupuesto y querrá mostrar que el presupuesto se ha aplicado de manera sensata y de acuerdo con los valores y prioridades de la empresa. Algunas de esas prioridades serán fiscales, pero otras tratarán de satisfacer otras necesidades. En algunos casos, esto puede significar engrasar las palmas de otros gerentes para obtener la promoción que su jefe siempre ha querido. Sin embargo, en la mayoría de los casos, probablemente se trate de encontrar maneras de obtener más negocios o de mejorar las relaciones con socios y clientes. Si no puede presentar su caso en estos términos, solo podrá llegar hasta aquí antes de encontrarse en un punto muerto.

Mi sugerencia es tratar de establecer un caso sobre la productividad y cómo esto afecta el presupuesto, como lo han sugerido otros, pero también hacer referencia a las prioridades de su empresa y cómo su productividad podría impactar directamente en las relaciones de la empresa con otros empresas.

Aquí hay uno: probabilidad.

Tener un entorno de prueba le da la libertad de realizar pruebas en una base de datos que no sería aconsejable realizar en un entorno de producción.

¿Desea cambiar la forma en que su organización desarrolla su software? Olvídate de preocuparte por las "razones" para "hacer las cosas de manera diferente". Los seres humanos no cambian de comportamiento debido a argumentos racionales. Cambian debido a influencias psicológicas en sus hábitos.

Entonces, ¿a dónde voy con esto?

Aunque ocasionalmente puede cambiar exitosamente el comportamiento de una organización a través de la argumentación, hay otras tácticas que funcionan mejor. Estos incluyen:

• Soporte de base: encuentre a UN desarrollador más "legado" que esté dispuesto a darle una oportunidad. Asociarse con él y cambiar cómo funcionan las cosas. No anuncies el cambio. Solo haz el cambio. Si alguien te pregunta alguna vez sobre eso, solo di "Oh sí, así es como lo hacemos ahora".

• Asume la responsabilidad. Ofrézcase como voluntario para manejar los despliegues de las personas heredadas. Actúa como te gusta. Pueden estar felices de renunciar a esa responsabilidad. Luego ejecútalo como quieras.

• Culpa a las personas correctas por sus errores. La próxima vez que un error de aplicación heredada se introduzca en producción debido a su mecanismo de implementación de la edad de piedra, señálelo. Hazlo sutilmente ... No en un correo electrónico. La próxima vez que esté en una reunión con un administrador, solo mencione casualmente el ejemplo de una razón por la cual la implementación fue problemática. "Sí, ¿recuerdas cómo estábamos luchando el viernes pasado por el error de Foo que Bob ingresó en producción? Sí, ¡eso fue un gran esfuerzo inútil!"

• Facilita hacerlo de la mejor manera. Mira el iPhone, por ejemplo. Hay un botón en él. (Bueno, dos). Es MUY fácil de encender. Hacer que la implementación a múltiples entornos sea una estupidez fácil. ¡Hazlo tan fácil que todos los gerentes pueden hacerlo!

Es más un problema cuando comienza a tratar con sistemas interconectados o heredados, los sistemas de los que depende la empresa para que funcionen y sean precisos. Es importante porque debe haber una separación entre las etapas, es la razón por la que no DEV en PROD porque tiene el potencial para causar daños por valor de millones de dólares en tiempo perdido .

Siempre hacemos DEV - > QA - > PROD (ocasionalmente esos pasos se dividen en partes más pequeñas) con un hardware idéntico detrás de ellos. Los datos de producción actuales siempre se transfieren de PROD a QA a DEV.

DEV: está destinado a ser el entorno limitado de desarrollo, donde las cosas se prueban, se iteran y se baten en cualquier información en este entorno nunca deben ser confiables y los desarrolladores simplemente las destrozan para encontrar formas de resolver un problema.

Control de calidad: una vez que sus desarrolladores estén satisfechos con las pruebas unitarias, es hora de que el grupo de prueba se ponga a ello. Ejecutan casos de prueba, pruebas de rendimiento y encuentran errores. Esos errores / mejoras se envían a DEV y el ciclo continúa hasta que todos estén contentos.

PROD: Una vez que llegue a esta etapa, debe asegurarse de que el código funciona junto con los datos actuales y que los usuarios de su grupo de control de calidad / empresa estén satisfechos con la implementación. Si hiciste todo correctamente, simplemente deberías poder actualizar el código y terminar con él.

De la misma manera que nunca lanzaría un producto no probado a los clientes, nunca debería liberar código no probado a un entorno de producción.

Si la empresa no está dispuesta a invertir el tiempo para hacerlo correctamente, pagará el costo del mantenimiento de emergencia y los errores 10 veces.

Como un pequeño ejemplo: tuvimos una compañía que decidió realizar un cambio en un informe en producción por su cuenta. Nadie supo que cambió hasta que llegamos para abordar una variedad de problemas uno o dos años más tarde.

Cuando señalamos la irregularidad en el informe, el rostro del Oficial Principal de Finanzas se puso blanco y resultó que estaban perdiendo ~ 250,000 dólares por trimestre debido a que alguien está haciendo un cambio rápido.

Sucede con más frecuencia de lo que crees, si no puedes permitirte hacerlo correctamente, entonces no lo hagas.

La administración tiene una gran parte detrás del éxito de las compañías de software y los productos de software que requerían generar estos entornos. Tomemos un ejemplo de su proyecto. Si su software se desarrolla a gran escala, entonces si no administra los requisitos de su proyecto, el control de procesos, las versiones de prueba, etc., es probable que se produzcan fallos. para que exista la gestión de proyectos.

  

Estoy algo de acuerdo con @ Stargazer712 en que su declaración apunta a   el dinero importa, pero revisa la siguiente declaración que tengo   Obtenido del libro de Marc Hamilton sobre Desarrollo de Software: Construcción.   Sistemas confiables (Prentice Hall PTR, 1999, ISBN 0-13-081246-3). Después   mirando todos estos factores; Mi opinión sobre tu pregunta es que   Un solo entorno no es darle ahorros, hará un largo plazo   Proceso para completar el proyecto / software. Entornos distribuidos   Ahorraré tiempo e ingresos como aprendí y vi en mi experiencia   que lo que sucedió con las empresas de software de inicio de las cuales i   he empezado mi operador.

Hay muchos artículos que demuestran que lo que importa para el éxito, consulte este Organización para un desarrollo de software exitoso

  

Cada individuo en una organización tiene ciertas habilidades, y estas   Las habilidades se miden típicamente contra el rendimiento formal o informal   métricas que conducen a recompensas (compensación) como incentivos para el futuro   actuación. Las personas en una organización establecen su cultura, aquellas   patrones de comportamiento y valores que generalmente se reconocen como ser   adoptado.

Un gran conjunto de desarrolladores de software luchará y, en última instancia, no logrará cumplir sus objetivos si tiene que dedicar todo su tiempo a luchar contra una estructura organizativa inadecuada.

Muchos de los arranques de software comienzan a funcionar con solo dos desarrolladores trabajando fuera de un garaje. No se requiere mucha estructura organizativa en este momento en la historia de una compañía, pero la estructura organizativa todavía existe. Por ejemplo, en 1977, cuando Bill Gates y Paul Allen formaron su sociedad y la nombraron oficialmente Microsoft, la compañía tenía una estructura organizativa mínima. Menos de una docena de empleados trabajaron en la primera oficina de Microsoft en Albuquerque, Nuevo México, y todos sabían quién estaba a cargo. No se necesitaron cuadros organizativos complicados para descubrir la estructura de informes de todos. Al mismo tiempo, todos los empleados sabían su papel en la empresa y lo que intentaban lograr. Esto se debió a que cualquier estructura organizativa que fuera necesaria podría comunicarse informalmente entre cada uno de los empleados.

Olvídese del tiempo, el dinero, la capacidad de prueba, la calidad ... acerca de la reputación .

  

razones buenas, simples e irrefutables para la separación de entornos   eso haría que los gerentes carecieran de experiencia en desarrollo para apoyar esto   idea.

Uber envió recientemente un código a github que contenía contraseñas para su entorno en vivo , lo que permite a los piratas informáticos descargar todos los detalles de sus clientes. Uber dice que fue una violación, todos los demás dicen "no pongas las llaves de tus cerraduras a la vista del público. Si sus desarrolladores trabajaron completamente en un entorno de desarrollo, podrían haber lanzado las claves de su entorno de desarrollo en github, pero eso es completamente Inofensivo. Que los de producción fueron lanzados muestra cuán pobre es esta idea de realizar dev en el entorno de producción.

Solo recuérdele a su gerente que se cometen errores, por lo que la manera de evitar que lo lleven ante el CEO que está a punto de ser interrogado frente a los periodistas y del público tecnológico se ríe de ellos es tomar medidas simples y obvias para prevenirlos. Los errores son catastróficos.

Parece que tienes muchos entornos diferentes y le cuesta mucho tiempo a las personas configurar un "entorno".

Debería tener la menor cantidad de "entornos" que pueda evitar, pero podrá clonar muchas copias por tantas razones como usted y el deseo de la compañía (usar "entorno para significar configuración del sistema)!

De manera óptima, las únicas diferencias deben ser:

1. Tamaño (mínimo, recomendado, mayor compatible / probado);
2. La puesta en escena y la producción no tienen herramientas de desarrollo
3. La producción está protegida contra la sobreescritura accidental de datos
4. Es muy fácil cargar datos de demostración, prueba o clientes [anoymizados] en servidores de desarrollo o de prueba

ENTONCES, la pregunta de cuánto y qué tipo de pruebas deben realizarse es una evaluación de negocio de riesgo / costo y se decide a nivel de empresa, ya que la empresa en su conjunto sufrirá si se producen fallas significativas. gama de clientes.

Edición posterior: esto me impulsó a racionalizar mis convenciones de nomenclatura con mis productos web (gracias por la pregunta). He decidido cuatro "entornos", con pruebas divididas entre qa (solo nivel mínimo para la funcionalidad de prueba) y puesta en escena (la misma arquitectura que la producción, para pruebas de carga / rendimiento / volumen).

La única diferencia real en el aprovisionamiento es que la producción / el almacenamiento intermedio instalan una base de datos en un sistema separado, el cual controlo los grupos en los que se encuentran los diferentes servidores. qa / dev tiene los roles de servidor web y db. El balanceo de carga se realiza mediante cloudflare.

También tengo una variable ENV_NO, que se transmite a los sistemas, por lo que puedo elegir tener tantos ejemplos "qa" o "staging" como elijo.

Entonces, para configurar un segundo entorno qa que incluya mi última copia de seguridad de live, los comandos serían:

git checkout desired-branch/commit for provisioning
ENV_NO=2 bin/provision create qa
# come back after a short lunch

git checkout desired-branch/commit
ENV_NO=2 bin/cap qa deploy
# a minute or two

ENV_NO=2 bin/cap qa db:upload db:restore
# longer than I want once there is a decade of data ("longer" coffee break to traverse a 5.3km ADSL link)

Por último, tengo un servidor adicional (opcional) llamado "readonly" como la última red de seguridad antes de aterrizar. Se aprovisiona como un sistema qa pero con las últimas copias de seguridad y actualizaciones deshabilitadas (el software también se actualiza a la noche anterior).

Utiliza un enfoque de "Todos los huevos en una canasta diferente": se aprovisiona con una ubicación / registrador de DNS, host de DNS, proveedores de servicios de host de sistema diferentes. Esta es la última / última red de seguridad, por lo que si todo se incendió, al menos puede acceder a los datos hasta la noche anterior. Los scripts de aprovisionamiento aíslan la diferencia entre los diferentes proveedores, por lo que el 99% es el mismo, solo el indicador de solo lectura. El equilibrador de carga de Cloudflare redirigirá el tráfico al sitio de solo lectura si todos los servidores activos han fallado.

Cuando se trata de hacer un cambio, tendrá la suerte de tener a alguien que escuchará su opinión profesional e implementará los cambios sugeridos.

Según mi experiencia, cada vez que tenía que hacer un cambio importante, tenía que justificarlo en términos de los ahorros que la empresa haría. Por ejemplo, introducir ReSharper en la línea de desarrollo fue bastante fácil, ya que pude decir algo al respecto:

ReSharper cuesta alrededor de £ 50 por desarrollador. El costo promedio del desarrollador por año es de £ 40k. ReSharper debería aumentar la productividad de los desarrolladores en al menos un 20% dado su uso en todo su potencial. Digamos que el desarrollador pasa el 75% de su tiempo escribiendo código en IDE. 75% de 40k es £ 30k. £ 30k es ahora el costo de la productividad del desarrollador. Un porcentaje adicional de productividad (1%) por año cuesta £ 300. Para obtener un 20% adicional de productividad, la empresa tendría que gastar £ 6k.

Si tuviera que poner esto en perspectiva para el negocio, puede decir que puede contratar a otra persona y obtener un 20% de productividad adicional por £ 6k, o puede obtener el mismo resultado gastando £ 50 en una licencia ReSharper. Una vez que las cifras estén al frente del negocio, la decisión será fácil de tomar.

Ahora, en lo que respecta a sus preguntas sobre tener múltiples entornos, todo lo que tiene que hacer es encontrar una manera de calcular cuánto le cuesta a la empresa cada año tener ahora estos entornos.

Puede pedir a sus otros desarrolladores que realicen un seguimiento de las horas dedicadas cada semana a la configuración de aplicaciones para desarrollo, implementación, etc. Por ejemplo, diez horas de tiempo para desarrolladores senior pueden costar £ 500. Son 10 horas que pueden dedicarse al desarrollo, o algo mucho más importante. Recopila las cifras durante un período de tiempo y proporciona a las empresas un costo anual.

Personalmente odio este tipo de política, pero es común y tenemos que vivir con ello.