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

Question

¿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 su máquina local, ¿cómo mantienen una arquitectura actualizada de db para el desarrollo local cuando se involucran varios desarrolladores?

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

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

Answer 1

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

Parece que hay un montón de gente que les gusta tener un servidor central que todo el mundo utiliza para el desarrollo - Realmente no entiendo por qué se prefiere estar en un entorno compartido donde las personas pueden hacer cambios interrumpir su proceso de desarrollo.

En mi tienda, cada uno tiene su propio servidor web de desarrollo y su propia base de datos de desarrollo (a menudo colocados en la misma base de datos servidor, 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, comprueban 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!

Answer 2

Normalmente tendría un servidor de desarrollo local que todos compartan.

Answer 3

Para una situación como esa siempre lo he hecho 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.

Answer 4

He encontrado que ejecutar un servidor web local, con DB remota funciona mejor. La duplicación/sincronización de bases de datos es un problema, por lo que solo trabajaría con una base de datos local si realmente tuviera .

Trabajar con un servidor web local elimina toda la molestia y lentitud de cargar páginas/código entre cambios.

Answer 5

Pros a lo local:

• funciona incluso si la red se cae
• que saben todas las herramientas en la máquina

Contras a lo local:

• tienen que sincronizar todo al servidor de implementación
• sin ver Control sión puede clobber el trabajo de otros

Pros al centro:

• todo el mundo tiene herramientas idénticas
• siempre trabajan en el contenido "real"

Contras al centro:

• no funciona si la red no funciona
• su herramienta de "favorito" (s) puede faltar

Estoy seguro de que hay más, pero estos vienen a la mente derecha fuera.

Answer 6

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 lo más cercano posible a la producción) y vuelvo a ejecutar las pruebas. También utilizamos nuestro escenario para ejecutar pruebas de carga y hacer pruebas de usuario.

Answer 7

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'.

Answer 8

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 versión en vivo servidor, o exactamente la misma configuración (hardware, software, etc.) y debe ser remota.

Cuando se trata de la parte de base de datos de la cuestión, que bien podría:

• cada uno tiene su propia copia de la base de datos o
• mantener los datos/estructura de sincronización mediante la ejecución de un script centralizado (tal vez como parte de su compilación)

Answer 9

Un problema con las pruebas en localhost es que puede perder elementos que son enlaces a archivos locales en lugar de ser 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 abrir una caja virtual Solaris, Windows, Mac y/o Linux para probarlo, 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 colocar sus máquinas virtuales en su estado base después de cada ejecución de prueba.

Answer 10

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.

Answer 11

He estado construyendo un sitio en Ruby on Rails y he estado desarrollando localmente pero desplegá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.

Answer 12

En cuanto a mantener su base de datos "sincronizada" cuando otros lo 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.

leer este post en el horror de codificación:

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

No tanto el cargo en sí, sino los seis artículos que vincula a K. Scott Allen.

Básicamente, lo que se describe en esos artículos es un método para alinear el esquema de la base de datos, verificando un archivo .sql de esa línea base y a partir de allí 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.

Answer 13

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!

Answer 14

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 ha funcionado bien para mí 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. Me he mudado recientemente a migrator dot net - básicamente un .NET tomar en Ruby on Rails migraciones - para mantener las bases de datos/puesta en escena/UAT/producción local en sincronía, y se está haciendo la vida 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 para usarla de manera coherente.

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 soporte 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 estropearlo los datos porque podría afectar a otros desarrolladores, y a la OMI, que de alguna manera derrotaron el propósito de tener un DB de desarrollo en primer lugar.

Answer 15

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

Utilizo el servidor local para la creación rápida de prototipos 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. Hay ciertas características que simplemente no se pueden probar localmente, es decir. 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.

Answer 16

He descubierto que desarrollar el código en las máquinas locales utilizando el control de fuente mientras se accede a una base de datos centralizada de desarrollo ha funcionado muy bien. Mantener múltiples DB's sincronizados demostró ser difícil.