Tiempo de cambios en mi blog

Pues sí, después de un tiempo, he decido cambiar la estética de mi blog http://www.lfraile.net a pesar de que seguiré escribiendo por mi blog de Geeks.ms, y por mi espacio de live, he decidido que ya era hora de hacer algo con lfraile.net, ya que no funcionaban las búsquedas, el contacto ni nada, y estaba un poco cansado, así que he cambiado de sistema de blogs a BlogEngine.NET, y dándole otro aire, más chulo que el anterior.

Así que ya sabéis, los que me leáis por lfraile.net, tenéis cambios, además también he cambiado el feed, el nuevo lo tenéis aquí.

Por supuesto aun me queda trabajo por hacer en el blog, así que no seáis muy duros, así que ya iréis viendo los nuevos cambios y quizás nuevas funcionalidades en ese blog.

Sincronización de usuarios entre Team Foundation Server y Active Directory

El jueves pasado, mientras tomábamos unas cervezas hablábamos de tecnología y cosas similares, Jesús Jimenez a parte de meterse conmigo … me comentó que había tenido algún efecto “raro” con usuarios de TFS y AD (no recuerdo la pregunta exacta mil perdones … la cerveza …), pero la cosa es que tenía un problema con la sincronización de usuarios de AD con TFS.

Y es que no es algo muy comentado, pero los usuarios de AD y TFS se sincronizan con algo que se llama Generic Security Services, y que se encarga de la sincro de grupos e identidades entre TFS y AD.

La cosa es que esto se sincroniza ante las siguientes condiciones:

  • Cuando se inicia él servidor que tiene la capa de aplicación de TFS.
  • Cuando un grupo de directorio activo se agrega a un grupo de TFS.
  • Según la temporización que está en el web.config de servicios de %PROGRAM FILES%Microsoft Visual Studio 2008 Team Foundation ServerWeb ServicesServices que por defecto es 1 hora (IdentityUpdatePeriod).

Pero ayyyyy amigo ojito con esto último ese setting NO aparece en el web.config por defecto, así que no os volváis loco buscándolo, para cambiar tenéis que añadirlo vosotros, para más información: http://msdn.microsoft.com/en-us/library/ms400727.aspx por supuesto, ojito con lo que tocamos aquí, que luego las cosas de repente “dejan de funcionar” jejeje, ahh  y el formato es de “tiempo”, es decir, una hora es 1:0:0

Si queréis más info acerca de la estructura de seguridad de TFS podéis consultar aquí: http://msdn.microsoft.com/en-us/library/ms252473.aspx

Y bueno esto es todo, y si tenéis problemas con algo de esto, por cierto, como siempre mirad el visor de eventos del servidor que aquí podréis ver lo que ha pasado.

Saludos desde Barna

Adeu.

PD: por cierto, en ese momento te dije, erróneamente, que de estos se encargaba el TFSScheduler, pero nop, estaba equivocado de “responable” en ese momento …

Alinear el número de Build con la versión de los Assemblies

(Lo que está en cursiva está escrito por mi, lo normal es de la cosecha de Martin)

Otra de las dudas que surgieron durante el evento, es la posibilidad de alinear el número de Team Build con el número de nuestra versión de assembly.

Acerca de esto, mi compañero MVP de Team System de Irlanda, Martin Woodward, ya escribió un artículo, que tenéis aquí y que voy a traducir en este post.

Me gusta que el número de mis builds sea el mismo número de versión de mis assemblies (y por tanto de los entregables). Esto hace las cosas mucho más fáciles de seguir, de este modo si recibo un informe de un bug de un cliente, puedo mirar el número de versión y buscar fácilmente por la etiqueta en source contro para ver el código. En todos los entregables distribuidos al cliente, siempre mostramos el número de versión obtenido del assebmly actual al principio de la información de diagnóstico, de este modo se puede comprobar la versión que tienen y empezar a revisarlo. Esto ayuda a archivar los bugs con su versión correcta de código y reportar en que versión se han arreglado (usando la integración entre las Team Builds y los Work Items en TFS).

La gente se sorprende que esta característica no está incluida “out-of-the-box” en Team Build, así que he pensado que podría tomarme un momento para escribir un documento explicativo de como he realizado este trabajo internamente. Como podréis ver, en TFS 2008 tenemos todos los puntos de enlace básicos para realizar esto.

Para comenzar, explicar que nuestro número de versión de .NET se diferencia ligeramente del esquema de nuestro número de versión de Java. En nuestros productos Java, la parte de “número de build” de la versión, es el número de changeset de TFS en ese momento. En .NET hay 4 componentes del número de versión (1.0.1234.5678) y el valor máximo para cada uno de ellos es 65535. Nuestro servidor de producción de TFS está actualmente en el changeset 7698 lo que significa que “disponemos” de 6 años  de este esquema de numeración – esto serçia perfectamente satisfactorio si tuviesemos una eópca de changeset después de cada “major release” (de este modo resetarías el número de build para que sea el changeset actual). Pero como Team build necesita un nombre único para cada build – usar el changeset podría tener mayor riesgo de que se tuviesen dos builds con el mismo número. así que mejor que usar el changeset, he preferido hacer que el número de build de .NET sea un número incremental. Y uso la funcionalidad por defecto de Team Build para crear una etiqueta para ese número de build para hacer el seguimiento de ese número en el control de versiones. El número incremental se almacena en un fichero en el directorio por defecto del directorio donde se guardan los binarios resultantes de la buid (el drop location).

Otro punto que quiero explicar es que, personalmente, no me gusta el standard de Microsoft a la hora de versionar asembblies:

<Major>.<Minor>.<Build>.<Service>

Para mí, es más fácil de leer:

<Major>.<Minor>.<Service>.<Build>

Dónde <Build> es el número que incremento cada vez que se realiza una build. Hasta dónde yo conozco, la diferencia es más bien estética, ya que eso no cambia el modo en que el CLR resuelve las versiones del assembly, de todos modos sois libres de corregirme en los comentarios si esto no es así.

Así que, vamos a ver como conseguir esto. Lo primero, TFS 2008 dispone de un “target” que podemos sobreescribir para generar nuestros propios números de build llamado “BuildNumberOverrideTarget”. Lo más importante es que cada número de build debe ser único, por tanto, una buena regla es usar algo como BuildDefinitionName_1.0.0.1234. Dentro de BuildNumberOverrideTarget simplemente asignaremos el valor a la propiedad “BuildNumber”, para poner el número que queramos, aquí está el nuestro:

<PropertyGroup>
  <VersionMajor>1</VersionMajor>
  <VersionMinor>0</VersionMinor>
  <VersionService>0</VersionService>
  <VersionBuild>0</VersionBuild>
</PropertyGroup>
<Target Name=”BuildNumberOverrideTarget”>
  <!– Create a custom build number, matching the assembly version –>     
  <Message Text=”Loading last build number from file &quot;$(DropLocation)buildnumber.txt&quot;” />
  <IncrementingNumber NumberFile=”$(DropLocation)buildnumber.txt”>
    <Output TaskParameter=”NextNumber” PropertyName=”VersionBuild” />
  </IncrementingNumber>
  <PropertyGroup>
    <BuildNumber>$(BuildDefinitionName)_$(VersionMajor).$(VersionMinor).$(VersionService).$(VersionBuild)</BuildNumber>
  </PropertyGroup>
  <Message Text=”Build number set to &quot;$(BuildNumber)&quot;” /> 
</Target>

Lo primero que hago, es una llamada a una tarea propia que he escrito y que incrementa el número de build almacenado en el fichero que le pasamos. Quería hacer esto mientras mantenemos el fichero bloqueado para el caso de que dos builds intenten actualizar el fichero en el mismo momento. A continuación cogemos este número y montamos el BuildNumber basándonos en este valor. El código de la tarea para incrementar este número lo tenéis aquí:

using System;
using System.IO;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;

namespace Teamprise.Tasks
{
    /// <summary>
    ///   A simple task to increment the number stored in a passed file.
    /// </summary>
    public class IncrementingNumber : Task
    {
        public override bool Execute()
        {
            NextNumber = IncrementNumber();
            return true;
        }
        public int IncrementNumber()
        {
            using (FileStream fs = new FileStream(NumberFile, FileMode.OpenOrCreate, FileAccess.ReadWrite, FileShare.None))
            {
                StreamReader reader = new StreamReader(fs);

                long pos = 0;
                String line = reader.ReadLine();

                // Ignore comments in file
                while (line != null && line.StartsWith(“#”))
                {
                    pos = pos + line.Length + System.Environment.NewLine.Length;
                    line = reader.ReadLine();
                }

                int number = -1;
                if (line != null)
                {
                    number = Int32.Parse(line);
                }
                NextNumber = number + 1;

                // Rewind the file stream back to the beginning of the number part.
                fs.Position = pos;

                StreamWriter writer = new StreamWriter(fs);
                writer.WriteLine(NextNumber.ToString());
                writer.Flush();
                writer.Close();
            }
            return NextNumber;
        }
        [Required]
        public string NumberFile { get; set; }
        [Output]
        public int NextNumber { get; set; }
    }
}

Podéis compilar este código en un assemby que podéis situar en el mismo directorio en source control que el fichero TFSBuild.proj de nuestra build, y que es cargado al principio del proceso mediante esta instrucción dentro del fichero .proj:

<UsingTask TaskName=”Teamprise.Tasks.IncrementingNumber”
           AssemblyFile=”Teamprise.Tasks.dll” />

Lo siquiente que tenemos que hacer es obtener el nuevo número de versión y forzarlo dentro del fichero AssemblyInfo. Personalmente, yo prefiero que el fichero AssemblyInfo esté almacenado en source control para tener un número bien definido para cada release (por ejemplo 1.0.0.0), y hacer que el servidor de build lo versione. Algunas personas prefieren volver a hacer checkin de esto en source control, si lo hacéis, tened precaución de poner en el comentario el texto “***NO_CI***” para asegurarnos de que el check-in no lanze una nueva compilación de CI, que nos podría colocar en un bucle infinito de builds.

Así que para modificar nuestro número de versión después de haberlo descargado de source control, usando una técnica prestada de  Richard Banks, nuestra interpretación es la siguiente:

<ItemGroup> 
  <AssemblyInfoFiles Include="$(SolutionRoot)**assemblyinfo.cs" /> 
</ItemGroup>   
<Target Name="AfterGet"> 
  <!-- Actualizamos los ficheros con el número de versión generado --> 
  <Message Text="Modifying AssemblyInfo files under &quot;$(SolutionRoot)&quot;." /> 
  <Attrib Files="@(AssemblyInfoFiles)" Normal="true" /> 
  <FileUpdate Files="@(AssemblyInfoFiles)"                                 
              Regex="AssemblyVersion(&quot;.*&quot;)]"                 
              ReplacementText="AssemblyVersion(&quot;$(VersionMajor).$(VersionMinor).$(VersionService).$(VersionBuild)&quot;)]" /> 
  <FileUpdate Files="@(AssemblyInfoFiles)" 
              Regex="AssemblyFileVersion(&quot;.*&quot;)]" 
              ReplacementText="AssemblyFileVersion(&quot;$(VersionMajor).$(VersionMinor).$(VersionService).$(VersionBuild)&quot;)]" /> 
  <Message Text="AssemblyInfo files updated to version &quot;$(VersionMajor).$(VersionMinor).$(VersionService).$(VersionBuild)&quot;" /> 
</Target>

Como podéis ver, estamos usando una tarea personalizada que se llama “Attrib” y que es parte de las tareas básicas del  MSBuild Community Tasks para poner los ficheros como lectura/escritura y después usamos la tarea (del mismo paquete) de FileUpdate para acualizar las partes necesarias mediante expresiones regulares.

Y esto es todo lo que se necesita hacer, ahora nuestras builds tienen un número incremental que tiene el número de versión incluido igual que en la información del fichero del assembly.

Bueno, como podéis ver esto no es excesivamente complicado, si bien se requieren conocimientos de como trabajar con la extensibilidad de las builds (Martin es un auténtico crack en esto), para familiarizaros con esto podeís descargaros el SDK de Visual Studio 2008 y ver la documentación de extensibilidad de las Team Builds.

Espero que os haya servido de ayuda a todos, y thanks Martin 😉

Sobre versiones de Team System, TFS e integración Project y MOSS

Me escribe uno de los asistentes al evento del webcast del martes en Second.NUG, con una serie de dudas acerca de varios puntos de Team system y tal y como me solicitó una persona durante el evento, aquí pongo las dudas y las “respuestas”, para que si hay alguien más interesado lo pueda ver 🙂

La primera duda que me plantea Luis (si un tocayo), es si siendo Gold Partner, a que versiones de Team System, ya que sólo disponen en sus descargas de la versión de Development y TFS Workgroup, pues, Luis, efectivamente con el MSDN que os dan por Gold partner sólo tienes disponible la versión de development, y luego en función de vuestra competencia de Gold Partner (tenéis que ser CDS o ISV), he leido que tenéis acceso a una versión completa de TFS: http://www.microsoft.com/spain/partner/program/competenciasCDS-ISV.mspx, la verdad es que esto es un jaleo, hasta para la gente de Microsoft …

Siguiente duda de Luis, me comenta que cuando arranca su Visual Studio Team System Development Ed., no ve la opción de conectarse a TFS, efectivamente Luis, como me comentas en tu correo, debes instalar Team Explorer, que NO se instala a la vez que el Visual Studio, si tienes Visual Studio 2008, el Team Explorer lo puedes encontrar en el mismo DVD que el Visual, en el directorio “TFC”, si es 2005, necesitas el DVD de Team Foundation Server, y en las opciones iniciales del autorun te saldrá la opción de instalarlo (de todos modos creo que el directorio es el mismo).

Y la última duda que me pregunta, es que ellos ya usan Project y Project server, así como un servidor de MOSS y VSS, y si sería muy traumático migrar a TFS, bueno, en cuanto a conexión con Project Server, existe un conector en Codeplex: http://www.codeplex.com/pstfsconnector pero la verdad es que yo no he tenido experiencias directamente con el :(, la última versión de este conector es la 2.0 ya preparada para Project Server 2007 y TFS 2008.

En cuanto a VSS, no hay mucho problema en migrar todo, tienes dos modos, el primero, si no necesitas el histórico de los ficheros de VSS, simplemente puedes hacer el “unbind” de las soluciones de VSS, y después agregarlas al Source Control de TFS, si quieres mantener el histórico, hay una herramienta que te hace la migración, aquí tienes los pasos: http://msdn.microsoft.com/en-us/library/ms181246(VS.80).aspx

En cuanto a MOSS, en TFS 2008, ya se ofrece la opción durante la instalación de usar un MOSS externo en vez de los Sharepoint Services que se instalarían en caso de no conectarnos con un MOSS externo.

De todos modos lo “gordo” de todo esto es el cambio que os va a suponer el modo de trabajar, no olvides que la parte importante de todo esto son las metodologías en las que siempre nos tenemos que apoyar, lo demás son herramientas para simplificarnos mucho el trabajo, y por tanto son muy importantes, pero antes tenemos que tener bien claros nuestros procesos, y aquí es dónde está la parte más complicada del tema, a mi modo de ver.

Bueno, espero  que con esto hayan quedado “más o menos” respondidas tus dudas, la verdad es que son complejas de responder en detalle, con lo que si quieres que profundicemos en algo más no dejes de comentarmelo.

Y por ahora nada más, muchas gracias por cierto a la gente de Second.NUG por el evento, y por supuesto y más importante aún por todas las personas que estuvisteis “presentes”, y para las que consultéis las grabaciones más adelante 🙂

Por cierto, los materiales del evento están aquí: http://cid-adc4781654d8412a.skydrive.live.com/browse.aspx/P%c3%bablico/20080603%20Novedades%20VS2008 y todo lo demás está cogido de la máquina de pruebas de Team Foundation Server de MSDN (tenéis el link en las PPT) instalando yo a posteriori la última versión de las Power Tools y el SP1 beta de TFS 2008.

Nuevo portal en castellano de Team System

Hola, esta misma semana, un colega de aquí de Madrid, Jesús Jiménez (si uno de la saga Jiménez), ha lanzado un portal nuevo acerca de Team system, aprovechándose de los beneficios de ser joven para los dominios .es, ha creado

http://www.teamsystem.es

Así que ya sabéis, otro feed más a añadiros, que conociendo a Jesús, estoy seguro de que va a ser un portal más que interesante.

¡¡¡¡¡¡¡NO OS LO PERDAIS!!!!!

Evento: Novedades VS Team System 2008

Vale, soy lo peor por ponerlo tan tarde, lo asumo, pero no he tenido mucho tiempo últimamente …

Bueno, al tema, mañana, vía Live Meeting, y bajo el auspicio de la gente de Second NUG, daré un evento acerca de las novedades en Visual Studio Team system 2008, hablaremos principalmente de:

– Herramientas de Profiling
– Integración Continua
– Mejoras en la gestión del código fuente
– Modos de trabajo Online y Offline

Y algunas sorpresas (si da tiempo) del SP1 de Team system 2008 (en Beta)

Todo un gran acontecimiento avalado además por el Heroes Community Launch.

Disfruta de las las últimas novedades de desarrollo de la manera más cómoda.

El evento será, mañana día 3 de junio, entre las 19:30 y las  21:30 (GMT+2), y como en anteriores ocasiones, se retransmitirá vía Web a través de Live Meeting.

 

 

 

Si no tienes Live Meeting, puedes descargarlo en el siguiente enlace

Podéis registraros en el evento en el siguiente enlace