Cuantos ingenieros se necesitan para cambiar una bombilla o crear sitios SharePoint

No es curioso, es un hecho que en el ambiente laboral relacionado con tecnologías de información y seguramente en muchos otros, nos encontramos con diversas personalidades, temperamentos y arquetipos colaborando día con día para resolver algún problema técnico o de negocio. Las personas tenemos toda una historia distinta, además de cualidades que en parte de forma consiente o inconsciente constituye la forma muy particular de ver y reaccionar ante vida, en algunos casos estas cualidades son las adecuadas para ciertos escenarios pero que en definitiva en otros no lo son.

Entonces la pregunta es, ¿cómo aprovechar lo que cada quien aporta para generar valor empresarial?, esa es una pregunta que especialistas en Management, Leadership y Coaching podrían responder sin ningún problema. Sin embargo, desde mi óptica por lo menos compartir constantemente una visión compartida con lineamientos claros es esencial para organizar y aprovechar lo que cada persona con su historia histeria y experiencia aporta.

En esta historia, el requerimiento es crear un conjunto finito de sitios con las siguientes características:

  • Cada sitio se basa en la plantilla de sitio de Trabajo en Equipo
  • Cada sitio no deberá tener herencia de permisos
  • Cada sitio deberá contar con 4 grupos “Owners, Visitors, Members, Permissions” bajo la nomenclatura “Sitio + Nombre de grupo
  • Cada sitio cuenta con usuarios específicos para cada grupo.

Lo que piensan los miembros del equipo de TI:

  • Miembro 1 – Vamos a lucirnos con la solución, hagamos un WSP con feature receiver a nivel sitio web para que cuando le den activar en las características del sitio, programáticamente los construya y configure.
  • Miembro 2 – ¿Hay urgencia por parte del cliente como para dedicar tiempo a construir y probar un WSP?, ¿se va a reutilizar la jerarquía en algún otro sitio en el futuro?, ¿conviene dejar archivos en el 12 hive y un ensamblado en el GAC con full trust assembly?, ¿vamos a implementar en DEV, QA, UAT y PROD el WSP? Yo digo que construyamos los sitios manualmente usando el UI de SharePoint.
  • Miembro 3 – Usemos scripts en un archivos *.bat que ejecute el comando stsadm.exe para crear los sitios y grupos, pasamos parámetros e nivel comando y creamos un solo archivo que cuente con todas las instrucciones necesarias.

Después los miembros dan inicio a los argumentos técnico-personales para defender su postura a capa y espada, como si fueran program managers de microsoft, correos electrónicos empiezan a fluir con preguntas que toman minutos leer y escribir de regreso para ser enviados de nuevo. El tiempo pasa, el tema sube de nivel, siguen estancados, el usuario pregunta por sus sitios y en eso Miembro 2 lo toma personal, sube de nivel su contestación y claudica ante su postura. Miembro 1 ratifica la postura de Miembro 2 con el afán de no afectar al equipo y Miembro 3 procede a ejecutar la postura del Miembro 2. Tiempo total transcurrido 2.5 horas.

Si lo analizamos, todos pierden. El espíritu del equipo se deteriora, definitivamente se ve mal y el usuario de plano esperando. Realmente cualquier postura es aceptable y totalmente factible, cada una con sus peculiaridades, estimaciones, esfuerzos y consecuencias.

Dicho esto, tengo 2 preguntas:

  1. ¿Cómo podríamos contextualizar las cosas para asegurar que antes de dar inicio a una solución construida por ingenieros, todos estén viendo hacia el mismo lugar? Esa es una respuesta que probablemente podamos encontrar aquí http://www.crecenegocios.com/los-objetivos-de-una-empresa/
  2. ¿Qué estrategia técnica conviene utilizar para un escenario donde el resultado se requiere de inmediato? A veces me pregunto si mi trabajo es preguntar, sin embargo haciendo un intento de posible respuesta, dejo algunos cuestionamientos respecto al escenario planteado y claro, su implementación.

Construyendo sitios de forma manual

Pros

  • Rápida ejecución usando UI de SharePoint
  • Cero dependencia a código, ensamblado o XMLs, todo queda en la base de datos usando los site definitions y templates propietarios de SharePoint que si están considerados para ser migrados y respaldados

Cons

  • No es repetible
  • Requiere de intervención manual para replicar en cada ambiente y por lo tanto hay margen de error

Implementación

Ubicados en el sitio en cuestión accedemos a Acciones de sitio, Configuración del sitio, Toda la configuración del sitio y al de final las galerías elegimos crear sitios o área de trabajo. Especificamos el nombre, url y los siguientes puntos:

Crear sitio Configurar grupos
image image

 

Construyendo sitios programáticamente

Pros

  • Total portabilidad a múltiples ambientes y sitios con mínimo esfuerzo de implementación
  • Aprovisionamiento y des aprovisionamiento flexible de la funcionalidad y dependencias

Cons

  • Crea una dependencia a un WSP, ensamblado en GAC y archivos en 12 hive
  • Requiere de construcción, pruebas, empaquetamiento y puesta en marcha en cada ambiente
  • Pasa a control de versiones y gestión

Implementación

En este caso vemos que utilizamos una colección especial de tipo diccionario para almacenar la URL y Nombre del sitio que deseamos crear. Existen varias formas de hacer lo mismo, en este caso recorremos la colección de plantillas SharePoint para poder elegir la que usaremos “Team Sites”. Recorremos la colección de nuestro diccionario y utilizamos la colección Webs para agregar un nuevo site pasando los argumento recolectados, lo mas importante destacar en este punto es que el ultimo argumento false indica que no se mantiene la herencia y a continuación ya dentro del sitio rompemos la herencia, posteriormente recorremos el arreglo que tiene el nombre de los grupos que estaremos construyendo programáticamente, ese código se los debo y si alguien quiere compartirlo adelante.

           uint        lcid_english = 1033;
            string      siteUrl = "http://portal.litwareinc.com";
            string[]    groupTypeNames = {"Owners","Members","Permissions","Visitors"};

            Dictionary<string, string> targetSites = new Dictionary<string, string>();
            targetSites.Add("demo1", "Sitio de demostracion 1");
            targetSites.Add("demo2", "Sitio de demostracion 2");
            targetSites.Add("demo3", "Sitio de demostracion 3");
                    
                using (SPSite site = new SPSite(siteUrl))
                {
                    SPWebTemplate siteTemplate = null;
                    SPWebTemplateCollection templateCollection = site.GetWebTemplates(lcid_english);
                    
                    foreach (SPWebTemplate template in templateCollection)
                    {
                        if (template.Title.Equals("Team Site"))
                        {
                            siteTemplate = template; 
                            break;
                        }
                    }

                    using (SPWeb web = site.OpenWeb())
                    {
                        foreach (KeyValuePair<string, string> siteInfo in targetSites)
                        {
                            using (SPWeb newWeb = web.Webs.Add(
siteInfo.Key, 
siteInfo.Value, 
string.Empty, 
lcid_english, siteTemplate, false, false))
                            {
                                newWeb.BreakRoleInheritance(false);
                                newWeb.Update();

                                foreach(string groupTypeName in groupTypeNames)
                                {
                                    string groupType = string.Format("{0} {1}",siteInfo.Value,groupTypeName);
                                    
                                    // aqui deberas crear el grupo y asignar los permisos         
                                }                                                                  
                            }                            
                        }
                    }                
                } 

Construyendo sitios con comandos stsadm.exe

Pros

  • Reutilización moderada e intervención manual para especificar sites, groups que se aprovisionaran por los comandos
  • Fácil de corregir y reaccionar ante cualquier error
  • La forma recomendada por Microsoft

Cons

  • Crea una dependencia al script que ejecuta los comandos de staadm.exe para la estructura solicitada
  • Pasa a control de versiones y gestión

Implementación

En esta alternativa utilizamos las sentencias del comando stsadm.exe ubicado en c:program filescommon filesmicrosoft sharedweb server extensions12bin especificando mediante –o la opción que deseamos y mediante los parámetros especificamos lo que requerimos. Específicamente –unique describe que no queremos heredar los permisos. Subrayo en rojo la parte donde especificamos el URL del sitio que estaremos creando. En este caso estamos creando un sitio llamado Sitio 1 y posteriormente creando cuatro grupos en donde los grupos Visitors y Members tienen como dueño al grupo Permissions.

stsadm.exe -o createweb –url “el url del sitio donde crearemos/url del nuevo sitio -lcid 1033 -sitetemplate STS#0  -title “Sitio 1” -description “” –unique

stsadm.exe -o creategroup -url “el url del sitio donde aplicaremos” -name “Sitio 1 Permissions” -description “Permissions of the site” -ownerlogin “administrator@litwareinc.com” -type “Owner”

stsadm.exe -o creategroup -url “el url del sitio donde aplicaremos” -name “Sitio 1 Owners” -description “Owners of the site” -ownerlogin “administrator@litwareinc.com” -type “Owner”

stsadm.exe -o creategroup -url “el url del sitio donde aplicaremos” -name “Sitio 1 Visitors” -description “Visitors of the site” -ownerlogin “Sitio 1 Permissions” -type “Visitor”

stsadm.exe -o creategroup -url “el url del sitio donde aplicaremos” -name “Sitio 1 Members” -description “Members of the site” -ownerlogin “Sitio 1 Permissions” -type “Member”

 

Personalmente en ocasiones he llegado a pensar, ¿qué es mas complejo?, la tecnología o la psicología, en fin.

¿Cuál es la mejor alternativa? Depende Sonrisa

Originalmente publicado en msmvps.com

Publicado por

haarongonzalez

Consultor de tecnología de la información dedicado a entregar soluciones de misión crítica para organizaciones donde la colaboración, la comunicación y el conocimiento son su inversión estratégica. Reconocido como Microsoft Most Valuable Professional en ASP / ASP.NET desde 2005 y SharePoint Server desde 2009. Interés: Satisfacción del Cliente, Excelencia Operacional, Desarrollo de Personas, Ingeniería en Pre-Ventas Especialidades: Colaboración, Gestión de Contenidos Web, Gestión del Conocimiento, Gestión de Contenidos Empresariales, Gestión de Formularios, Intranet, Extranet, Portales, Implementaciones de entornos on-premises de SharePoint, Arquitectura de soluciones, Soporte Especializado en SharePoint y Office 365 Tecnologías: SharePoint todas las versiones, Office 365, Nintex, DocuSign, Sharegate, PowerApps, Flow, SPDocKit, InfoPath, .NET, C #, JavaScript, CSS, Skeleton Framework, Office 365 PnP

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *