Mostrando entradas con la etiqueta Git. Mostrar todas las entradas
Mostrando entradas con la etiqueta Git. Mostrar todas las entradas
viernes, 30 de mayo de 2014
by Ernesto
Antes cuando desarrollabas SW y se te planteaba el versionar tu código fuente algunos no tenían idea de lo que se hablaba, y en el otro extremo solo había dos opciones ampliamente usadas: SourceSafe y CVS, aparte claro de opciones chapuceras como: diskettes, carpetas fechadas compartidas y USB.
Ahora mucha agua ha corrido bajo los puentes, así que el que no versiona SW es porque ha vivido aislado de la realidad, o porque de alguna manera no ve la justificación económica de ello (hace poco me comentaron que una entidad crediticia sigue manejando sus desarrollos con carpetas fechadas y comprimidas y recién iban a analizar la viabilidad de usar SVN), por lo que el problema en estos momentos es decidir que repositorio usar y las implicancias de su decisión.
En este momento me pueden decir "¡Pero tu usas TFS, ya no tienes que decidir!", pues la verdad que no, hasta el 2010 no había que tomar muchas decisiones, pero en el momento actual también toca decidir como es que vamos a usar TFS, entonces.. vamos a ello, repasemos el escenario.
En este momento al crear un proyecto en TFS/VSO tenemos dos opciones de mecanismo de control de versiones:
TFVC: El mecanismo tradicional de TFS de toda la vida, heredando terminología de SourceSafe como "check-in" "check-out", pero mucho mas potente, todo almacenado en SQL Server, permitiendo gestión de branches y merges, aparte claro esta de la integración de tus changesets con una actividad determinada. Su modelo es Centralizado al igual que Subversión por ejemplo, con todas las implicancias que eso trae, que no vamos a discutir ahora.
Lo curioso es que si optamos por usar esta modalidad hay que tener en cuenta un detalle adicional: el tipo de Workspace ya que hasta TFS 2010 solo había el workspace en servidor, vale decir que el servidor de TFS llevaba un seguimiento de cual es el estado de cada una de las maquinas que se conectaban al repositorio, lo cual debemos reconocer no funcionaba muy bien, llegando al extremo de que en algún momento el usuario sabia que no estaba sincronizado, pero el servidor insistía en que no tu workspace esta bien, y arreglar eso, complicado.
Con los workspace locales, esos problemas ya no existen, aparte de que proveen una mayor flexibilidad para trabajar sin problemas cuando el servidor esta desconectado, pero de eso nos cuenta con mas detalle El Bruno, solo debo añadir que si se opta por TFVC solo hay un escenario en el cual tendría sentido usar workspace en el servidor: cuando tu IDE aun es VS 2010 o anterior, en cualquier caso es workspace locales, ahh la decisión se hace en el IDE no en el servidor.
Git: ya hemos hablado anteriormente de este recién llegado a las plataformas Microsoft, y creo sinceramente que debemos probarlo, intentar usarlo en nuestros proyectos, pues los DVCS han llegado para quedarse y Git ya es casi el estandar de facto, proveyendo muchas ventajas; dicho esto debemos ser conscientes que a la fecha (si alguien lee esto 2 años despues puede que se ria), si bien Microsoft ha integrado totalmente el "protocolo" backend de Git en sus productos aun no ha terminado de pulirlo en cuanto a interfaz (quiero creer que la próxima versión de VS tendrá una interfaz para Git que rivalice con SourceTree) y que de momento no podemos usar una herramienta tan potente como los Code Review integrados, a los cuales me acostumbre rápidamente cuando use por primera vez TFS 2012, ni tampoco los Gated Check in a la hora de hacer Integración continua (en breve: esta modalidad permite que un cambio no se añade al repositorio si la Build falla).
Conclusión: si no tienes una demanda muy fuerte de hacer uso de CodeReview o Gated Check In, usa Git, pero de la mano ve aprendiendo los comandos aun no disponibles desde el IDE, pues seran necesarios para sacarle el jugo. En otro caso (el Code Review si que puede ser un deal breaker en muchos casos) no temer y usar los workspace locales con TFVC.
A ver cual es la situación de aquí a un año, probablemente nuestro flujo cambie para entonces.
Ahora mucha agua ha corrido bajo los puentes, así que el que no versiona SW es porque ha vivido aislado de la realidad, o porque de alguna manera no ve la justificación económica de ello (hace poco me comentaron que una entidad crediticia sigue manejando sus desarrollos con carpetas fechadas y comprimidas y recién iban a analizar la viabilidad de usar SVN), por lo que el problema en estos momentos es decidir que repositorio usar y las implicancias de su decisión.
En este momento me pueden decir "¡Pero tu usas TFS, ya no tienes que decidir!", pues la verdad que no, hasta el 2010 no había que tomar muchas decisiones, pero en el momento actual también toca decidir como es que vamos a usar TFS, entonces.. vamos a ello, repasemos el escenario.
En este momento al crear un proyecto en TFS/VSO tenemos dos opciones de mecanismo de control de versiones:
TFVC: El mecanismo tradicional de TFS de toda la vida, heredando terminología de SourceSafe como "check-in" "check-out", pero mucho mas potente, todo almacenado en SQL Server, permitiendo gestión de branches y merges, aparte claro esta de la integración de tus changesets con una actividad determinada. Su modelo es Centralizado al igual que Subversión por ejemplo, con todas las implicancias que eso trae, que no vamos a discutir ahora.
Lo curioso es que si optamos por usar esta modalidad hay que tener en cuenta un detalle adicional: el tipo de Workspace ya que hasta TFS 2010 solo había el workspace en servidor, vale decir que el servidor de TFS llevaba un seguimiento de cual es el estado de cada una de las maquinas que se conectaban al repositorio, lo cual debemos reconocer no funcionaba muy bien, llegando al extremo de que en algún momento el usuario sabia que no estaba sincronizado, pero el servidor insistía en que no tu workspace esta bien, y arreglar eso, complicado.
Con los workspace locales, esos problemas ya no existen, aparte de que proveen una mayor flexibilidad para trabajar sin problemas cuando el servidor esta desconectado, pero de eso nos cuenta con mas detalle El Bruno, solo debo añadir que si se opta por TFVC solo hay un escenario en el cual tendría sentido usar workspace en el servidor: cuando tu IDE aun es VS 2010 o anterior, en cualquier caso es workspace locales, ahh la decisión se hace en el IDE no en el servidor.
Git: ya hemos hablado anteriormente de este recién llegado a las plataformas Microsoft, y creo sinceramente que debemos probarlo, intentar usarlo en nuestros proyectos, pues los DVCS han llegado para quedarse y Git ya es casi el estandar de facto, proveyendo muchas ventajas; dicho esto debemos ser conscientes que a la fecha (si alguien lee esto 2 años despues puede que se ria), si bien Microsoft ha integrado totalmente el "protocolo" backend de Git en sus productos aun no ha terminado de pulirlo en cuanto a interfaz (quiero creer que la próxima versión de VS tendrá una interfaz para Git que rivalice con SourceTree) y que de momento no podemos usar una herramienta tan potente como los Code Review integrados, a los cuales me acostumbre rápidamente cuando use por primera vez TFS 2012, ni tampoco los Gated Check in a la hora de hacer Integración continua (en breve: esta modalidad permite que un cambio no se añade al repositorio si la Build falla).
Conclusión: si no tienes una demanda muy fuerte de hacer uso de CodeReview o Gated Check In, usa Git, pero de la mano ve aprendiendo los comandos aun no disponibles desde el IDE, pues seran necesarios para sacarle el jugo. En otro caso (el Code Review si que puede ser un deal breaker en muchos casos) no temer y usar los workspace locales con TFVC.
A ver cual es la situación de aquí a un año, probablemente nuestro flujo cambie para entonces.
viernes, 20 de diciembre de 2013
by Ernesto
En los últimos meses quienes trabajamos con tecnologías Microsoft, especialmente con TFS hemos sido arrastrados a una voragine de cambios que empezó con la herramienta Git-TF que permitia cierto grado de sincronización entre repositorios Git y TFS, pero eso fue solo el primer paso, luego vino el soporte nativo de Git en Team Foundation Service Visual Studio Online, el soporte a repositorios Git en un update a Visual Studio 2012, y ahora con Visual Studio 2013 y TFS 2013 la total integración entre Builds y repositorios Git.
Así que en los últimos meses hemos tenido que acercarnos a Git y experimentar con el, en ese sentido como primer punto de partida sugiero revisar los articulos de Eduard sobre el tema, pues nos permiten acercarnos a esta plataforma desde una perspectiva de quien ha trabajado en modo centralizado toda la vida.
Ahora bien, nuestro principal interés es tratar de seguir usando nuestras herramientas de TFS de toda la vida pero vinculado al nuevo repositorio, la buena noticia es que si, podemos tener lo mejor de ambos mundos, pero hay que tener unas consideraciones a fin de sacarle el máximo partido a nuestra nueva herramienta (Si aun dudas en usar Git, mejor lee a El Bruno) asi que aqui vamos:
Si tienes una duda no dejes de comentar y preguntarme.
Así que en los últimos meses hemos tenido que acercarnos a Git y experimentar con el, en ese sentido como primer punto de partida sugiero revisar los articulos de Eduard sobre el tema, pues nos permiten acercarnos a esta plataforma desde una perspectiva de quien ha trabajado en modo centralizado toda la vida.
Ahora bien, nuestro principal interés es tratar de seguir usando nuestras herramientas de TFS de toda la vida pero vinculado al nuevo repositorio, la buena noticia es que si, podemos tener lo mejor de ambos mundos, pero hay que tener unas consideraciones a fin de sacarle el máximo partido a nuestra nueva herramienta (Si aun dudas en usar Git, mejor lee a El Bruno) asi que aqui vamos:
- Los repositorios Git de Microsoft (TFS on premise y Visual Studio Online) cumplen totalmente las especificaciones de Git, en ese sentido puedes conectarte a tu repositorio no solo desde Visual Studio 2013 sino también desde una herramienta como SourceTree.
- El soporte de Visual Studio para los flujos de trabajo de Git (stash, rebase, etc) que tanto gustan a los veteranos de Git aun esta en progreso, en ese sentido nunca viene de mas poder tener un SourceTree a la mano configurado para conectarse a nuestro repositorio, si, funciona perfectamente.
- Cuando te conectas a un Team Project con Git, se te ofrece la opción de clonar el repositorio a fin de poder empezar a trabajar, lo cual crea un repositorio Git local, y dentro de este repositorio el archivo \.git\config queda apuntando a la ruta del repositorio online (en el caso de VSO la ruta tiene la forma de https://midominio.visualstudio.com/DefaultCollection/_git/MiTeamProject), todo bien hasta ahi, pero si por alguna razón queremos cambiar de repositorio remoto tendremos que recurrir a la edición manual del archivo en cuestión (o usar SourceTree).
- Ya que hablo de usar linea de comandos y/o otra herramienta cabe indicar que hay que configurar nuestra cuenta de VSO para poder conectarse transparentemente a entornos diferentes a Visual Studio, para ello nos vamos a la esquina superior derecha de nuestro portal de VSO, elegimos nuestro nombre Le damos a "My profile"
y veremos que tenemos un nombre de usuario primario en formato "email" que es el que usamos para conectarnos al portal de VSO, pues bien lo que toca es crear un nombre de usuario secundario (que NO debe tener formato email) el cual sera el que usemos cuando intentemos conectarnos con linea de comandos o SourceTree.
- Como mencionaba lineas arriba Visual Studio reconoce directamente la configuración Git estandar, en ese sentido es perfectamente posible agregar un repositorio remoto adicional a nuestro archivo \.git\config (en este caso un repositorio GitHub), o via SourceTree: quedando de la siguiente manera:
[core]
bare = false
repositoryformatversion = 0
filemode = false
logallrefupdates = true
symlinks = false
ignorecase = true
[remote "origin"]
url = https://xxxxxxx.visualstudio.com/defaultcollection/_git/Applicat%C3%B3n
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[remote "Github"]
url = https://github.com/fisica3/Applicaton
fetch = +refs/heads/*:refs/remotes/Github/*
Ocurrido esto, cuando sincronizemos nuestros cambios desde Visual Studio, se efectuara una sincronización simultanea a ambos repositorios remotos, lo cual puede venir muy bien en ciertos entornos, pero lamentablemente por ahora no tendremos la opción de elegir cuando hacer los sync por separado, seran en simultaneo. - Otro detalle de cuando tenemos mas de un repositorio remoto configurado en nuestro repositorio local: hay que tener cuidado pues si tenemos alguna Build Definition basada en Integración Continua esta puede no dispararse, tratare de encontrar una solución para evitar este problema, pero de momento hay esa pequeña limitante.
Si tienes una duda no dejes de comentar y preguntarme.
viernes, 1 de febrero de 2013
by Ernesto
Si algo se me ha pasado es compartir esta presentación con la que introduje Team Foundation Service en el ultimo Agile Open Lima, así como a algunos compañeros de trabajo
En este tiempo lo que ha cambiado es que TFS ya es RTM, por lo cual ahora si que se tienen los planes de licenciamiento, y algo muy interesante, ahora esta integrado con GIT. No queda sino animarlos a probar Team Foundation Service, el cual es gratis para equipos de hasta 5 personas y por supuesto seguir los blogs de El Bruno y Jersson, que siempre nos estan informando novedades sobre esta potente herramienta.
En este tiempo lo que ha cambiado es que TFS ya es RTM, por lo cual ahora si que se tienen los planes de licenciamiento, y algo muy interesante, ahora esta integrado con GIT. No queda sino animarlos a probar Team Foundation Service, el cual es gratis para equipos de hasta 5 personas y por supuesto seguir los blogs de El Bruno y Jersson, que siempre nos estan informando novedades sobre esta potente herramienta.
About Me
- Ernesto
- Egresado de Ingenieria Informatica de la PUCP. Master en Direccion de Sistemas y Tecnologias de la Informacion por el Instituto de Empresa. MCSD,MCSD.NET.
Technorati
