Ya están disponibles en el web de Microsoft para descargarlas, y aunque algunos privilegiados ya habíamos podido probarlas, ya están públicamente disponibles, y la verdad, traen mejoras muy interesantes, así que os recomiendo que os las bajéis: TFS July 2008 Power Tools.
¿Y qué traen estas nuevas power tools? Algunas de las nuevas mejoras son:
En fin que merece la pena descargarlas y empezar a probarlas …
Los que hayáis estado en alguna de mis charlas, leído mi blog de vez en cuando, me habréis oído decir que una de nuestras máximas prioridades, a la hora del desarrollo, es aportar valor al cliente, y bueno, siempre hablamos de las herramientas, las prácticas y los valores que tenemos que tener en mente para esto, pero sin embargo, hay algo de lo que no he hablado, y que realmente es el primer sitio dónde podemos empezar a dar valor, y es valorando a las personas del equipo.
Es extremadamente importante que la gente que tenemos en la empresa, equipo, con nosotros, esté valorada tal y como se merecen, lógicamente hay tantos tipos de personas como personas existen, siempre habrá gente que hace mejor o peor su trabajo, que se implica más o menos en proyectos, empresa, etc. Y a todos hay que valorarlos en su justa medida.
Si no hacemos esto, queramos o no, va a repercutir en la calidad de los proyectos que hacemos, es como cuando se comenta que para las metodologías ágiles necesitamos equipos de gente responsable, y yo digo, ¿si no tienes gente responsable qué clase de proyectos haces?, pero más importante aún que el proyecto es cuidar a la gente.
Inicialmente aunque alguien, a pesar de que su sueldo (si vamos a hablar de dinero), o sus responsabilidades, no estén de acuerdo a su implicación, ya que esta sea una persona que participa activamente de los equipos, los compañeros, la empresa, repito, aunque inicialmente esa persona no esté valorada, puede que siga adelante con su implicación y dando el 100%, pero al medio plazo (ni siquiera a largo), eso va a pasar factura, va a sentir que no está valorada, y aunque quiera seguir dando el 100% va a ser imposible, ya que este tipo de cosas invariablemente nos afectan en nuestro día a día, y además a nivel personal, lo cual debemos evitar siempre, pensad que trabajos con y para personas, no con máquinas, y como tal debemos tratarnos.
Otra consecuencia de esto es la temida rotación, que aunque no siempre es mala (de esto si queréis hablamos otro día), en este caso si que se convierte en un “bad factor”, porque si alguien se va de nuestros equipos o empresas, que no sea porque no se le valora, ya que esa persona ya nunca volverá y eso es malo, muy malo.
¿y cómo se puede hacer para valorar a la gente? bueno una de las cosas más directas y que seguro que todos estamos pensando es el sueldo, es importante que los sueldos vayan acorde a la implicación de las personas, valor que generan al cliente, oportunidades que generan a la empresa, más aún que referente a puestos, categorías, etc. las personas han de recibir lo que se merecen por su implicación y por el valor que aportan en su trabajo, de este modo podemos tener desarrolladores mucho más implicados en su trabajo que jefes de proyecto, o jefes de proyecto mucho más implicados que gerentes o directores de proyecto, y esto es importante reflejarlo también en los sueldos.
Por supuesto, no todas las empresas, por desgracia, se pueden permitir dar los sueldos que quisieran a sus empleados, y desde luego, sólo con sueldo no se valora a las personas tenemos que ver todo lo que tenemos a nuestra disposición, y aquí no hay recetas fijas, desde promover determinadas actividades para la gente, mayores capacidad e independencia en su toma de decisiones (algo que la gente que se implica suele valorar mucho), o cosas tan simples como una llamada de apoyo (si una llamada aquí un correo no vale), en fin que hay muchas cosas, cada cual debe ver y decidir en su caso cuales son las más adecuadas.
Y bueno, por suerte, yo, por suerte en casi todos los sitios que he estado he sido bien valorado en los sitios dónde he estado, tanto a nivel de sueldo, siempre que las condiciones lo han permitido, y con otros muchos factores, pero bueno, se que esto no siempre es así, y por eso quería escribir esto, para que todos lo tengamos siempre en cuenta.
No se si muchos de vosotros conocéis que son los VSTS Rangers, pero bueno, en definitiva es un grupo dentro de Microsoft con gente de Microsoft Consulting Services, que crean ciertas herramientas para Visual Studio Team Syste, como puede ser por ejemplo el WCF Load Test que coge trazas de WCF y genera pruebas unitarias para reproducirlas después en una prueba de carga de VSTS.
Pues acaban de sacar una nueva herramienta en este sentido que es el SQL Load Test y que coge los resultados de una sesión del SQL Profiler y nos permite generar esas pruebas unitarias.
En fin tiene buena pinta,, a ver si la pruebo (otra cosa más).
Y bueno, también comentaros que no me he olvidado del blog, pero últimamente tengo mucho trabajo ya demás estoy entrenando para mis próximas vacaciones, si entrenando, y es que, si todo va bien, me voy aquí ;).
Prometo fotos a la vuelta y por supuesto comentarios por aquí ….
Bueno amigos, después del excelente resumen que ha hecho Jorge en su blog, y como creo que aún no lo habíamos anunciado públicamente, lanzo la convocatoria del siguiente evento :).
En este no coincidimos con el fútbol, así que espero veros por allí a todos.
Esta vez nos acompañará Roberto González, MVP de Biztalk, un auténtico titán del Biztalk, WF, y WCF, no os lo perdáis
Y el nombre del evento es:
Integración entre Workflow Foundation y Windows Comunication Foundation
Tenéis más detalles y el link de inscripción aquí.
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.
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:
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 …
(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 "$(DropLocation)\buildnumber.txt"" />
<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 "$(BuildNumber)"" />
</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 "$(SolutionRoot)"." /> <Attrib Files="@(AssemblyInfoFiles)" Normal="true" /> <FileUpdate Files="@(AssemblyInfoFiles)" Regex="AssemblyVersion\(".*"\)\]" ReplacementText="AssemblyVersion("$(VersionMajor).$(VersionMinor).$(VersionService).$(VersionBuild)")]" /> <FileUpdate Files="@(AssemblyInfoFiles)" Regex="AssemblyFileVersion\(".*"\)\]" ReplacementText="AssemblyFileVersion("$(VersionMajor).$(VersionMinor).$(VersionService).$(VersionBuild)")]" /> <Message Text="AssemblyInfo files updated to version "$(VersionMajor).$(VersionMinor).$(VersionService).$(VersionBuild)"" /> </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 😉
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.
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
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!!!!!
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