Páginas

Mostrando las entradas con la etiqueta build. Mostrar todas las entradas
Mostrando las entradas con la etiqueta build. Mostrar todas las entradas

Aplicando practicas modernas de desarrollo a proyectos hosteados en TFS / legacy

Si me preguntan cuáles son las prácticas que deberían aplicarse a un proyecto de desarrollo de software hoy en día, sin importar su tamaño, yo rápidamente respondería:

  1. Utilización de containers para levantar entornos de trabajo. 
  2. Código versionado en herramienta moderna. Hoy en día el estandar de la industria es GIT
  3. Aplicar refactorización a ese código.
  4. Que ese código tenga una buena cobertura.
  5. Integrar las modificaciones al código continuamente y que un server compile el código y verifique que no haya roto nada.
  6. Hace un análisis de mi código que me asegure que sigo standard, que me de métricas sobre mi código, etc.
  7. Test automatizados
  8. Delivery / deploy automatizado y continuo

Y si me apuran aún mas, respondo "como mínimo integrar las modificaciones al código continuamente y que un server compile el código y verifique que no haya roto nada" aunque a veces en mucho pedir.

Ahora, déjenme que les cuente una historia a ver si les suena familiar.

Este año me sume a trabajar a un equipo que desarrollaba una aplicación web para un cierto cliente. El código ha sido tocado por mucha gente, de distintos senorities y ni hablar de los errores inexplicables que se encuentran  o del código dulpicado que hay.

El código fuente del proyecto estaba hosteado en el TFS del cliente con un Jenkins build server y deploy server (que no controlamos). Este build server no está configurado como integración continua

El Jenkins ejecuta un análisis de código con SonarQube aunque tampoco tenemos acceso. El acceso a los análisis de SonarQube nos serviría para tener métricas de nuestro código, ver como evoluciona / involuciona y ayudaría a los desarrolladores más juniors a que aprendan y mejoren.

A pesar que no hacemos TDD (y que la arquitectura de app no lo permite), hay algunos unit test escritos que nunca se ejecutan.

Conclusión: casi ninguno de los puntos nombrados al principio se cumplen.

¿Seguimos desarrollando así? la respuesta es muy simple NOOOOOOOOOOOO
¿Qué opciones tengo? ahi la cosa es más compleja pero nada complicado gracias a la cantidad de herramientas con las que contamos hoy en día:

  1. Utilizar un GIT controlado por nosotros y luego integremos los cambios en el TFS. Esto es facil de hacer con GIT TFS, un comando que nos permite clonar en un repo GIT el código fuente hosteado en un TFS y tener una comunicación bidireccional. Una vez que controlamos el repo, el resto es más facil!
  2. Como integración continua podemos usar algo como Azure DevOPS para que buildee el código continuamente y ejecute las tareas que necesitamos:

Ya con el hecho de usar GIT TFS y Azure DevOPS junto a los Unit Test y SonarQube logramos tener mucho más de lo que originalmente teníamos y hemos mejorado notablemente nuestra calidad.

Configure Xamarin.iOs build on TFS


Build agent

First of all, you need to install the cross platform build and release agent for Team Services and Team Foundation Server 2015 and beyond on a mac.

I think the easiest way to do that is to you MacInACloud service (https://support.macincloud.com/support/solutions/articles/8000016614-getting-started-with-the-macincloud-vsts-build-agent-plan) but if you don't want to pay for the service and have a Mac, you must install it there.

Install Prequisites

First, ensure you have the necessary OSX (macOs) system prequisites (https://github.com/Microsoft/vsts-agent/blob/master/docs/start/envosx.md) - basically OpenSSL, Git and other stuff. You will need BREW (http://brew.sh/), so visit Brew website for install instructions

Installing OpenSLL, if the following lines doesn't work, check the installed version and use it instead of 1.0.0

ln -s /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib /usr/local/lib/
ln -s /usr/local/opt/openssl/lib/libssl.1.0.0.dylib /usr/local/lib

Deploy an agent on OSX

After installing all prequisites, you need to install the agent.


You must configure it and run it (don't forget to run it LOL), pretty straightforward.

If everything is OK you shoul see you Build Agent is green, if it is red, then something went wrong

image

Creating the build

Now you have go to your TFS and create a new Xamarin.iOS. To create it follow these instructions https://www.visualstudio.com/docs/build/apps/mobile/xamarin

Troubleshooting

If you have any issues, visit these url for troubleshooting info:

Can't connect to TFS when configuring the agent

User permissions

If you face issues with user permissions:
  1. Creation issues: To create the agent, the user must be part of "Agent Queue Administrator"
  2. Execution issues "Tfs2015 Build agent error: Access denied: xxxxx\yyyyy needs Listen permissions for pool zzzzz to perform the action": To run the agent, the user must be part of "Agent Queue Users" and not "Agent Queue Administrator". This is the (http://www.codewrecks.com/blog/index.php/2015/05/09/tfs2015-build-agent-error-access-denied-xxxxxyyyyy-needs-listen-permissions-for-pool-zzzzz-to-perform-the-action/)
  3. Can't select a build queue during build definition - TFS 2015 Build’s Queue is Empty: your user doesn't have permissions to execute the queue and needs to be part of "Agent Queue Users" (https://lajak.wordpress.com/2016/03/24/fix-tfs-2015-builds-queue-is-empty/)
  4. I use Team Foundation Server on-premises and I don't see some of these features. Why not? Some of these features are available only on Visual Studio Team Services and not yet available on-premises. Some features are available on-premises if you have upgraded to the latest version of TFS. Check the available features on each version here https://www.visualstudio.com/de-de/docs/build/define/build (eg: at the time of writting this post "Xamarin component restore" is only available on Team Services)