build environment - sitio - Desarrolladores web: ¿es mejor hacer desarrollo en su máquina local o en un host remoto?

pasos para migrar wordpress (16)

¿Cuáles son los pro / contras de hacer desarrollo web en su máquina local en lugar de en un servidor de desarrollo centralizado? Para aquellos que desarrollan en tu máquina local, ¿cómo mantienes una arquitectura de db actualizada para el desarrollo local cuando se involucran varios desarrolladores?

En particular, actualmente estoy experimentando con XAMPP para PHP y me llamó la atención cómo mantengo sincronizada la instancia de MySQL DB en mi máquina local cuando otros desarrolladores cambian regularmente la estructura de datos / db.

¿El desarrollo local solo es práctico cuando se trabaja solo?

Ambos. Realice algunas pruebas de integración y unidad en su servidor de desarrollo (que, idealmente, debería ser lo más similar posible a su servidor en vivo, pero local), luego realice algunas pruebas de aceptación en un entorno de control de calidad, que debería ser la misma máquina que su servidor, o exactamente la misma configuración (hardware, software, etc.) y debe ser remota.

Cuando se trata de la parte de la base de datos de la pregunta, usted puede:

cada uno tiene su propia copia de la base de datos O
mantener los datos / estructura sincronizados ejecutando un script centralizado (tal vez como parte de su compilación)

Creo que es mejor tener una configuración local que esté completamente bajo su control durante el desarrollo para garantizar que los cambios realizados por otros desarrolladores no interfieran con los suyos. Tengo un entorno de desarrollo y prueba configurado localmente para poder realizar ambas tareas sin necesidad de tener en cuenta a otros desarrolladores. Continuamente ejecuto mis pruebas mientras codigo usando autotest, lo que significa que puedo estar seguro de que mi código es correcto y cumple con la especificación correcta.

Después de que la base del código esté en orden, despliego a un servidor de transición (que es un entorno que está lo más cerca posible de la producción) y vuelvo a ejecutar las pruebas. También utilizamos nuestro escenario para ejecutar pruebas de carga y hacer pruebas de usuario.

Desarrollar y ''probar'' en la máquina local está bien, pero las pruebas de calidad deben realizarse en un sistema que refleje el entorno objetivo, es decir, sin todas las herramientas de desarrollo, etc. instaladas.

Esto ayudará a evitar las situaciones ''bueno funciona en mi máquina''.

Descubrí que ejecutar un servidor web local con DB remota funciona mejor. La replicación / sincronización de DB es un problema, así que solo trabajaría con un DB local si realmente tuviera que hacerlo.

Sin embargo, trabajar con un servidor web local elimina toda la molestia y lentitud de cargar páginas / códigos entre cambios.

Descubrí que el desarrollo del código en las máquinas locales que utilizan el control de fuente mientras se accede a una base de datos centralizada de desarrollo ha funcionado de maravilla. Mantener múltiples DB''s sincronizados demostró ser difícil.

En cuanto a mantener su base de datos "sincronizada" cuando otros la están editando. Una forma de evitar esto es poner su esquema de base de datos bajo control de versión. Esto no es tan simple como poner su código fuente bajo control de versión, y hay diferentes maneras de manejarlo.

Lea esta publicación sobre Codificación de terror:

http://www.codinghorror.com/blog/archives/001050.html

No tanto la publicación en sí, sino los seis artículos a los que se vincula por K. Scott Allen.

Básicamente, lo que se describe en esos artículos es un método para definir el esquema de la base de datos, verificando un archivo .sql de esa línea de base y, a partir de ahí, escribir .sql incrementales "cambiar scripts" cada vez que cambie el esquema. Ahora, cada vez que un desarrollador revisa o actualiza una copia de trabajo, se ejecutarán los scripts de cambios pendientes. Tendrá que configurar algunos scripts / herramientas para hacerlo usted mismo a menos que use un marco que lo haga por usted.

En mi posición actual, desarrollo en mi propia máquina. Para proyectos más pequeños, solo uso el servidor web ligero que viene con Visual Studio. También tengo SQL Server 2005 y 2008 configurados en mi propia máquina para fines de desarrollo y pruebas iniciales.

Esto me ha funcionado en general; el único problema con el que me he encontrado es (como han notado otros) mantener las bases de datos sincronizadas es un poco doloroso. Recientemente me he mudado a migrator dot net , básicamente una versión .NET de las migraciones de Ruby on Rails, para mantener sincronizadas las bases de datos locales / de preparación / producción / producción, y eso hace que mi vida sea mucho menos estresante. Una herramienta como esta también hace que sea más fácil trabajar en la base de datos en un entorno de equipo, aunque debe ser lo suficientemente disciplinado como para usarla de manera consistente.

Mis experiencias aquí me han convencido de que el desarrollo local combinado con algún tipo de proceso de control de cambios db, un servidor de integración continua y un buen sistema de control de versiones que permita la fusión (utilizamos TFS) es la mejor manera de hacerlo. Eso les permite a todos hacer lo suyo sin pisar a otra persona, pero también se asegura de que los cambios se fusionen adecuadamente.

En mi trabajo anterior utilizamos IIS en nuestras PC combinadas con una base de datos de desarrollo dedicada y esto era un poco de PITA. Tenías que tener cuidado de no ejecutar ningún proceso que pudiera anular la base de datos o incluso estropear los datos porque podría afectar a otros desarrolladores, y a la OMI, que de alguna manera derrotó el propósito de tener un DB de desarrollo en primer lugar.

FWIW, mencionaré que nuestra configuración es como lo describió el Sr. Matt. Cada desarrollador tiene su propia caja de arena personal para jugar, con su propio servidor web y DB. A punto de publicarse, el código controlado por la versión es una instantánea / bifurcación y se mueve a un servidor intermedio que se supone que imita el entorno real en vivo lo más cerca posible. Las pruebas se realizan, luego el lanzamiento se realiza en un entorno de producción.

Para mis propios proyectos personales (no relacionados con el trabajo), me desarrollo localmente, luego lo hago en vivo. Uno o dos proyectos pueden tener un servidor / entorno de prueba intermediario entre desarrollo y público / en vivo.

He estado construyendo un sitio en Ruby on Rails y he estado desarrollando localmente pero implementándome en una máquina remota tan a menudo como puedo. Leí en Desarrollo web ágil con Rails que cuanto más practiques la implementación mejor, porque cuando llegue el momento de implementarla en producción, no habrá sorpresas.

Normalmente, tendrías un servidor de desarrollo local compartido por todos.

Otra razón para trabajar localmente es que todo funciona más rápido. Esto se traduce en un desarrollo más rápido. ¡El retraso de la red puede ser un factor de productividad!

Para una situación como esa, siempre lo hice en un servidor de desarrollo. Como no hay recompilaciones Siempre puede obtener una nueva instantánea de base de datos todos los días y llevarla a su máquina. O simplemente tenga el servidor web local y dirija el DB al cuadro dev.

Pros a local:

funciona incluso si la red se cae
usted conoce cada herramienta en la máquina

Contras a local:

tiene que sincronizar todo con el servidor de implementación
sin control de versión, puedes derrotar el trabajo de otros

Pros a central:

todos tienen herramientas idénticas
trabajando siempre en contenido "real"

Contras a central:

no puede funcionar si la red no funciona
su (s) herramienta (s) favorita (s) pueden estar perdidas

Estoy seguro de que hay más, pero me vienen a la mente de inmediato.

Soy una tienda de un solo hombre; Tengo un servidor remoto y uno local.

Utilizo el servidor local para el prototipado rápido y el ciclo de desarrollo inicial en el que realizo muchos cambios y necesito probarlos rápidamente. Cuando llegue a una etapa de aproximadamente alfa, estableceré un subhost personalizado para el proyecto y lo implementaré en mi servidor. Existen ciertas características que simplemente no pueden probarse localmente, es decir, el registro de usuario basado en correo electrónico, por lo que estas características se desarrollan en el servidor remoto. Como es MINE, y no una implementación real, todavía está libre de retraso. Como tengo un VPS, tengo el control total del entorno de desarrollo en ambas máquinas.

Un problema con las pruebas en localhost es que puede perder cosas que son enlaces a archivos locales en lugar de accesibles a través del navegador. Mi padre siempre ponía enlaces en el sitio web de su cámara que eran cosas como ''a href = "C: / Mis documentos / Camera Club / Photos ...", y cuando le decía que lo había analizado , él diría "funcionó para mí". Del mismo modo, en un entorno profesional, es posible que tenga cosas que olvidó controlar en el control del código fuente, y por lo tanto no se desplegarán en el servidor real.

Una solución de compromiso podría ser tener máquinas virtuales, ya sea VirtualBox o VMWare o Parallels, para que pueda iniciar una caja virtual de Solaris, Windows, Mac y / o Linux para probarla, que le mostrará cómo se ve su sitio en los navegadores predeterminados. en cada uno, además puede asegurarse de que las cosas realmente funcionen a través de una conexión no local. Aún mejor podría ser tener una máquina virtual a la que implementar y usarla como su servidor web para las pruebas.

Si su SO base es OpenSolaris, incluso puede usar ZFS y usar instantáneas para volver a poner sus máquinas virtuales en su estado base después de cada prueba.

Siempre, siempre desarrolle en una configuración local.
Siempre use el control de fuente.
Siempre ponga todo bajo control de fuente, incluido el esquema de la base de datos.

Parece que hay mucha gente a la que le gusta tener un servidor central que todo el mundo utiliza para el desarrollo: realmente no entiendo por qué preferiría estar en un entorno compartido donde las personas que realizan cambios pueden interrumpir su proceso de desarrollo.

En mi tienda, todos tienen su propio servidor web de desarrollo y su propia base de datos de desarrollo (a menudo colocados en el mismo servidor de base de datos, pero con su propia base de datos). De esta forma están completamente aislados de los otros desarrolladores y no pueden interrumpirse entre sí.

Cuando implementan una característica o corrigen un error, verifican su código y el esquema de base de datos correspondiente para que esté disponible para otros desarrolladores como una unidad completa. Las versiones para el servidor de prueba o el servidor de implementación se hacen desde una versión etiquetada en el repositorio de código fuente.

¡Estable y sano! ¡No veo por qué lo harías de otra forma cuando los servidores de desarrollo son gratuitos!