Mejores prácticas de implementación / mantenimiento de ASP.NET

He estado en la industria del desarrollo web durante unos 5 años, siempre trabajando en un entorno de código abierto. Mayormente apache, mysql y php con un poco de ruby, usando git para el control de versiones. Pero recientemente asumió un trabajo donde el desarrollo es completamente C # ASP.NET MVC.

Si bien pude aprender el idioma, etc. con bastante facilidad, los otros miembros de mi equipo (con mucha más experiencia en MS Development que yo) tienen una forma diferente de pensar cuando se trata de publicar e implementar el sitio final, y particularmente cambios futuros.

La mentalidad con los otros desarrolladores es que una vez que un sitio ha sido publicado, es definitivo. No se pueden realizar más cambios en el sitio, cuando pregunté las razones detrás de esto, las respuestas han sido que es demasiado peligroso, lento o difícil.

Según mi experiencia anterior, actualizar un sitio es simplemente un caso de cargar los archivos modificados, que generalmente es bastante rápido si fue un pequeño cambio, o poner el sitio en modo de mantenimiento mientras ocurre la actualización.

Recientemente publicamos un sitio MVC, y la empresa nos contactó para actualizar parte del texto y agregar un enlace a un nuevo documento pdf. El resto de mi equipo se apresuró a decir que esto no debería hacerse porque el sitio ya está en funcionamiento y no debe modificarse. ¿Hay algo que me haya perdido al no haber sido "criado" como desarrollador de Microsoft?

¿Cuáles son los argumentos en contra de hacer modificaciones a una aplicación web en vivo en producción y esta mentalidad es exclusiva de los desarrolladores de .NET?

Realmente me gustaría entender esta mentalidad y si está justificada en un entorno de desarrollo de Microsoft, o si esta es solo una forma más antigua de pensar.

NOTA: Utilizamos TFS para el control de versiones y los perfiles de publicación para determinar dónde se implementa el sitio (UAT o Producción)

Las aplicaciones ASP.NET MVC están compiladas. Esto significa que no puede simplemente cargar los archivos modificados, como lo hace con un sitio web PHP, por ejemplo. Esto también significa que cuando comience a actualizar el sitio, los usuarios actuales serán descartados (por ejemplo, perderán sus sesiones).

También hay mucho más que hacer que simplemente actualizar los archivos: debe manejar:

• Permisos

  La nueva versión puede requerir un conjunto diferente de permisos en el servidor.

• Configuración

  La nueva versión puede requerir la instalación del servicio Coordinador de transacciones distribuidas (MSDTC), o puede querer usar un servidor SMTP diferente, o tener acceso a Active Directory, etc. Esto implica cambiar tanto la configuración de la aplicación como del servidor mismo. .

• Dependencias

  Por ejemplo, uno de los problemas que a menudo encuentran los principiantes es que mantienen las DLL antiguas al /bintiempo que agregan nuevas con diferentes nombres: la aplicación aún puede usar las antiguas, lo que crea una situación loca donde cambia el código del aplicación, pero el comportamiento de la aplicación sigue siendo el mismo.

• Datos

  ¿Qué pasa si el esquema de la base de datos cambió y la aplicación usa un servidor SQL ordinario en lugar de NoSQL? ¿Cómo realizar el cambio en el esquema? ¿Cómo mantener los datos correctos durante el cambio?

Manejar la transición entre una versión antigua y una nueva de la aplicación es una tarea difícil. Hace unos años, uno de los problemas era que una nueva versión de la aplicación estaba lista, pero los administradores del sistema tardaron días o semanas en implementarla. DevOps aborda este problema, pero requiere que los desarrolladores describan (a través del código o la configuración) el sistema que alojará la aplicación.

Cuanto más grande es la aplicación, más complicada es esta tarea.

• Para una pequeña aplicación web, basta con copiar los archivos de origen al servidor,

• Para algo más grande, debe tener un proceso automatizado que se ocupe del proceso de actualización y la reversión en caso de que algo salga mal,

• Para sistemas aún más grandes, en cada nueva versión, se crean e implementan nuevas máquinas virtuales, y las antiguas se reciclan, lo que garantiza una transición sin problemas de los usuarios de la versión anterior a la nueva.

Las aplicaciones compiladas simplemente fuerzan / alientan a automatizar el proceso antes.

la empresa nos contactó para actualizar parte del texto y agregar un enlace a un nuevo documento pdf. El resto de mi equipo se apresuró a decir que esto no debería hacerse porque el sitio ya está en funcionamiento

OMI, no hay razones técnicas reales para esta negativa; solo quieren evitar hacerlo, porque, si no se automatiza bien, la tarea es propensa a errores .

Lo que suele pasar es que:

1. La aplicación se implementa por primera vez.

2. El equipo pasa unas horas ajustando la configuración para que funcione. Como se esperaba que el equipo entregara hace tres semanas, todos se apresuran y nadie toma nota de los cambios.

3. La aplicación ya está en funcionamiento.

4. Durante algunas semanas, meses o años, algunas personas aleatorias cambian algunas cosas aleatorias en el servidor: por ejemplo, movieron una base de datos a una ubicación diferente, o la contraseña SMTP cambió, causando los cambios en Web.config.

Si actualiza la nueva versión ahora, volverá al primer paso y puede llevar días recuperar la configuración correcta. Dado que el sitio web es en vivo, esto debe evitarse a toda costa.

¿Tiene gerentes de proyecto, un Gerente de Desarrollo u otra persona que no sean los otros desarrolladores?

Tiene sentido CERO que no pueda hacer un despliegue después de su lanzamiento.

Por supuesto, estos cambios deben programarse, costearse y financiarse, entre otras cosas, pero decir "no" no tiene sentido.

La razón principal del comportamiento que está viendo es que este tipo de cambios son propensos a errores. La actualización manual de la aplicación hace que las cosas se olviden y se desincronicen. Todavía debería poder hacer nuevas versiones (y debería ser fácil) , solo que no parches parciales.

Las actualizaciones parciales, como cambiar un poco de CSS o texto en un sitio en vivo, podrían ocasionar que las pruebas salteadas, los entornos de prueba o de escenario no estén sincronizados o, incluso, no comprometan el código con el control de origen. Si se trata de un cambio de código, incluso podría terminar rompiendo el sitio en vivo sin un plan de recuperación.

En .NET porque el código está compilado, puede haber otros problemas, como tiempos de carga largos y pérdida de sesiones de usuario. Estos problemas podrían mitigarse al cambiar a un entorno cálido y usar el estado de sesión fuera de proceso. Sin embargo, a menos que desee pensar en este tipo de problemas y otros problemas específicos de su aplicación cada vez que desee realizar una implementación. Entonces, parchear sitios web en vivo es una mala idea.

A medida que su aplicación crece en tamaño y las personas van y vienen, esto puede pasar de un inconveniente a un problema grave. Entonces, para hacer las cosas más seguras, seguimos reglas como: Para actualizar un sitio web en vivo, debe ser una implementación completa, nunca solo parcheada.

Si aún no está automatizando sus implementaciones (lo que hace que sea fácil y rápido seguir la regla). Las nuevas implementaciones generalmente se realizan junto a la versión existente y luego su sitio web es solo un puntero a la versión que desea (tenga en cuenta que el esquema de la base de datos lo hace un poco más complejo).

1.0.0  // Old version you can roll back to   
2.0.0 <-- IIS points here

En realidad, creo que todas las implementaciones deberían estar realmente automatizadas y eso también incluye implementaciones que no son .NET, por razones similares. Una vez que comience a automatizar las implementaciones, puede garantizar que sean consistentemente rápidas y confiables.

Regularmente publico / vuelvo a desplegar bastantes sitios web ASP.NET MVC implementados en Amazon AWS, Windows Azure y servidores web privados, y no veo ninguna razón por la cual su equipo haga un gran negocio.

Sin embargo, debe diseñar sus sitios web de tal manera que tareas como actualizar textos y enlaces se realicen a través de la base de datos a través de la interfaz de administración del sitio web.

Mi punto es que, si bien los cambios en un sitio web en vivo están bien (se llama desarrollo), la reubicación de la aplicación para cambiar una cadena de texto probablemente sea indicativa de un mal diseño. No estoy sugiriendo que la republicación se pueda hacer sin cuidado.