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:
• Unit Tests
• Análisis SonarQube (Instalar SonarQube en una VM en Azure https://bitnami.com/stack/sonarqube/cloud/azure)  
• Integración de código nuevamente en TFS

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.

Learning GraphQL using NodeJS

Motivation and background

Trying to learn GraphQL (https://graphql.org/) I found the "Code Challenge for Scoutbase" (https://medium.com/scoutbase/we-are-hiring-javascript-developers-e7833762a40d).

The drawback of the challenge was that I've never done a nodejs app but as I knew JS and I have many many years of experience building web apps (mainly .net) and I love to learn new thing, I decided to go for it!

So I went from nothing (0) using NodeJs, GraphQL, Sequelize, PostgreSQL to this in just a couple of hours.

Here you have the code (it's an MVP or a prototype) and the code challenge description
https://github.com/vackup/scoutbase-code-challenge-back-end/

The app is deployed to Azure through Azure pipelines.



The app is using an Azure Database for PostgreSQL.

You can access the Graphql playground here https://scoutbase-code-challenge-backend.azurewebsites.net/graphql

Helpful links

• Getting a new node project started with npm · Mark Wolfe's Blog
• Node.js Everywhere with Environment Variables! - Node.js Collection - Medium
• Setup PostgreSQL on Windows with Docker – Eric L. Anderson
• Debugging Node.js applications on Azure App Services Linux/containers | Microsoft Azure Open Source Development Support Team Blog
• How to setup Express.js in Node.js - RWieruch
• GraphQL Server Tutorial with Apollo Server and Express - RWieruch
• GraphQL Context – Patrick Desjardins' Blog
• How to setup a TypeScript, NodeJS, Express Apollo Server to easy debugging with VsCode – Patrick Desjardins' Blog
• Install Apollo Server to host a GraphQL service – Patrick Desjardins' Blog
• Authentication and Authorization in GraphQL (and how GraphQL-Modules can help)
• UpToSkill – Custom Scalars in GraphQL
• Setting up a Node development environment - Aprende sobre desarrollo web | MDN

Back-end task of Code Challenge for Scoutbase

This task is for demonstrating your understanding of HTTP, GraphQL, Node.js and general API practices.

Instructions:

1. Implement a Node.js-based server with raw http, Koa or Express.
2. Add a /graphql endpoint serving the apollo-server or any other GraphQL implementation.
3. Schema must be able to return proper response for the following public query:
• { movies { title year rating actors { name birthday country directors { name birthday country } } } }
4. Add support for the following mutation:
• mutation createUser($username: String, $password: String) { createUser(username: $username, password: $password) { token user { id name } } }
5. To expand on the number four, add a mutation-based authentication that accepts:
• mutation login($username: String, $password: String) { login(username: $username, password: $password) { token user { id name } } }
6. Authenticated users may request additional fields for the query used earlier. New scoutbase_rating field must return the a random string between 5.0-9.0:
• { movies { scoutbase_rating title year rating actors { name birthday country directors { name birthday country } } } }
7. /graphql must be accessible for external clients.
8. End.