... o tiene que pasar por otra persona (una persona que administra los servidores) para implementar su código?¿Eres responsable de implementar tu código en un entorno real?
Entiendo la política de no permitir que todos se conecten a un servidor de producción en vivo, pero me gustaría la posibilidad de tener acceso a mi código, base de datos y archivos una vez que estén en vivo.
¿Cómo es para todos los demás?
Tener un grupo de administración de la configuración, o alguien que no sea el grupo de desarrollo que implementa el código en el entorno de producción tiene sus ventajas. La mayoría de ellos ayuda a imponer un rigor y un seguimiento de las emisiones. Lo ideal es que el equipo de administración de configuración libere código mediante secuencias de comandos. El script extrae del repositorio de código una determinada etiqueta y las libera a un determinado servidor. Al hacerlo, minimiza los errores en el camino.
Creo que el equipo de desarrollo debería haber leído solo los derechos de los datos de producción y la capacidad de ver los archivos de registro. Esto permite una depuración más fácil de los problemas. Si una nueva versión de código también requiere actualizaciones de la base de datos, el equipo de administración de la configuración también debería implementar dichos cambios, por supuesto, por script.
Todo depende de qué procedimientos tenga la empresa. Algunos son más flexibles que otros. Nuestra organización se está alejando de los desarrolladores que tienen acceso al entorno de producción. Ahora todo tiene que seguir el proceso de QA y luego las operaciones (que se ocupan de la implementación y el mantenimiento del código). Creo que terminarás con menos incidentes, pero un tiempo de reparación de errores más largo.
Creo que es más probable que termine con el mismo número de incidentes y un tiempo de corrección de errores más largo. –
@Brian - Eso podría o no suceder. Todavía es nuevo, así que démosle el beneficio de una duda. Es el sabor del día. –
Supongo que una pequeña barrera entre la decisión de algo es una buena idea y probarlo en un sitio en vivo es algo bueno, dada la cantidad de errores idiotas que hago todo el tiempo. Pero pequeña es probablemente la palabra clave allí. –
En el último lugar contratado, hay un grupo específico de personas responsable de la implementación y configuración en los servidores de producción.
Todo su código tuvo que ser registrado en el vcs y aquí es donde obtuvieron el código para implementar. Por lo tanto, no tiene "acceso" para realizar cambios en el código una vez que se activa. Implementaron código nuevo/modificado dos veces por semana, a menos que se tratara de una implementación de emergencia.
Supongo que en su caso el entorno en vivo reflejó el entorno de prueba. No estoy seguro de si la nuestra:/ – JohnnyBizzle
Tenían varios entornos, dos de desarrollo, uno de qa y producción. – buckbova
Acabo de implementar algo en un entorno en vivo hoy. También tengo acceso a la base de datos en vivo.
Se sabe que esto ha causado algunas fallas épicas en el pasado. A veces alguien deja caer una mesa en el entorno de producción en lugar de un entorno de desarrollo. Sin embargo, veo poca ventaja en otra persona que realiza la liberación, especialmente cuando no está familiarizado con el software.
¿Dejar caer una mesa en vivo? ¡Supongo que es por eso que tomas copias de seguridad! – JohnnyBizzle
Por supuesto, pero eso todavía significa que el sistema no funciona mientras alguien restaura la tabla desde una copia de seguridad. – Sjoerd
El flujo de procedimiento de liberación ideal es el siguiente (en mi pequeño mundo):
Dependiendo de qué tan estricta sea su empresa, el desarrollador puede o no tener acceso a la versión en vivo, especialmente si se trata de una gran empresa.
Soy similar. - Me desarrollo en mi propia máquina. - Despliegue a un servidor interno/intranet y deje que el probador lo intente. - Cuando está listo, se coloca en una lista de implementación (concepto reciente) y se implementa en vivo. – JohnnyBizzle
Cada entorno es ligeramente diferente. En comparación, debes decidir qué funciona para ti. Amazon, por ejemplo, hace que sus desarrolladores tengan su propio código, algo que algunos desarrolladores odian, pero es una característica de ese entorno que mantiene bajos los conteos de errores (¿cuándo fue la última vez que vio un error en amazon.com?).
Otros quieren un proceso de control de calidad más estricto, así que crea un departamento de operaciones para supervisar despliegues, pero he descubierto que tienden a crear una atmósfera de negatividad en la empresa: se recompensan justificando su función, lo que implica señalar y apoyando las cosas malas en el mundo. Si los desarrolladores son buenos en su trabajo, el resentimiento puede aparecer si su salario está relacionado con el desempeño.
Personalmente, tiendo a preferir cuidar toda la pila, pero cada vez me estoy moviendo más a proveedores que me permiten preocuparme cada vez menos por el hardware (EC2, Heroku, etc.) y centrarme más en la funcionalidad en el aplicaciones.Personalmente me gusta tener el código y los errores, ya que significa que estoy motivado de forma demostrable para mantener las multas por errores: cada ticket abierto es un retraso para la nueva funcionalidad en la que deseo trabajar.
Cada uno por su cuenta.
Hay argumentos de cualquier manera. Personalmente, me gustaría ser responsable de mi código en vivo y saber que nada ha sido manipulado de antemano (¡eso ya pasó antes!) ¡También sería agradable tener los entornos reflejados! – JohnnyBizzle
Respuestas entorno de prueba y desarrollo mencionado anteriormente. También es muy importante tener un servidor de compilación dedicado y separado que no se use para el desarrollo. Extrae el código fuente del repositorio, compila y crea la distribución (en el archivo EAR o WAR del mundo Java) que luego se implementa en el entorno de prueba, etc.
Este servidor de compilación también puede alojar entornos de CI y realizar compilaciones diarias automatizadas.
¡La persona que reemplacé solía desarrollarse en el entorno en vivo! –
Para ser más específico sobre por qué lo pregunté, tengo una aplicación web que usa un par de archivos xml. En lugar de hacer cambios en esos archivos a través de la aplicación, preferiría editarlos localmente y subirlos al servidor. No deberían cambiar muy a menudo. Lo mismo con algunas de las imágenes del sitio. No cambiarán a menudo, pero preferiría no dejar que los usuarios los mantengan ellos mismos. – JohnnyBizzle
@Ed B. ¡Ahora no llegaría tan lejos! – JohnnyBizzle