Inicio > Gestión TI > ¿Deberían los desarrolladores tener acceso a producción?

¿Deberían los desarrolladores tener acceso a producción?

lunes, 25 de marzo de 2024 Dejar un comentario Ir a comentarios

Una pregunta que surge de nuevootra vez en las empresas de desarrollo web es:

«¿Deberían los desarrolladores tener acceso al entorno de producción, y si lo tuvieran, en qué medida?»

Mi opinión sobre esto es que en su conjunto deben tener acceso limitado a la producción. Una advertencia poco antes de que traten de justificar este punto de vista es que este punto de vista no es en absoluto basado en la calidad percibida o la actitud de los desarrolladores – así que por favor no lo tome de esta manera. En primer lugar quiero cubrir algunos argumentos comunes de los desarrolladores que no les gusta u odian esta idea:


«No podemos conseguir cosas por hacer, los administradores del sistema las consiguen en el camino y toman para siempre.»

Bueno, si este es realmente el caso, entonces están en lo cierto. Si no hay suficientes administradores o los administradores no son buenos entonces puede convertirse en un cuello de botella. Sin embargo, el acceso del desarrollador no es la solución porque después de esto todavía tienes mierda o insuficientes administradores. A veces hay otros problemas administrativos específicos que podrían hacer que las cosas tarden más tiempo, más sobre esto más adelante, pero no debería tener un intervalo de tiempo excesivo.

«Siempre hemos tenido acceso antes».

Las compañías recientes parecen comenzar rara vez con los administradores. Por alguna razón, los administradores del sistema se consideran un lujo. Aunque este proceso podría haber funcionado antes, a medida que crece es probable que haya una administración más. Las cosas se ponen más complicadas y esto es probablemente por qué fue contratado un administrador. Así que en este caso, «esto es lo que siempre hemos hecho» no es realmente suficiente argumento.

«Necesitamos acceso para solucionar.»

Quizá, quizá no. Es posible que los administradores sólo le entreguen la información que necesita. Si esta área en particular se convierte en un cuello de botella, el acceso limitado podría estar en orden.

Estos son algunos argumentos posibles contra el acceso restringido para los desarrolladores, sino que dejan pasar a lo que realmente quiero hablar – por qué es una buena idea.

Acceso restringido al proceso crea:

Si los desarrolladores no pueden acceder a producción, una gran implicancia es que no pueden instalar su propio código. Esto significa que los administradores han de instalar el código. Dos cosas, entonces que suceder:

  • Los desarrolladores y administradores de sistemas deben comunicarse – uno con el otro! Los administradores aprenderán cómo instalar el software, lo cual espero no tener que explicar es probablemente una buena cosa.
  • Los desarrolladores tienen que crear un instalador o liberar el proceso que sea fácil y eficaz. Esto también es una buena idea. Ser capaz de reconstruir el ambiente es una parte esencial de la recuperación ante desastres. Entonces, lo qué no puede suceder con acceso restringido es que la instalación del código es un proceso complejo que vive solo en la cabeza de unos cuantos desarrolladores. Además, los desarrolladores no tienen que pasar un tiempo en implementación e instalación de código cuando podrían estar escribiendo nuevo código. Podría tomar más tiempo que al principio, pero asintóticamente será más rápido.

Los administradores también probablemente aprenderán un poco más acerca de que se necesita una copia de seguridad a través de este proceso. Si el administrador no conoce la aplicación y lo único que tiene es confiar en que lo que el desarrollador dijo para sacar copias de seguridad es lo único que realmente tiene que hacerse una copia de seguridad.

Las preocupaciones del desarrollador a menudo no son preocupaciones del administrador del sistema:

En general, los desarrolladores no se centran en la seguridad en las mismas áreas que los administradores de sistemas lo hacen. Por lo general, tienen diferentes áreas de experiencia cuando se trata de la seguridad del sitio web. Temas como cross site, scripting e inyección SQL son areas comunes para la seguridad en el que los desarrolladores tienen conocimientos específicos y los administradores no lo hacen. Privilegios de cuenta, los permisos de archivos, configuración del servidor web a menudo no son aéreas en que los desarrolladores tienen experiencia o estén muy interesados. Son todas las áreas importantes en entornos de producción están destinados a la pericia de los administradores de sistemas. Asimismo, mientras estoy en el tema de la seguridad menos personas con el mejor acceso (principio de mínimo privilegio). Esto también ayuda cuando la llamada viene a las 2 am debido a que el administrador del sistema no tiene que preguntarse si uno de los 15 desarrolladores con acceso estaban en el sistema haciendo… algo.

Control de cambios:

No creo que haya un desarrollador decente por ahí que no se toma en serio el control de cambios. Cuando se trata de su código. Sin embargo, no he visto a muchos desarrolladores que sean serios acerca del registro de todos los cambios que hacen al servidor como un todo (he visto algunos archivos de configuración bajo control de revisiones sin embargo).

Si no se hace esto significa que el entorno de producción no podrá ser reconstruido correctamente. También significa que si ha habido cambios que podrían haber causado un problema, estos cambios puede que no sean reconocidos por las personas que intentan solucionar el problema. Paralelo a esto sería si un administrador acaba de ingresar código a producción y ha cambiado algunas cosas sin decir a nadie o lo verifica.

La persona que posee se debe tener control:

Un artículo de Joel Spolsky creencias cuando se trata de la gestión es:

«Todo el mundo posee cierta área. Cuando lo poseen, lo poseen. Si un administrador, o cualquier otra persona, quiere dar su opinión sobre la forma en que se maneja el área, tienen que convencer al propietario. El propietario tiene la última palabra. »

Los administradores de sistemas son generalmente considerados propietarios del entorno productivo. Los administradores son los que llevan un registro de tiempo de actividad, los que reciben las llamadas telefónicas a las 2 am, en el fondo, ellos son los más cercanos al problema. Cuando los desarrolladores tienen acceso directo a la producción de lo que he visto este control siempre se socavada.

Las Responsabilidades de los administradores de sistemas:

Para que esto funcione, los administradores tienen derechos que deben cumplirse.

  • Invitar a los desarrolladores a pedir lo que necesitan de ti y ser agradable en dárselo a ellos.
  • Asegurarse de que los desarrolladores tienen un buen entorno de desarrollo en el que tienen rienda suelta.
  • Ser razonable y práctico. Cada empresa es diferente, para algunas empresas quizá sólo los desarrolladores no deberían tener acceso debido a la naturaleza del negocio (ej. finanzas). Sin embargo, si no es una empresa financiera, un flujo de trabajo donde los desarrolladores tengan acceso sin privilegios es probable que sea la mejor solución. También podría ser que algunos desarrolladores que hacen las veces de administradores de sistemas, por lo que cada empresa tiene una situación diferente.

Como señalé al principio la creencia en el proceso no tiene que ver con tener o no grandes desarrolladores – muchas funciones del desarrollador son como administradores del sistema (Por ejemplo, vea este articulo envío de correos electrónicos sin que ser marcado como spam). Más bien se trata de un proceso que permite a ambas personas centrarse en su experiencia tanto como la empresa crece. Las cosas pueden moverse un poco más lento. Sin embargo, el negocio debería tener un entorno de producción seguro y más confiable.

Comparte y diviertete:
  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • BarraPunto
  • Bitacoras.com
  • BlinkList
  • Blogosphere
  • Live
  • Meneame
  • MSN Reporter
  • MySpace
  • RSS
  • Suggest to Techmeme via Twitter
  • Technorati
  • LinkedIn
  • email
  • FriendFeed
  • PDF
  • Reddit
  • Wikio IT
  • Add to favorites
  • blogmarks
Top Footer