#Podcast – views on #GitVFS (Virtual File System), the world of the #SourceControl, and there is nothing virtual for #Hololens here (Spanish)

computer-revenge

Hello!

Another episode, this time with the excellent excuse to talk about the new “Git Virtual File System” with a great ALM expert, Luis Fraile (@lfraile); and one of the best experts on Source Control we can meet, Pablo Santos (@psluaces)

I was a little disappointed since I thought that the “Virtual” had something to do with the HoloLens, but not at the time we were talking about mono repos, git submodules and things like that. During the podcast Luis and Pablo I explained about the way that Git VFS, work on some previous experiences that tested the same way; and also about the future of Source Control tools in general.

The good thing about having to Luis and Pablo is that we are not only talking about Git, we brought a bit of history from SubVersion up to our days, we review great heroes that have fallen into oblivion as SourceForge and another couple of interesting anecdotes.

I hope you enjoy it. Podcast Link.

Greetings @ Calgary

El Bruno

References

Advertisements

#Podcast – NTN 28 – Opiniones sobre #GitVFS (Virtual File System), el mundo del #SourceControl , y que no hay nada de Virtual para #Hololens

computer-revenge

Hola !

Otro episodio, en esta ocasión con la excelente excusa de hablar del nuevo “Git Virtual File System” con un grande en temas de ALM, Luis Fraile (@lfraile); y uno de los mejores expertos sobre Source Control que podemos encontrar Pablo Santos (@psluaces)

Me tenian un poco engañado, ya que pensé que lo de “Virtual” tenía algo que ver con las HoloLens, pero no al rato estabamos hablando de mono repos, gitsubmodules y cosas por el estilo. Durante el podcast Luis y Pablo me explicaron sobre la forma en la que trabaja Git VFS, sobre algunas experiencias anteriores que probaron el mismo camino; y además sobre el futuro en general de las herramientas de Source Control.

Lo bueno de tener a Luis y a Pablo, es que no solo hablamos de Git, trajimos un poco de historia desde SubVersion hasta nuestros días, repasamos grandes héroes que han caído en el olvido como SourceForge y otro par de anécdotas interesantes.

Espero que lo disfruten. Podcast Link.

Saludos @ Calgary

El Bruno

References

 

 

#TFS – DEP Guía de Branching para Team Foundation Server y Visual Studio Team Services

Hola !

Durante estos últimos 10 años he escrito y hablado mucho sobre estrategias de Branching. Recuerdo cuando la frase con la que solía comenzar o terminar las charlas era

The worst branching strategy is not to have a branching strategy at all

Después de un tiempo, comencé a ver que algunas personas estaban sobre utilizando las ramas y se creaban estructuras que parecían un mandala. En ese punto cambié un poco mi speech intentando explicar el correcto uso de las mismas (o inclusive recomendando no usar ramas !) Fue también por esos tiempos cuando Git llegó a nuestras vidas y, de nuevo tuvimos que aprender desde cero, estrategias, modelos, etc. Toda la experiencia aprendida tuvo mucho más sentido con sistemas distribuidos.

Durante todo este tiempo hubo una guía de lectura obligatoria para el trabajo con Ramas:

The Visual Studio ALM Rangers Branching Guidance

Este conjunto de documentos no solo hablaba de ramas, también trataba temas como la gestión de dependencias con Nuget, o como comenzar con GIT viniendo de TFSVC entre otros temas. Era un punto de partida genial para trabajar con ramas en Team Foundation Server o Visual Studio Team Services.

Hoy, después de 10 años, esta guía se elimina de CodePlex. La idea es utilizar algunos artículos y entradas de MSDN como puntos de partida para el trabajo con ramas.

giphy.gif

Así que hay que comenzar por darle las gracias al equipo de Visual Studio ALM Rangers y recomendar estas entradas que ellos mismos publican en este post

Articles:
Blog posts:
Posters

Una vez más, gracias y que descanse en paz la Guía de Branching!

Saludos @ Toronto

El Bruno

References

#TFS – RIP Branching Guidance for Team Foundation Server and Visual Studio Team Services

Hi !

I’ve been writing and talking about branches and branching strategies for a long time. I remember that I usually start or end my presentations with

The worst branching strategy is not to have a branching strategy at all

After some time, I get to a point where I realize that people are “over using” branches, so I start to try to teach about the correct use of branches (or event not use branches at all!). Then Git get into our lives and everything start to make more sense.

During all this time, there was a #MustRead document, which I strongly suggest if we talk about branches:

The Visual Studio ALM Rangers Branching Guidance,

This set of documents also included topics on dependency management with Nuget, Git for TFSVC users and more. It was a great starting point to have a clear view of what we can do with branches in Team Foundation Server or Visual Studio Team Services.

Now, after 10 years, this guide is removed from Codeplex, and the main idea is to replace this guide with MSDN articles as a starting point.

giphy.gif

I’ll copy the contents proposed in the Visual Studio ALM Rangers post as new starting point for this.

Articles:
Blog posts:
Posters

So, thanks to all the work of the ALM Rangers and RIP Branching Guidance!

Greetings @ Toronto

El Bruno

References

#VS2015 – #TFS2015 is here y estas extensiones te ayudaran a trabajar mejor (#Git included!)

Hola!

Hoy es viernes de extensiones. Eso sí, como ayer se presentó oficialmente Team Foundation Server 2015, hoy voy a recomendar algunas con las que más trabajo, que ya están actualizadas a TFS2015.

TFS Source Control History Visualization

Empiezo con una idea genial. Si quieres tener una idea gráfica sobre cómo ha evolucionado una rama de tu source control esta herramienta genera un chart animado que es bastante útil. Por ejemplo, en el siguiente video podemos ver

– El proyecto comienza en Enero de este año, y participan David y Scott en el mismo.

– En el camino se suma Ana y Senthil al desarrollo

– En el 00:50 que es a mediados de Abril me sumo como Developer un tiempo al proyecto

– En el 01:10, Junio del 2015; hago un cambio brutal de código. Con un esquema de organización de código bastante diferente al original (preparando el camino para Windows 10)

TFS Source Control Explorer Extension

Empiezo con un clásico. La primera vez que escribí sobre la misma fue allá por el 2011 para TFS2010 (la última vez hace poco tiempo). Hoy muchas de las funcionalidades originales de la herramienta ya son parte de TFS2015 y VS2015. Me siguen pareciendo imprescindibles

Move to Folder, la capacidad de poder mover más de un archivo a un directorio desde el Source Control Explorer

Branch to Folder, ídem que el anterior pero trabajando con ramas

Destroy, ahora con un doble Check de validación antes de eliminar elementos

TFS Productivity Pack (Visual Studio 2015)

Esta es una de las que tengo instaladas casi todo el tiempo, ya que tiene un par de funcionalidades que uso bastante, por ejemplo>

– Seleccionar un elemento en Solution Explorer y abrir el mismo en el Source Control Explorer. No voy a comentar el jardín de workspaces en los que he tenido que poner un poco de orden, esta funcionalidad me ayuda a ver por dónde van los tiros.

– Compare to Branch, el nombre lo dice todo y la siguiente imagen es mejor aún

Esta extensión tiene un video muy bueno en https://vimeo.com/120608354

TFS Auto Shelve for Visual Studio 2015

Una idea bastante buena. Te gustaría tener un “auto save” en tus soluciones de código? Aunque en lugar de hacerlo en local, hacerlo en server?. Pues juntando el concepto de Shelve y TFS, esta extension propone una solución a este problema.

Cada N minutos, crea un Shelve con los archivos modificados. De esta manera tus “cambios” quedan auto guardados en el servidor TFS.

Visual Studio Tools for Git

Si tienes VS2015, seguramente ya las conoces. En caso contrario, deberías descargarlas y darles un vistazo.

Git Commit Formatter

Sobre esta utilidad ya escribí un post hace un tiempo (link). Esta extensión formatea los comentarios en modo 50/72 dentro del panel de Git en Visual Studio.

GitFlow for Visual Studio 2015

Cuando hablamos de TFS, algunos excluyen por defecto a GIT. Desde hace un par de versiones podemos tener repositorios basados en Git. Y claro, una herramienta como GitFlow es un #MustHave para nosotros. Jakob le hace un repaso muy interesante en este post a su herramienta

Pues ahora es el momento de ponerse a actualizar servidores TFS2013 a TFS2015.

Buen fin de semana

Saludos @ Madrid

/El Bruno

References

– Team Foundation Server 2015, now available http://blogs.msdn.com/b/somasegar/archive/2015/08/06/team-foundation-server-2015-now-available.aspx?utm_source=dlvr.it&utm_medium=twitter

– TFS Productivity Pack (Visual Studio 2015) https://visualstudiogallery.msdn.microsoft.com/03ead7e5-3680-4834-a4cb-271a2b189108

– TFS Source Control Explorer Extension https://visualstudiogallery.msdn.microsoft.com/8ad891d2-142b-4acf-b487-46db9f3bb5cf

– TFS Source Control Explorer Extension for Visual Studio 2015 https://elbruno.com/2015/04/14/vs2015-tfs-source-control-explorer-extension-for-visual-studio-2015/

– Excelente extensión para Source Control Explorer en TFS2010 https://elbruno.com/2011/03/07/visualstudiogallery-excelente-extension-para-el-source-control-explorer-de-tfs-2010/

– TFS Auto Shelve for Visual Studio 2015 https://visualstudiogallery.msdn.microsoft.com/8a8c753d-e10e-42b2-940e-2f6e8ed68d84

– TFS Source Control History Visualization https://visualstudiogallery.msdn.microsoft.com/6a8e7330-8395-4915-935f-941dc3bde29c

– GitFlow for Visual Studio 2015 https://visualstudiogallery.msdn.microsoft.com/f5ae0a1d-005f-4a09-a19c-3f46ff30400a

– Introducing GitFlow for Visual Studio http://geekswithblogs.net/jakob/archive/2015/02/12/introducing-gitflow-for-visual-studio.aspx

– Visual Studio Tools for Git https://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-40f4-8a5e-d6724bdb980c

– Git Commit Formatter https://elbruno.com/2015/06/19/vs2015-git-commit-formatter/

[#TFS] Why my Visual Studio goes so slow? It may be because the workspace is in LOCAL mode

Hello!

Now it’s nostalgic moment and time for a bit of history with Team Foundation Version Control. Since the release of TFS2012 we have the possibility to create workspaces in two modes: local and server. Local mode, is a kind of “workaround” which allows us to work comfortably offline.

Obviously you don’t have as much power as a Git repo, however is very useful if your Team Project uses TFVC. Now, the inner workings of a local Worspace relies on a Windows process that verifies the changes that exist in a directory.

The problem usually occurs when these directories contain several thousands of files and the size is closer to 1GB. At that time, Visual Studio begins to “become a very slow app“. Simple actions such as adding or refreshing a NuGet package, may take several minutes.

In reality, this is because the local workspaces were not designed to work with “many files”, the workspaces in server mode are recommended for this 2nd scenario.

Note: here we have a loophole where is hard to know if”many files may be 1 or 500 or 500000 or…”

Luckily, the solution is simple. In the edition of your workspace, you change it locally to server mode.

image

You’ll see how they disappear hidden files $tf and in addition your Visual Studio comes to life.

image

At this point also worth rethinking other options such as

-I really need a unique mapping on the root of my Source Control, or I can create mappings for only the folders that I use?

-It should be put into mode cloack some folders?

I think that with this, I know already 4 that I have made them the d to.

References:

-Far reach the local workspaces? (link)

Saludos @ La Finca

El Bruno

image image image Google

[#TFS] Porque mi Visual Studio va tan lento? puede ser por el workspace en modo LOCAL

Hola!

Ahora toca momento nostálgico y un poco de historia con Team Foundation Version Control. Desde la versión de TFS2012 tenemos la posibilidad de crear workspaces en modo local y server. El modo local, es una especie de “ñapa” que nos permite trabajar de una forma cómoda sin conexión.

Obviamente que no tiene tanta potencia como un repo de Git, sin embargo es bastante útil si tu Team Project utiliza TFVC. Ahora bien, el funcionamiento interno de un Worspace local se basa en un proceso de Windows que verifica los cambios que existen en un directorio.

El problema suele darse cuando estos directorios contienen varios millares de archivos y llegan o pasan el 1GB de tamaño. En ese momento, Visual Studio comienza a “ponerse lento”. Acciones tan simples como agregar o refrescar un paquete NuGet, puede tardar varios minutos.

En realidad esto es porque los workspaces locales no fueron pensado para trabajar con “muchos archivos”, para este 2do caso se recomiendan los workspaces en modo server.

Nota: aquí tenemos un vacío legal donde “muchos archivos, puede ser 1 o 500 o 500000 o …

Por suerte, la solución es más que simple. En la edición de tu workspace lo cambias de modo local a modo server.

image

Verás como desaparecen los archivos ocultos $tf y como además tu Visual Studio vuelve a la vida.

image

En este punto también vale la pena replantearse otras opciones como por ejemplo

– Realmente necesito un único mapeo en la raíz de mi Source Control, o puedo crear mappings solo para los folders que utilizo?

– Debería poner en modo cloack algunos folders?

Creo que con esto, ya conozco a 4 a los que les he alegrado el día.

Referencias:

– Hasta donde llegan los workspaces locales? (link)

Saludos @ Home

El Bruno

image image image Google

[#ALMRANGERS] Version Control Guide V3 (antes conocida como Branching and Merging Guide)

Hola!

 

Después de darles bastantes vueltas al asunto, los rangers han liberado una nueva versión de la guía de Branching y Merginng, o con su nuevo nombre: “Version Control Guie V3”. Est guía en realidad es un paso adelante en el camino de una filosofía no basada en regla sino en recomendaciones y buenas prácticas, luego cada equipo es lo suficientemente maduro para elegir el mejor camino.

Por ejemplo, ¿recuerdas mi post sobre no usar ramas en tu equipo de desarrollo? Lamentablemente eso fue lo que muchos entendieron del post, cuando en realidad el objetivo del post era intentar simpliicar el trabajo de un equipo implementando solo aquello que de valor a la solución sobre la que se trabaja … que me enrollo. Pues mira como empieza esta guía.

image

Impresionante! la guía recomienda comenzar sin una estrategia de branching, a partir de allí la solución emergerá con el tiempo.

Joyas como estas tiene varias dentro, la verdad es que RECOMIENDO LEER LA GUÍA, ahora se ha convertido en un excelente ejercicio para saber si vamos por el buen camino.

Descarga: http://vsarbranchingguide.codeplex.com/

Saludos @ Camino a Niza

El Bruno

imageimageimageGoogle

[#TFS] Is Microsoft going to leave TFSVC for GIT? NO (let me put this more clearer: NO!)

Hello!

Brian Harry didn’t put the source of this confusion, so I wont do the same. Brian Harry maked this clear, he explained that Microsoft and Visual Studio and the Team Foundation team will continue betting and working for the model of centralized Souce Control that Team Foundation provides.

A few days ago a small dilemma on Twitter was armed when someone alleged that, speaking with people at Microsoft, he had confirrmation on no more support for TFSVC and all will be moved to GIT. This was very out of scope, and much. I told you how to make migration a few days ago, using GIT-TF, and Brian also makes it clear there are some features that are not available in an environment with GIT and yes for TFSVC, the main idea is to get the best experience for a developer .

And the noise level was fairly high, as to which Brian Harry has to make clear the response in a post: plan to abandon Microsoft TFSVC for GIT? > > Not.

Source: http://blogs.msdn.com/b/bharry/archive/2014/04/14/is-microsoft-abandoning-tfvc-in-favor-of-git.aspx

Saludos @ Home

El Bruno

image image image Google

[#ALM] Why not use branches or not do something not useful in your app devs

Hello!

Since there are several people who have been amazed with my statement on not to use branches, I better explain this a little more. To do this I’ll share a story which happened to a cousin brother of the brother-in-law of a neighbor, called Paco.

-Paco had a request Milagros (his customer) to make an iOS app for a 15 days promotion of a beauty cream for hands. This promotion started in little over 2 months.

-In this type of projects Paco usually worked with Lucia, she is an UX expert, and also knew how to manage iOS apps

-Paco (cool!) is a Xamarin developer, so taking advantage of Visual Studio Online, Paco gave permissions to Lucia and Milagros in a VSOnline instance

-Paco coordinated with Lucia and Milagros to work in 2 sprints, each one will be a 3 week duration. He also is defining this time box thinking in the leap between Sprints and possible changes. At the end they all agreed on this model.

-Paco create the basic elements and they started to use TFS as repository, work was started!.

-After of the 2nd Sprint, Milagros was Happy Happy with the application, so she give a GO to Paco and Lucia to coordinate with the Marketing team for the publication and promotion of the application.

So here ends the story of Milagros, Lucia and Paco and I asked myself…

Where are the branches? Maybe nowhere, Paco never had the need to use branches; SO HE DIDN’T CREATED!

Caution! I do not mean that create and use branches is bad. For sure Paco when he was testing or making changes, had a local Git repo with his changes, tests, branches, etc; but why does he have to create a branch to share with Lucia and Milagros?

This bring us to the bases of the branch managing: if we work in an app will not have later versions, why do you have to create a DEV – MAIN – RELEASES schema?  At this point there is no idea that the application will have continuity so … what for?.

One of the excellent features of TFS and GIT is that anytime you can create a branch and start working with branches. So when the the scenario request this feature, you can start and define a scheme of branches.

Proably you think that this sample is kind of crazy (It is!). I’m trying to share a message in the background: not add XYZ to you apps when you are creating applications, if XYZ does not add value to the application that you are creating!. For example, why create an app that supports multiple cultures? if you know that that is not necessary.

If when a Sprint ends, the PBIs changes, get new changes; PO puts on the table new features that require changes in the architecture or the way of working… don’t feel bad, the architecture will emerge naturally to accommodate those changes.

What you should not do is to think in advance in scenarios that do not apply and that only complicate your application. The phrase that sums up all this, leaves the app architecture and the app itself to emerge and to adapt with the same time as the business context of the app, … and obviously relies on your team and let the team to decide.

Note: If a dev writes applications regardless of the bases of a good app developer, as for example a correct exceptions management, it is to cut off his fingers. Once a developer replied “I did an application that handles exceptions correctly because the PO not asked for this “… This serves to measure the quality of a person and also is a good opportunity to test the edge of a Katana.

Saludos @ Home

El Bruno

image image image Google