Una estrategia de control Git Fuente para un sitio web en vivo Sitecore

Question

En primer lugar, pido disculpas por el gran tamaño de esta pregunta como estoy seguro de lo que estoy proponiendo es un "gran problema" en cuanto a la implementación y probablemente podría ser tres o cuatro preguntas separadas en sí mismo. No preguntaría si no necesitaba desesperadamente ayuda.

Se me ha dado la tarea monumental de la revisión de los procedimientos de gestión de riesgos de mi empresa en lo que respecta a nuestro trabajo en línea.

Al tomar ninguna copia de seguridad, ni protegemos nuestros datos que he decidido que, al igual que cualquier persona involucrada en la programación profesional ya debería estar haciendo, nos vamos a proteger nuestro trabajo a través de control de código fuente. Actualmente lo hago a nivel local con Git, pero otros no usan control de fuente y finalmente perdemos muchos de los beneficios que ofrece el control de fuente. Preferiría que tuviéramos un sistema en el que todos usen Git y que haga cumplir la regla de que si no está en control de fuente, no se queda. Obviamente, vamos a necesitar un plan de respaldo, pero como desarrollador, supongo que lo primero que debe hacer es ordenar el aspecto de codificación antes de ordenar una solución de respaldo; obviamente, cualquier consejo sobre eso es más que bienvenido. .

corremos un sitio web ASP.NET con un servidor SQL 2005 back-end, corriendo Sitecore como nuestro CMS de elección. En un mundo ideal, me gustaría tener todas las partes cambiantes de este sitio CMS bajo el control de la fuente, incluida la base de datos.

Por el momento, y sé que esto no es la mejor idea, corro una solución para todas sublayouts construidas en Sitecore. Esto está bajo el control de la fuente y gracias a Git he podido agregar ramas e insertar nuevas características y corregir errores fácilmente (usando Git-flow como mi solución de flujo de trabajo). Todavía soy bastante nuevo en Git, así que no he manejado nada demasiado complejo fuera de comprometerme, ignorando ciertos archivos, etc.

Además de esto, también me gustaría usar el control de fuente para obtener la base de datos contenidos bajo control de fuente. Según tengo entendido, puede serializar elementos de contenido de Sitecore como un árbol enorme dentro del sistema de archivos (¿se guardan como archivos .item si no recuerdo mal?). Si esta es la solución ideal, también me gustaría agregarlos al control de fuente, aunque no sé exactamente dónde se guardarían en el sistema de archivos. Mi sistema de archivos en este momento es la siguiente:

- Data  (Logs, indexes, etc - is this needed to be in source control?) 
- Source (Helper files, although occasionally modified) 
- Website (Containing all the files I edit, and other essential Sitecore stuff) 

Como ya se ha mencionado mi repositorio actual solo está en mi sistema, y ​​consiste en una carpeta única solución con un montón de Ascx, .ascx.cs, Ascx .cs.designer y el archivo .aspx impar o dos. Esto tiende a hacer la vida más fácil al subir como, al igual que con el

Lo que me gusta de entrada en es una forma ideal de gestión de este para todos los desarrolladores. A pesar de usar un DVCS, preferiría tener el servidor en vivo como el repositorio principal y para que todos los desarrolladores lo empujen y lo atraigan, y entre ellos. Usaremos el git-flow workflow solution ya que se ajusta muy bien a nuestra forma de desarrollo. Lo que me preocupa, obviamente, es configurarlo correctamente sin destruir lo que actualmente es un sitio muy caro y de alto tráfico en un servidor sin respaldo.

Sugerencias y consejos sobre la cantidad de datos del servidor que se deben pegar en el repositorio, orientación sobre cómo manejar los datos serializados en Sitecore y, potencialmente, cómo utilizar el control de origen como una forma de realizar copias de seguridad repositorio sería bienvenido. Esta es la primera vez que tengo que crear un sistema de control de fuente/flujo de trabajo para un sitio web en vivo, por lo que cualquier orientación y consejo sobre lo que sería lo mejor para mí sería muy apreciada.

---

EDIT: Voy a poner una recompensa por este para tratar de obtener más guías sobre cómo las personas manejan Sitecore con Git.

Para aclararme a mí mismo, NO estoy buscando una manera de hacer una copia de seguridad de mi trabajo, sino una forma de que un número de desarrolladores pueda trabajar en él y asegurar que el código en el sitio web esté actualizado con un repositorio central . Por ejemplo, he mencionado antes que usaré git-flow para administrar mi flujo de trabajo. El repositorio de origen existirá en un servidor compartido (que a su debido tiempo probablemente será un entorno de prueba), y todos los desarrolladores tendrán clones de eso para trabajar y para presionar. Desde aquí, deseo poder enviar cambios desde el repositorio de origen en la unidad compartida al servidor activo y viceversa si se encuentran errores. También me gustaría incluir elementos de contenido serializado en mi repositorio.

Answer 1

respuesta revisada tras pregunta revisada:

Ok, déjame ampliar en mi idea original cuando tenemos más información de antecedentes de usted. Dado que usted dice que solo tiene una licencia para Sitecore y no puede tener un servidor de prueba por separado, etc., siempre podemos modificar esto levemente y aun así lograr el mismo efecto.

¿Qué pasaría si tuviera varios repositorios en el mismo servidor que ejecuta el Sitecore en vivo? Si es posible configurar Sitecore para usar diferentes raíces/repositorios en el mismo sistema de archivos, p. Cambia la URL a http://yoursite.com/blahblah/test para ejecutar Sitecore en modo de prueba. Esto depende del tipo de licencia que tenga, por supuesto, es decir, si está vinculada a una máquina específica. De todos modos, de esta manera podría probar su sitio en otra rama (por ejemplo, una rama de desarrollo en un repositorio de prueba) antes de fusionar el material en master y dejarlo en funcionamiento.

Por lo que podría tener un repositorio vacío en el servidor, donde todos empujan y extraen. Y podría tener dos repositorios adicionales no desnudos en el mismo servidor, uno con la rama principal desprotegida y el otro con la rama de desarrollo desprotegida. Al iniciar sesión a través de ssh, puede ejecutar fácilmente "git pull" en el repositorio de pruebas si desea probar nuevas funcionalidades en la versión de prueba de su sitio de Sitecore. Cuando esté satisfecho con los cambios, únase a master y presione para dominar en su repositorio simple y actualice el repositorio en vivo de la misma manera.

Creo que debe probar y encontrar una manera de tener dos versiones de su sitio, para que pueda probar los cambios antes de que se publiquen.

---

Original post:

me sugieren fuertemente que usted hace una separación entre el servidor vivo y lo que está trabajando en ese momento, es decir, otro depósito donde se presiona su trabajo también (y tirar de) que funciona como un repositorio de integración. De esta forma, puede integrar código y probarlo localmente (localmente en su organización) antes de enviarlo al servidor activo, de modo que nadie presione accidentalmente el código/bases de datos/lo que sea directamente al servidor en vivo.

También recomiendo que realice copias de seguridad de los datos para el repositorio central, en otras palabras, git debe usarse como un sistema de control de versiones, no como un sistema de respaldo. Incluso git puede fallar y causar repositorios dañados, y luego eres fumado si no tienes copias de seguridad de todos modos.

Además, si es posible, intente separar el contenido real del sitio de la lógica que trabaja en los datos, es decir, trate de mantener un buen concepto de modelo/vista. De esta forma, puede configurar fácilmente un entorno de prueba con bases de datos de prueba que es independiente del código, y no es necesario comprometer bases de datos. A menos que realmente quieras comprometerlos por supuesto :)

Answer 2

Echa un vistazo a HedgeHog's Team Development Soultions (3.0 es la última versión). Satisface muchas de tus necesidades cuando se usa con Visual Studio, Sitecore Rocks, Team City (u otro servidor de compilación) Visita http://hhogdev.com/ para más detalles.

Answer 3

Cuando retrocedo y trato de ver lo que está haciendo, se está gestionando el riesgo de perder la continuidad del negocio. p.ej. Si su sitio deja de funcionar, lo ideal es que pueda utilizar su copia de seguridad para restaurar el sitio de manera completa y automática.

El almacenamiento de datos no es costoso. Realmente, no lo es. Incluso cuando tienes un gran conjunto de datos. Y por lo tanto, es una buena idea requerir que todos los desarrolladores usen git. Muchas organizaciones configuran un solo servidor de git, y usted simplemente empuja/jala hacia ese servidor. Si su solución tiene pruebas buenas y completas, sabrá muy rápidamente si las fusiones de código han roto el software. De lo contrario, probablemente debería usar un servidor central de git para que los desarrolladores lo empujen/tiren, y luego un servidor de integración de lanzamiento separado que use "git fetch" para fusionar los cambios de prueba & del servidor central.

Ha descrito una variedad de componentes de su solución, como el código de copia de seguridad, datos, base de datos, entradas CMS, etcétera. Sin embargo, la pregunta general que debe hacerse es si ha reunido suficientes elementos para poder activar completamente su sitio solo desde la copia de seguridad. Si no puedes hacer eso, no has hecho lo suficiente. Si puedes hacer eso, ya has hecho suficiente.

En cuanto a la licencia, necesita una licencia mejor. Pídale al dueño de Sitecore una licencia para un servidor de prueba, y dígales que es para un servidor de prueba. Un buen proveedor se dará cuenta de que si lo ayudan de esta manera, es más probable que renueve su suscripción. O solicite a su personal financiero otra licencia de Sitecore. Si su sitio CMS basado en Sitecore es una gran utilidad para su empresa, otra licencia no cambiará mucho ese beneficio.

Answer 4

Pasé una hora aprendiendo lo que pude sobre Sitecore (nunca antes lo había oído, herramienta genial), y creo que entiendo lo que estás tratando de hacer. Así es como lo haría:

1. Configurar un repositorio desnudo bendito en una caja Linux (física o virtual, no debería importar).
2. Inicialice un repositorio git en el entorno de producción, en la carpeta base donde se pueden agregar todos los códigos fuente, archivos de configuración y datos al repositorio. (Recuerde establecer user.name y user.email que identificarán a sysadmin y se ocuparán de las actualizaciones de producción.)
3. Cree un archivo de volcado de SQL Server para cada esquema y coloque todos los volcados en una carpeta especialmente marcada dentro del local Repo de producción.
4. Etapa de todos los archivos (git add --all) y confirmar con un "Confirmación inicial, versión X.Y.Z" comentario donde el número de versión es lo que considere que es la implementación actual.
5. Empuje hacia el bendito repositorio.
6. Clona el bendecido repositorio en todos los entornos de desarrollo. (Recuerde de nuevo establecer user.name y user.email para una identificación adecuada en commits.)
7. Comience a usar git-flow.

Tenga en cuenta el paso 3 donde los volcados de SQL Server se crean y se agregan al repositorio. Esto le permitirá deshacer cualquier cambio futuro en la (s) base (s) de datos. Tenga en cuenta que deberá generar nuevos volcados cada vez que realice cambios, pero solo para los esquemas que realmente hayan cambiado. Serialice lo que necesita para serializar y asigne las nuevas serializaciones junto con los cambios de esquema. De esta manera, git revert {commit_hash} es todo lo que necesita para revertir esos cambios específicos (sin olvidar restaurar la base de datos, por supuesto).

Espero que esto ayude, directa o indirectamente.

P.S: No conozco la estructura de su base de datos; si las configuraciones se almacenan en el mismo esquema que los datos del usuario, definitivamente complica las cosas, ya que no puede simplemente restaurar un volcado anterior sin perder datos de usuario nuevos (y presumiblemente importantes). Estoy acostumbrado a Ruby on Rails, donde las revisiones de los esquemas están codificadas por igual; Espero que su marco proporcione una característica similar.