Una estrategia de control de fuente de Git para un website vivo de Sitecore

En primer lugar, me disculpo por el tamaño de esta pregunta, ya que estoy seguro de que lo que propongo es un "gran problema" en términos de implementación y probablemente podría ser tres o cuatro preguntas por separado. No preguntaría si no necesitaba desesperadamente ayuda.

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

Como no tomamos copys de security ni protegemos nuestros datos, he decidido que, como debería estar haciendo cualquiera que esté involucrado en la progtwigción profesional, protegeríamos nuestro trabajo a través del control de fonts. 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 orderar el aspecto de encoding antes de orderar una solución de respaldo; obviamente, cualquier consejo sobre eso es más que bienvenido. .

Ejecutamos un website ASP.NET con un server SQL Server 2005, ejecutando 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 database.

Por el momento, y sé que esta no es la mejor idea, ejecuto una solución para TODAS las subcampas integradas en Sitecore. Esto está bajo el control de la fuente y gracias a Git he podido agregar twigs e insert 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 files, etc.

Además de esto, también me gustaría usar el control de fuente para get los contenidos de la database bajo control de fuente. Según tengo entendido, puede serializar elementos de contenido de Sitecore como un tree enorme dentro del sistema de files (¿se guardan como files .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 saveían en el sistema de files. Mi sistema de files ahora es así:

- 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 mencioné, mi repository actual solo está en mi sistema, y ​​consiste en una sola carpeta de solución con un grupo de .ascx, .ascx.cs, .ascx.cs.designer y el file .aspx impar o dos. Esto tiende a hacer mi vida más fácil al cargar como, como con el

Lo que me gustaría recibir es una forma ideal de gestionar esto para todos los desarrolladores. A pesar de usar un DVCS, preferiría tener el server en vivo como el repository principal y para que todos los desarrolladores lo empujen y lo atraigan, y entre ellos. Usaremos la solución de flujo de trabajo de git-flow, ya que se adapta 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 server sin respaldo.

Sugerencias y consejos sobre cuánto de los datos del server debe save en el repository, orientación sobre cómo manejar los datos serializados en Sitecore y, potencialmente, cómo utilizar el control de origen en sí mismo como una forma de hacer copys de security en un repository separado. . Esta es la primera vez que tengo que crear un sistema de control de fuente / flujo de trabajo para un website en vivo, por lo que cualquier orientación y consejo sobre lo que sería lo mejor para mí sería muy apreciada.


EDITAR: Voy a poner una recompensa en esto para tratar de get más guías sobre cómo las personas manejan Sitecore con Git.

Para aclararme a mí mismo, NO busco una manera de hacer una copy de security de mi trabajo, sino una forma de que varios desarrolladores puedan trabajar en él y garantizar que el código en el website esté actualizado con un repository central. Por ejemplo, he mencionado antes que usaré git-flow para administrar mi flujo de trabajo. El repository de origen existirá en un server compartido (que a su debido time probablemente será un entorno de testing), y todos los desarrolladores tendrán clones de eso para trabajar y para presionar. Desde aquí, deseo poder enviar cambios desde el repository de origen en la unidad compartida al server activo y viceversa si se encuentran errores. También me gustaría include elementos de contenido serializado en mi repository.

Respuesta revisada después de la pregunta revisada:

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

¿Qué pasaría si tuviera varios repositorys en el mismo server que ejecuta el Sitecore en vivo? Si es posible configurar Sitecore para usar diferentes raíces / repositorys en el mismo sistema de files, por ejemplo, cambie la URL a http://yoursite.com/blahblah/test para ejecutar Sitecore en modo de testing. 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 forma podría probar su sitio en otra twig (por ejemplo, una twig de desarrollo en un repository de testing) antes de fusionar el material en master y dejarlo en funcionamiento.

Por lo tanto, podría tener un repository vacío en el server, donde todos empujen y extraigan. Y podría tener dos repositorys adicionales no desnudos en el mismo server, uno con la twig principal desprotegida y el otro con la twig de desarrollo desprotegida. Al iniciar session a través de ssh, puede ejecutar fácilmente "git pull" en el repository de testings si desea probar nuevas funcionalidades en la versión de testing de su sitio de Sitecore. Cuando esté satisfecho con los cambios, únase a master y presione para dominar en su repository simple y actualice el repository en vivo de la misma manera.

Creo que debe intentar encontrar la manera de tener dos versiones de su sitio, de modo que pueda probar los cambios antes de que se publiquen.


Publicación original:

Le sugiero encarecidamente que tenga una separación entre el server en vivo y en lo que está trabajando actualmente, es decir, otro repository donde empuja su trabajo también (y extrae desde) que funciona como un repository de integración. De esta forma, puede integrar código y probarlo localmente (localmente en su organización) antes de enviarlo al server activo, de modo que nadie presione accidentalmente el código / bases de datos / lo que sea directamente al server en vivo.

También recomendaría que realizara copys de security de los datos para el repository central, en otras palabras, git debería usarse como un sistema de control de versiones, no como un sistema de respaldo. Incluso git puede fallar y causar repositorys dañados, y luego eres fumado si no tienes copys de security 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 model / vista. De esta forma, puede configurar fácilmente un entorno de testing con bases de datos de testing que es independiente del código, y no es necesario comprometer bases de datos. A less que realmente quieras comprometerlos por supuesto 🙂

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

Cuando doy un paso atrás y trato de ver lo que está haciendo, está gestionando el riesgo de perder la continuidad del negocio. Por ejemplo, si su sitio deja de funcionar, lo ideal es que pueda utilizar su copy de security para restaurar el sitio por completo y de forma automática.

El almacenamiento de datos no es costoso. Realmente, no lo es. Incluso cuando tienes un gran set de datos. Y por lo tanto, es una buena idea requerir que todos los desarrolladores usen git. Muchas organizaciones configuran un solo server de git, y usted simplemente empuja / jala hacia ese server. Si su solución tiene testings 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 server central de git para que los desarrolladores lo empujen / tiren, y luego un server de integración de lanzamiento separado que use "git fetch" para fusionar y probar los cambios desde el server central.

Ha descrito una variedad de componentes de su solución, como el código de copy de security, datos, database, inputs de 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 copy de security. Si no puedes hacer eso, no has hecho lo suficiente. Si puedes hacer eso, ya has hecho suficiente.

En el tema de la licencia, necesita una mejor licencia. Pídale al dueño de Sitecore una licencia para un server de testing, y dígales que es para un server de testing. Un buen proveedor se dará count 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.

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

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

Tenga en count el paso 3 donde los volcados de SQL Server se crean y se agregan al repository. Esto le permitirá deshacer cualquier cambio futuro en la (s) base (s) de datos. Tenga en count 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 forma, git revert {commit_hash} es todo lo que necesita para revertir esos cambios específicos (sin olvidar restaurar la database, por supuesto).

Espero que esto ayude, directa o indirectamente.

PD: no sé la estructura de su database; 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.