|
Blog acerca de Team Foundation Server, Team System, metodologías de trabajo ágiles, y acerca del desarrollo y la tecnología en general
November 2006 - Posts
-
Hola a todos, hace ya unos días que no escribía nada, cosas del "tiempo", pero bueno, hoy veo algo que merece un breve apunte, y es que ya está disponible la versión 2.0 de Teamprise.
Para los que no conozcáis Teamprise, es una herramienta que nos permite acceder a Team Foundation Server, desde entornos Linux, Apple y por supuesto, Windows.
Pues bueno, ayer "liberaron" la nueva versión, con nuevas características como la búsqueda de Work Items, algo que ya pude ver en el Tech·Ed en Barcelona, y que tiene una pinta estupenda, aquí os dejo un pantallazo (directamente de la web de Martin):
Y es que una pantalla de búsqueda, sin necesidad de usar el WIQL, es algo, que los usuarios no técnicos (y también los técnicos) del Team Explorer, van a agradecer bastante.
Bueno, aquí os dejo un link al post de Martin Woodward (una de las personas que trabajan en Teamprise y MVP de Team System), para que veáis algún pantallazo más y las nuevas características, si tengo tiempo, intentaré traducirlo y ponerlo aquí (previo permiso de Martin por supuesto).
http://www.woodwardweb.com/teamprise/000310.html
|
-
Ha salido un nuevo libro acerca de Team Foundation, que tiene una pinta estupenda, además está escrito por tres MVPs de Team System, la cosa promete, a ver si lo encargo y os comento que tal está.
Bueno, ya tengo fecha aproximada de llegada para el libro: 14 de diciembre J
|
-
Estaba leyendo un artículo de Rodrigo Corral sobre estimaciones y de cómo se convierten en compromisos a veces, y bueno lo primero, estoy totalmente de acuerdo con Rodrigo y me han parecido artículos muy interesantes, y esto, también me lleva a pensar en uno de los grandes peligros a la hora de ajustarnos a las estimaciones para que sean lo más cercanas posibles a la realidad, y que es cómo muchas veces las estimaciones de los desarrolladores se ven influidas por las especulaciones que como desarrolladores hacemos, cuando los desarrolladores nos ponemos a pensar "ahhh ¿y si aquí meto esta funcionalidad X que seguro que va a ser necesaria en el futuro?", con lo que la estimación (que me reitero una estimación NO es un compromiso) ahora sí que está perdida, ya que además de hacer la funcionalidad planteada en un principio, vamos a hacer otra, que nadie nos ha pedido. Esto es extremadamente peligroso a la hora de realizar un proyecto, ya que, lo primero, es que estamos modificando la planificación sin haber consultado previamente si es necesario, lo segundo, muy probablemente acabemos haciendo trabajo de más, que nuestro cliente no necesitaba y no va a apreciar, y que tercero, es posible que por esto, dejemos de hacer trabajo que nuestro cliente SI necesitaba, y esto es un gran problema. Este tipo de especulaciones se tienen que evitar siempre, cualquier funcionalidad que detectemos durante nuestro trabajo como desarrollador (ahora estoy con la gorra de desarrollador puesta), siempre, siempre, se tiene que verifica con el jefe de producto/cliente, ya que él es el que tiene la visión del negocio de la aplicación que estamos desarrollando, lógicamente estamos asumiendo que tenemos un jefe de producto/cliente que está dispuesto a colaborar a la hora de la toma de decisiones en cuanto a funcionalidad se refiere, y esto es lo que hay que hacer entender a los clientes a la hora de la implicación en un proyecto, no es válida la posición de, voy, tomo los requisitos en dos horas, me vuelvo a mi sitio, y me estoy dos meses desarrollando lo que yo creo que es la visión de negocio. Siempre tenemos que apoyarnos en el jefe de producto/cliente a la hora de decidir que funcionalidad es necesaria y prioritaria y cual no. Por supuesto, esto tiene mucho que ver con los principios del manifiesto ágil ("Customer collaboration over contract negotiation"), y para poder conseguir esto se tienen que dar algunos condicionantes como tener siempre cerca al responsable de la toma de decisiones sobre funcionalidad. Planificar en iteraciones también es muy importante respecto a esto, lo primero es que nos van a ayudar a hacer mejores estimaciones, ya que siempre es más sencillo estimar un conjunto pequeño de funcionalidades y a corto plazo, y favorecerá el que surjan menos especulaciones durante ese plazo de tiempo ya que tenemos que decidir que es lo que se va a hacer, concretando todas las dudas al principio de la iteración. Por supuesto, y como siempre digo, es importante rodearse de buenos desarrolladores, que eviten caer en la tentación de la especulación, y se centren en entregar buen software, y si no es posible que todos sean buenos desarrolladores y con experiencia (nadie nace sabiendo y hay que aprender en el camino), sí que es necesario que al menos haya uno que sea un poco el "cabeza" de grupo, y en el que se apoyen el resto de desarrolladores con menos experiencia o conocimientos. Bueno, esto es un poco lo que me rondaba la cabeza y quería escribir, y que se resume en NO hacer especulaciones sobre lo que no estamos cualificados para hacer, y que corresponden a otras personas, y centrémonos en hacer software de calidad.
|
-
La gente de Accient, ha recopilado todos los widgets que hay para Team Foundation Server, Team System, y Visual Studio 2005, y los ha puesto en una página para tenerlos todos listados, vaya lo mismo que empezé haciendo con un post yo aquí pero ampliado, interesante, aquí os lo dejo: http://accentient.com/widgets.aspx
|
-
Una cuestión que preocupa a mucha gente en los eventos que he dado de TFS, es el número de proyectos que se pueden crear en TFS, ya que eso puede definir la manera de gestionar todos nuestros proyectos, hasta ahora, no había una respuesta clara al respecto.
Ya hay una respuesta oficial por parte de Microsoft en el MSDN, Bill Essary, ha publicado recientemente un artículo al respecto, aquí os dejo el link, y paso a hacer un breve resumen y comentarios acerca de lo leído, aunque os recomiendo, a todos aquellos que estéis encargados de la administración de un Team Foundation Server, la lectura de este documento.
Lo primero que vemos, es que el principal factor limitante es el tamaño de la cache de los workitems en el cliente, esta caché está en %userprofile%\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache esta cache es la que nos determinará cuando un servidor se está acercando a sus límites. Cuando nos estemos acercando a estos límites, al tener que descargar más información de la cache, los nuevos clientes que conectemos al servidor tendrán una carga extra, tanto de procesamiento de estos datos, como de tráfico de red al conectarse al servidor, esta cache lógicamente, es dependiente, principalmente, pero no únicamente, de los tipos de Workitems y plantillas con las que se crearon los proyectos existentes, y cuanta mayor complejidad tengamos aquí, menor va a ser el límite para la creación de nuevos proyectos.
En líneas generales esto nos conduce, según el documento a los siguientes límites genéricos:
- Si estamos creando proyectos basados en la plantilla de CMMI el límite para la cache será el correspondiente a 250 proyectos
- Para proyectos basados en la plantilla de MSF Agile, tenemos un límite de 500 proyectos.
El problema viene cuando usamos plantillas personalizadas, en este caso lo que tenemos que observar es el tamaño de la tabla de Rules del servidor esta tabla la tenemos en el servidor de TFS, en la base de datos de TfsWorkItem y miraremos el tamaño de la tabla, cuando alcance los 30Mb, estará en el límite y cuando alcancemos el 80% de carga (unos 24Mb), deberíamos tener en cuenta algunas puntos especiales, y lo primero es consultar en la guía de administración el punto de Team Project Limit, y en caso de tener que recuperar desde un back up, al conectar los nuevos clientes, que se haga en grupos de menos de 100 clientes para minimizar la carga de proceso, tanto en el servidor, como en la red, como en los ordenadores de cliente, teniendo en cuenta que esta penalización SÓLO se da en la primera conexión después de la restauración.
También en el documento, se proporciona una hoja Excel para calcular los límites de creación de proyectos, basado en el tamaño de la tabla de Rules del servidor.
Por cierto, también dice algo que cualquiera que haya trabajado con Team Foundation Server (y en general con Visual Studio 2005), ya ha podido comprobar y es la necesidad de poner 1Gb de RAM en las máquinas cliente.
Y bueno esto es el pequeño resumen que hago del documento, de todos modos, aquí os dejo el documento al completo para que lo podáis consultar:
Team Foundation Server Team Project Limits
|
-
Ya estoy de vuelta por Madrid, y es el momento de hacer un breve resumen de lo que ha sido el TechEd para mí, y la verdad es que han sido unos días estupendos.
Empezemos por la primera charla, la preconference de Roy Osherove, que hizo una estupenda introducción a VSTS, metodologías ágiles y sus prácticas, y además lo hizo de forma muy amena (incluidas las divertidas canciones que cantó J), aunque, bueno, fue un poco básica para lo que yo esperaba, pero lo cierto es que para gente que no había tocado antes ninguna de esas prácticas, estuvo muy bien, y algún que otra práctica nueva aprendí, como el método que sigue para nombrar los test unitarios: NombredelMetodoaProbar_Prueba_ResultadoEsperado, hasta ahora me quedaba en las dos primeras partes. Y bueno el primer día no dio mucho más de si que las preconference.
En el segundo y siguientes días ya nos empezamos a meter en materia, la keynote, pues bueno, nos marcaba un poco por dónde iban a ir los tiros del TechEd, mucha metodología ágil, Ajax, Windows Vista, y C#/.NET 3.0, bastantes cosas interesantes para ver en tan poco tiempo ciertamente. A partir de aquí ya pasamos a las charlas, que tampoco me voy a meter en detalle, lo cierto es que algunas de ellas, me parecieron un poco "bajas" de nivel para lo que anunciaban, y otras, como por ejemplo la de Ingo Rammer, o las de Ajax de Andres Sanabria, estuvieron muy interesantes, y como no las de Rafal Lukawiecki, que como siempre estuvo impresionante.
A parte de las charlas, otra cosa que me ha gustado mucho, es el ambiente que se respiraba entre la gente que estábamos por allí (al menos entre gran parte de los españoles que nos juntamos por allí), que hicieron del TechEd, un buen sitio para conocer gente nueva (o conocida de los foros) y gente tan estupenda como Pep Lluis, Rodrigo Corral, David Salgado, la gente de Pand (perdón me he olvidado del nombre), Chus y su compañero (otro nombre que se me olvida), y un largo etc., y como decía Iñigo, un gran sitio para hacer "networking", y como no el reencontrarme con gente de Madrid que hacía tiempo que no veía, como Miguel Jimenez, Cristina de Microsoft, Carlos Oramas, y un largo etc…, que la verdad, es de las cosas que mejor sabor de boca me han dejado del TechEd y ya estoy deseando ir a otro evento y volver a ver a todos las caras.
Además también ha sido una oportunidad para poner caras a gente que conocía de blogs, o de los foros como Martin Woodward (un saludo Martin), Neno Loje, Roy, y más gente que de otro modo no habría podido conocer.
Y bueno, por ahora lo dejo aquí, habría muchas más cosas que contar, pero bueno, hay cosas que es mejor contar en vivo J.
|
-
Hace un tiempo puse un link al blog de Naren Datha, acerca de la creación de Custom controls, bueno, pues finalmente he estado haciendo pruebas de custom controls, y lo primero que voy a hacer, es poneros aquí unas instrucciones básicas, acerca de la instalación de los custom controls en Team Foundation Server, me voy a basar en el ejemplo de Naren, así como en información que pude ver tanto en foros, como en la web de http://www.vstsrocks.com Antes de nada una pequeña introducción acerca de lo que son los custom controls. Bueno como algunos ya sabéis, TFS nos permite extender las plantillas de los work ítems, agregando campos nuevos, hasta ahora (con el SP1), estos controles, sólo podían ser de los controles que vienen por defecto en la instalación de TFS, con el SP1, se ha incluido la posibilidad de crear nuestros propios controles, lo que nos permitiría, por ejemplo , agregar una grid, un control de imagen, un TreeView, o cualquier otro tipo de control que desarrollemos, al formulario de edición de un tipo de WorkItem. Por supuesto, lo primero que tenemos que instalar (recordad, es Beta, no instaléis en servidores de producción, solo en entornos de pruebas), es la beta del SP1 de TFS, esto hay que hacerlo tanto en el servidor, como en los clientes. Una vez instalado el SP1, y para continuar con este ejemplo hay que descargar el ejemplo de Naren, que además es un excelente ejemplo, y punto de partida, para el desarrollo de nuestros propios controles. Este ejemplo tiene, tanto la solución de VS 2005 del control de ejemplo de Naren, como la definición de un nuevo tipo de de WorkItem, y el fichero .wicc necesario para la instalación, que detallaré más adelante, antes que nada descomprimimos el fichero zip del ejemplo a un directorio. Lo primero es compilar la solución del ejemplo, para ello, abrimos la solución que contenía el zip del ejemplo, esta solución tiene referencias a dos assemblies que tenemos que cambiar para que apunten a los assemblies de TFS en nuestro ordenador, estas referencias son Microsoft.TeamFoundation.WorkItemTracking.Controls y Microsoft.VisualStudio.TeamFoundation.WorkItemTracking, estas referencias las tenemos en %ProgramFiles%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies una vez agregadas las referencias (son los ficheros .dll con el mismo nombre que el assembly), ya podemos compilar la solución. Una vez compilado el proyecto, tenemos que copiar el assembly, WitCustomControlSample.dll, del directorio de compilación, al directorio donde TFS lo irá a buscar cuando se referencie, este directorio lo crearemos dentro de una de las siguientes opciones: - El directorio de settings específicos de usuario: "C:\Documents and Settings\<NombreUsuario>\Application Data\" (para los usuarios de Windows Vista: C:\Users\<NombreUsuario>\AppData\Local), que también lo podríamos obtener en código: Environment.SpecialFolder.LocalApplicationData.
- El directorio de settings generales para todos los usuarios: "C:\Documents and Settings\All Users\Application Data\", para los usuarios de Windows Vista: C:\ProgramData\), que en código sería: Environment.SpecialFolder.CommonApplicationData.
Dentro del directorio que escojamos (yo recomendaría para la mayoría de los casos la segunda opción para que todos los usuarios lo tengan disponible), y dentro de la carpeta Microsoft, tendremos que crear un directorio que se llame Team Foundation y dentro de este otro llamado Work Item Tracking y dentro, una tercera carpeta Custom Controls, con lo que la ruta que nos queda finalmente es: c:\Documents and Settings\All Users\Application Data\Microsoft\Team Foundation\Work Item Tracking\Custom Controls Dentro de este directorio, tendremos que copiar el assembly compilado y el fichero .wicc que está en el directorio raíz del ejemplo, este fichero, contiene, en una estructura Xml, la referencia al fichero que contiene el custom control, así como el nombre completo del control. Esto hay que tener en cuenta que lo tenemos que distribuir, del mismo modo, a TODOS los clientes de nuestro Team Foundation Server. En este punto ya tenemos distribuido nuestro control a todos los clientes, ahora vamos a agregarlo a uno de nuestros tipos de WorkItem, en el eejemplo de Naren se nos proporciona una plantilla para un nuevo tipo de WorkItem, llamado Bug-CustomControl, lo tenemos en un fichero Xml del mismo nombre en el directorio raíz del ejemplo, para agregar este nuevo tipo de WorkItem a un proyecto que ya tenemos creado podemos usar el comando witimport /f Bug-CustomControl.xml /t <ServidorTFS> /p <NombredelProyectoTFS> , este comando lo tenemos que ejecutar desde la línea de comandos de Visual Studio 2005. Bueno con esto ya lo tenemos todo instalado, si hemos realizado todos los pasos correctamente, debería de funcionar, para comprobarlo abrimos el Visual Studio 2005, y en el Team Explorer, abrimos el proyecto en el que hemos agregado el nuevo tipo de WorkItem, y agregamos un nuevo WorkItem del tipo Bug-CustomControl. En la pantalla de edición del WorkItem vemos como se muestra el nuevo control (marcado con el círculo rojo): 
Cuando pulsamos el botón "…" para agregar un nuevo id se nos muestra el formulario que nos permite ejecutar una consulta contra el conjunto de WorkItems y seleccionar un WorkItem duplicado: 
Y bueno, eso es todo, si hemos llegado correctamente hasta aquí, ya tenemos el custom control correctamente instalado, enhorabuena. El siguiente paso es desarrollar un nuevo custom control, a ver si pronto tengo tiempo de publicaros otro post con un artículo al respecto, y espero que este artículo os haya ayudado.
|
-
El lunes empieza el Tech·Ed 2006 en Barcelona, y por segunda vez voy a el (estuve en el 2001), ciertamente es un evento muy interesante para ir, y obtener una perspectiva de todo lo que se cuece en el entorno de Microsoft, que es como yo lo veo, más que para aprender una u otra tecnología (en una charla no da tiempo). Así que veremos a ver que es lo que se está moviendo en Ms, por ahora, muchas charlas de Windows Vista, .NET 3.0, metodologías ágiles, mucha arquitectura, Ajax, en fin, un montón de cosas, la verdad es que se hace difícil escoger a que conferencias ir, ya que hay muchas y muy interesantes, bueno ya os iré contando si tengo tiempo durante la semana y si no a mi vuelta.
|
-
A veces nos deja de funcionar el Source Control, y nos volvemos locos intentando descubrir el porqué nos falla y uqe es lo que está ocurriendo por dentro, como hace poco le ha pasado a un amigo, cuando nos pasa esto, lo mejor, es activar las trazas de las llamadas a Source Control, lo cual es bastante sencillo y nos proporciona bastante información sobre lo que está ocurriendo por dentro del sistema, aquí os pongo unos sencillos pasos para activarlas. Lo primero que tenemos que hacer es abrir este fichero: %ProgramFiles%\Microsoft Visual Studio 8\Common7\IDE\devenv.exe.config una vez abierto, y antes del cierre de </configuration> agregamos las siguientes líneas: <appSettings>
<add key="VersionControl.EnableSoapTracing" value="false" />
</appSettings> <system.diagnostics>
<switches>
<add name="TeamFoundationSoapProxy" value="4" />
<add name="VersionControl" value="4" /> </switches>
<trace autoflush="true" indentsize="3">
<listeners>
<add name="myListener"
type="Microsoft.TeamFoundation.TeamFoundationTextWriterTraceListener,Microsoft.TeamFoundation.Common, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" initializeData="c:\traceTFS.log" />
</listeners>
</trace>
</system.diagnostics> Con estas líneas, le decimos al sistema que habilite el log de Team Foundation Server de las acciones que hacemos en cliente y lo guarde en el fichero que indicamos en initializeData, que aparece en la configuración del listener, una vez hecho esto, si tenemos abierto el Visual Studio 2005, lo cerramos y lo volvemos a abrir para que coja los cambios, y volvemos a ejecutar la acción que nos está dando problemas (CheckIn, CheckOut, etc…) y comprobamos el fichero de log para ver el problema. Otro punto por el que también podemos continuar buscando problemas, es activando las trazas de servidor (todo lo anterior lo estamos haciendo en la máquina de desarrollo), aquí os dejo un link de MSDN dónde se habla de las trazas de Team Foundation Server: http://msdn2.microsoft.com/en-us/library/ms400788(VS.80).aspx
|
-
Bueno aquí pongo un resumen, traducido, de un artículo (también reducido) bastante interesante, de cómo configurar builds incrementales en las Team Builds de Team Foundation Server, lo cual es bastante interesante.
Por supuesto, partiremos de una Team Build ya existente, aquí podéis consultar como se crean nuevas Team Builds: How to: Create a New Build Type
Lo primero que tenemos que hacer es traernos el fichero TFSBuild.proj de la build que queramos configurar, a nuestro workspace (How to: Create a Workspace, How to: Get the Source for your Team Project), este fichero lo podemos encontrar en Source Control, en la rama del proyecto al que pertenezca la build, y en la carpeta $/MiProyectoTfs/TeamBuildTypes/NombredeBuild, una vez que nos hayamos traido la última versión del fichero, lo desbloqueamos para editarlo, este fichero es un Xml, con lo que la edición es bastante sencilla, y lo más cómodo es hacerlo desde el propio entorno de Visual Studio.
Y ahora veremos lo que hay que editar en el fichero:
- Cuando Team Build comienza la ejecución de una build, borra los ficheros y las fuentes que se ha traido de la última build al directorio de trabajo intermedio, en las builds incrementales estos ficheros los necesitamos, ya que más adelante forzaremos a obtener únicamente los ficheros que han cambiado, para cambiar esto, y que no borre los ficheros que ya existen, especificaremos la propiedad SkipClean a true.
- También, en el inicio de la build, el Workspace usado por TeamBuild, se borra y se vuelve a crear, este paso también tenemos que saltarlo para poder conservar lo que ya teníamos en el WorkSpace, por tanto usaremos la propiedad SkipInitializeWorkspace y también la pondremos a true.
- Por último, lo que vamos a hacer es, no forzar a que se traiga la última versión de todos los ficheros, obteniendo únicamente los que se han modificado, esto se hace mediante la propiedad ForceGet, y en este caso la pondremos a false.
Todas estas propiedades las pondremos en un nuevo <ItemGroup> al final del fichero TFSBuild.proj, justo antes del cierre de </Project>, con lo que el final del fichero nos quedaría de este modo:
</ItemGroup>
<PropertyGroup>
<SkipClean>true</SkipClean>
<SkipInitializeWorkspace>true</SkipInitializeWorkspace>
<ForceGet>false</ForceGet>
</PropertyGroup>
</Project>
Bueno con esto quedaría configurada nuestra build para que sea incremental, como ya comentaba al principio, para hacer esto, necesitamos tener permisos en Source Control para modificar ese fichero y también tenemos que tener permisos de Administer a build y Administer workspaces (Team Foundation Server Permissions).
También os dejo aquí la Url original del artículo en inglés: How to: Configure Team Foundation Build for an Incremental Build
Espero que os haya sido de ayuda J.
|
-
Bueno pues nuevos contenidos en la zona de Visual Studio 2005, y son 10 hotfixes que acaba de hacer públicos Microsoft, para problemas relacionados con Visual Studio 2005, como ya muchos sabéis, para poder descargar estos hotfixes, antes os tenéis que registrar en Microsoft Connect (http://connect.microsoft.com) y solicitar la participación para el programa de Connect de Visual Studio 2005, el link dónde están los hotfixes es este: Hotfixes
Y aquí os pongo el listado de hotfixes, para ver si entre ellos está alguno de los que necesitáis:
| KB918642 | FIX: A .NET Framework 2.0-based application may require read/write permissions to a registry key even though the application only has to read the registry key | | KB915038 | FIX: You may receive Visual Basic compiler error messages when you are developing a Visual Basic 2005 project in Visual Studio 2005 | | KB917452 | FIX: You may experience performance issues when you use solutions that contain large Visual Basic projects in Visual Studio 2005 | | KB920805 | FIX: You may experience slow performance when you work with a Visual Basic solution that contains many projects in Visual Studio 2005 | | KB917036 | FIX: The Visual Studio 2005 IDE may corrupt the deployment files for a Web Setup Project and for a Setup Project | | KB920770 | FIX: You may receive a "Fatal error C1902" error message and a solution build may fail when you try to use the AT command or a scheduled task to automate a build of a C or C++ project in Visual Studio 2005 | | KB913377 | FIX: IntelliSense may stop working, and Visual Studio may crash, when you try to open a large Managed C++ project in Visual Studio 2005 | | KB916769 | FIX: The Visual Studio 2005 IDE stops responding when you work with a large Visual C++ .NET solution in Visual Studio 2005 | | KB912019 | FIX: You may receive an error message when you rebuild a solution and try to view a Windows Form in Design view in Visual Studio 2005. |
|
|
|
|