Pregunta

En un equipo de varios desarrolladores, ¿cuál es la mejor manera de configurar el entorno de desarrollo?

¿Todos tienen sus propias bases de datos completa instalación de SharePoint o compartir contenido, o algo más?

¿Fue útil?

Solución

Cada desarrollador tiene que tener su propia máquina virtual que nadie comparte.

Esto es para dos propósitos. En primer lugar, se puede trabajar sin interrupciones y no perjudicial para el resto del equipo. No te preocupa que alguien reiniciar el sistema o haciendo que no esté disponible para ti. En segundo lugar, puede implementar lo que desea o necesita sin afectar a los demás. Tal vez usted prefiere usar Firefox sobre IE (yo) y las herramientas que tiene. Seguir adelante e instalar en la máquina virtual. Tal vez te encuentras con un elemento web que desea probar. Instalarlo. Lo mejor es que puede tomar su propia instantánea personal antes de instalar la parte web y si las cosas van hacia el sur, hacia atrás simplemente retroceder a la versión anterior.

Una vez que ha hecho toda su andar por ahí y construido su sistema, entonces empaquetarlo como una característica e implementarlo en una prueba compartida / entorno de ensayo antes de moverlo hacia la producción.

El único requisito es que los desarrolladores tienen una conexión desde su máquina virtual a su sistema de control de código fuente. Esto es para que puedan comprobar el código de entrada / salida y si está utilizando la integración continua entonces su servidor de compilación puede hacerse con una copia del código y actualizar la estructura. Si trabaja de forma aislada en su mirada VM, en algo así como una secuencia de comandos robocopy o SyncToy o una herramienta similar para sincronizar el contenido de su máquina virtual a una unidad exterior que empujará el código en el repositorio.

Otros consejos

Muy buena pregunta! Sorprendido de cómo todo lo que parece estar de acuerdo hasta el momento. Esta es Normalmente un tema que puede dividir a la gente mucho: -)

Cada desarrollador debe tener una instancia de servidor virtual (ya sea Hyper-V o VMware, instalado o compartida localmente). Base de datos podría ser compartido, pero cada desarrollador tiene su propia instancia de base de datos (utilizando entornos compartidos de forma remota utilizando VPN es factible, pero a menudo retrasa el desarrollo del proceso hasta dejar de fumar mucho, y por lo tanto se debe evitar si es posible).

Cuando participa en varios proyectos, cada proyecto debe tener un conjunto dedicado de servidores virtuales para cada desarrollador.

También me gusta tener un "sitio de POC" local que puedo hacer con lo que quiero. Yo lo uso para hacer pequeñas pruebas y cosas que no haría en mi servidor de desarrollo del proyecto. Si se pone demasiado sucia, que siempre se puede volver a cargar una instantánea.

Para evitar "que funcionaba en mi caja de" problemas, no debería haber directrices sobre cómo desarrollar. Como tener los menos posibles privilegios en la caja mientras que el desarrollo, y sobre todo tener sólo permisos de visitante cuando se hace el desarrollo normal de la parte web o similar.

Los servidores de desarrollo se debe crear misma imagen de oro y la misma (preferiblemente guión) de configuración del punto cero como la prueba dev, prueba de integración, prod pre y servidores prod by. Esto reducirá al mínimo los problemas en dev prueba debido a problemas de configuración o software especial en el servidor desarrolladores. Incluso sé de equipos de desarrollo (por ejemplo, Ben Robb) que elimine todos sus servidores desarrollador virtuales cada semana y despliegue una instantánea (automatizado con PowerShell) del servidor para mantener los servidores de desarrollo lo más cerca posible de pruebas dev (y los otros ambientes) como sea posible .

A menudo se pasa por alto es que, sobre todo para los equipos más grandes que necesita directrices sobre la forma de nombres debería ser (por ejemplo. Subcarpetas en la carpeta raíz (12hive si te gusta) cómo utilizar espacios de nombres, etc.), cómo implementar (BIN + CAS o GAC, y cuándo usar qué), el uso de la utilidad común, como las bibliotecas. No haber aclarado esto antes del arranque hará que pena lo largo de la carretera y aumenta el riesgo de tener pequeñas islas de código que debería / podría haber sido reutilizadas en todo el equipo (o incluso a través de projecs si las bibliotecas son buenas y lo suficientemente genérico).

Mi opinión es que cada uno debe tener su propia copia de todo. compartir bases de datos, grupos de aplicaciones, servidores sólo te hace cometer más errores o tienen malos entendidos. La depuración es muy incómodo y poco productivo el uso de recursos compartidos y pensar en la base de datos cerraduras, etc.

Una vez que el desarrollador (s) están listas las características se trasladó a un / entorno de ensayo de prueba, que se comparte. Los desarrolladores pueden copiar el / env prueba de escenario para su desarrollo env si es necesario para conseguir un poco de datos reales.

Forzar a los desarrolladores tienen sus propias fuerzas de VM a escribir código que se puede implementar en los Membes equipo en su propia VM ;-) es un disfraz astuto para un gran resultado final!

una gran cantidad de organizaciones compartir un servidor SQL con diferentes bases de datos de contenido y tienen máquinas virtuales individuales con SharePoint y Visual Studio, etc para cada desarrollador. A menudo, estas máquinas virtuales son en realidad alojado en un host de virtualización compartida en lugar de en los desarrolladores estaciones de trabajo debido a los requisitos de memoria, etc.

El @ de SPDevWiki La construcción de un entorno de desarrollo de SharePoint en esto.

Licenciado bajo: CC-BY-SA con atribución
scroll top