¿Cómo administro el desarrollo y la implementación de mi website como parte de un grupo?

He estado leyendo este sitio aquí y allá y parece que ustedes tienen una comunidad maravillosa.

En cuanto a mi formación, soy un estudiante de segundo año en la universidad familiarizado con SQL, C ++, Visual Basic y algo de PHP. Uno de mis proyectos esqueueres para el verano incluye la construcción de una aplicación web que permite a los usuarios iniciar session y progtwigr horarios específicos a través de Internet. Normalmente, he sido la única persona que trabaja en un proyecto, pero en este caso formaré parte de un grupo. Como todos somos relativamente nuevos en el trabajo en equipo, me gustaría configurar el control de fuente para mi grupo, por lo que no todos trabajamos en un disco compartido en alguna parte. Además, me gustaría asegurarme de que todos podamos probar nuestros cambios en algún tipo de server de desarrollo que aloje una instancia de nuestro website.

Mi pregunta real es con respecto al set de herramientas que debemos usar para lograr esto. Como grupo, estamos más familiarizados con PHP y MySQL, así que terminaremos usando eso para el código y la database. He utilizado SVN en el pasado para mi uso personal, pero los miembros de mi grupo no están muy familiarizados con el control de código fuente. Probablemente nos quedaremos con algo simple como Excel para la gestión de proyectos y el seguimiento de errores. Idealmente, nos gustaría que las herramientas sean libres y de código abierto.

¿Cómo deberíamos, como grupo, gestionar la construcción de la aplicación real? ¿Existen methods que pueda usar que permitan a cualquiera de nosotros mover los files a nuestra máquina de desarrollo y realizar un seguimiento de quién lo hizo para que no terminemos sobrescribiendo los cambios de los demás? Si esto no es posible, uno de nosotros escribirá algunos scripts para manejarlo, pero me gustaría evitar crear básicamente una aplicación de software separada que solo se utilizará para administrar nuestro proyecto. Otro problema que preveo será actualizar la database que se ejecuta en la máquina de desarrollo. ¿Hay algún método estandarizado que podamos usar para administrar nuestras secuencias de commands SQL entre los cuatro de nosotros?

No espero una respuesta realmente larga (¡después de todo, este es nuestro proyecto!), Pero cualquier consejo útil sería muy apreciado. ¡Una vez que return de vacaciones, estoy deseando empezar! ¡Gracias!

Recomiendo a tu grupo usar el control de fuente para sincronizar tu código. Puede configurar su propio server o simplemente usar un proveedor gratuito como github , código de Google o bitbucket .

Si decides utilizar uno de estos sitios, una buena característica es que también proporcionan seguimiento de problemas gratuitos, por lo que puedes usar eso en lugar de Excel.

La mejor manera de administrar los scripts SQL es dividirlos en files separados y colocarlos bajo control de fuente también. Puede crear files .sql o usar una herramienta para administrar estos cambios; por ejemplo, eche un vistazo a Ruby on Rails 'Migrations . Esto puede requerir un poco de esfuerzo para configurarlo, pero te agradecerás más tarde si estás trabajando en un proyecto de cualquier tamaño …

  1. Elabore un plan sobre cómo lo haría si fuera solo usted.
  2. Divida el plan en tareas que tardan entre 3 y 4 horas en completarse. Asegúrese de que cada tarea tenga un objective mensurable.
  3. Divide las tareas. Intente clasificarlos si es posible para maximizar la eficiencia del desarrollador.
  4. Enséñeles a usar el control de fuente. Explíqueles que usarán esto (tal vez no svn, pero ALGO) en unos pocos años, por lo que también podrían aprender cómo hacerlo ahora. Además, esto ayudará en cada proyecto de grupo que hagan en el futuro.
  5. Haga una secuencia de commands para build y ejecutar sus testings. También script su implementación. Esto asegurará que tenga el mismo mecanismo que va a vivir, como lo hará para probar, lo que aumenta la cantidad de defectos encontrados en las testings. (Esto es opuesto a dejar que existan, pero no se encuentran en las testings).
  6. Usted mencionó actualizar la database de desarrollo. Sería completamente razonable deshacerse de la database de desarrollo a menudo con una actualización desde el directo. Es posible que desee hacer 3 entornos. Desarrollo, puesta en escena y producción. La database de desarrollo contendría datos de testing fabricados. La database de etapas tendría una copy en vivo (reciente en unos pocos días, tal vez). Y, por supuesto, en vivo es en vivo.
  7. Excel funciona bien como una "database de errores". Considere ponerlo en control de fuente que manipule y comprometa. Esto le dará una buena idea de lo que sucedió con el time, y puede corregir los errores más rápidamente.

En cuanto al control de fuente / versión, recomendaría la subversión. Hay algunas herramientas de GUI que pueden usar, o incluso webDAV para acceder al SVN. Esto permitirá a los usuarios editar files en queueboración y también proporcionar detalles sobre quién editó qué, cuándo y por qué … SVN también hará un trabajo bastante bueno al fusionar files que se guardan al mismo time.

No es el concepto más fácil de entender, pero no es muy complicado una vez que se ejecuta.

Sugiero que todos lean el primer capítulo de: http://svnbook.networking-bean.com/en/1.5/

y deberían tener una buena idea de lo que está sucediendo.

También tengo curiosidad por ver lo que la gente tiene que decir sobre la database

¿Cómo deberíamos, como grupo, gestionar la construcción de la aplicación real? ¿Existen methods que pueda usar que permitan a cualquiera de nosotros mover los files a nuestra máquina de desarrollo y realizar un seguimiento de quién lo hizo para que no terminemos sobrescribiendo los cambios de los demás?

Parece que estás buscando administración de compilation . En el caso de PHP, una "compilation" verdadera es tan simple como una colección de files fuente porque el lenguaje es interpretado; no hay compilation

Da la casualidad de que soy uno de los desarrolladores de BuildMaster , una herramienta que básicamente resuelve todos los problemas que has enumerado en tu pregunta … y también suena como si fuera gratis en tu caso bajo la licencia Community Edition. Trataré de abordar algunos de tus puntos de dolor individuales y cómo BuildMaster podría usarse como una solución.

Fuente de control

Según lo sugerido por otros, debes usarlo. El truco cuando se trata de implementación es establecer alguna forma de continuous integration para que cada vez que alguien ingrese, se cree una nueva "compilation". En BuildMaster, puede configurar esto para cualquier proveedor de control de fuente que desee.

Problema / Seguimiento de errores

Excel funcionará, pero no es una solución óptima. Hay muchas herramientas gratuitas de seguimiento de problemas que puede usar para administrar sus errores y características. Con BuildMaster, puede vincular sus errores y la list de características con la aplicación por su número de versión para que pueda verlos dentro de la herramienta en cualquier momento. También puede modificar estados de problemas y agregar descripciones automáticamente si lo desea.

Despliegues

Con BuildMaster, puede crear planes de implementación automatizados para su entorno de desarrollo, por ejemplo:

  1. Obtener el último código fuente
  2. Crear artefacto
  3. Copie files a la máquina de desarrollo
  4. Implementar files de configuration
  5. Actualizar database

La mejor parte es que, una vez que configure esto para otros entornos (punto # 6 del glowcoder), presionar todo el código y las actualizaciones de la database es tan simple como hacer clic en un button.

Otro problema que preveo será actualizar la database que se ejecuta en la máquina de desarrollo. ¿Hay algún método estandarizado que podamos usar para administrar nuestras secuencias de commands SQL entre los cuatro de nosotros?

Actualizaciones de database

Como era de esperar, BuildMaster maneja estos también utilizando el module de scripts de cambio. Cuando un miembro de tu equipo crea una secuencia de commands (por ejemplo, ALTER TABLE ADD [Blah] INT NOT NULL ) puede cargarla en BuildMaster y luego ejecutarla en cualquier entorno que hayas creado.

La mejor parte es que puede agregar un paso en su implementación automatizada y no volver a preocuparse. Como menciona Justin, puede usar files .sql para su código de object (procedimientos almacenados, vistas, desencadenadores, etc.) y ejecutarlos en cada compilation, ya que en esencia son código. Puedes mantenerlos en control de fuente.

Archivos de configuration

Un aspecto de todo esto que puede haber descuidado (pero que inevitablemente se encontrará) es lidiar con files de configuration. Con PHP, puede tener un file .htaccess, un file php.ini, un prepend.php, o puede rodar su propio file de configuration personalizada. Dado que, por definición, los files de configuration deben cambiar entre su máquina personal y la máquina de desarrollo, agarrarlos del control de fuente no sería necesario sin algo de pirateo a la la:

 if (DEV) { // do one thing } else if (PROD) { // do another } 

Con BuildMaster, puede personalizar sus files de configuration y asociarlos con un entorno para que puedan implementarse automáticamente. También mantendrá un historial de cambios para usted.

Pruebas automatizadas

Si quiere el efecto ALM completo, puede probar automáticamente su código durante una compilation automatizada y notificarle si algo falla para que sepa lo antes posible que algo no funciona.


Disculpas por la respuesta "larga aliento", pero me siento como si ya estuvieras adelantando al juego al observar los problemas que podrías encontrar en el futuro y realmente creo que BuildMaster hará que todo este deployment sea simple para tu equipo, así que puedes centrarse en la parte divertida, la encoding!