Github Actions + Rails

En este post quería mostrarles un poco de la potencia y lo fácil que es usar Github Actions, pero primero…

¿Qué es Github Actions?

Si leemos lo que dice la web nos encontramos con esto:

Automatiza, personaliza y ejecuta tus flujos de trabajo de desarrollo de software directamente en tu repositorio con GitHub Actions. Puedes descubrir, crear y compartir acciones para realizar cualquier trabajo que quieras, incluido CI/CD, y combinar acciones en un flujo de trabajo completamente personalizado.

Pagina de Github Actions

En definitiva nos permite automatizar cosas en nuestro Repo. No solo continuous integration, sino manejo de issues en el repo, darle la bienvenida a los nuevos usuarios, y muchísimas cosas más.

Hubo un hackaton creado en Dev.to para que los devs puedan crear acciones en diferentes categorías. Algunas de las cosas que surgieron fueron muy locas.

Se pueden hacer mil cosas, desde jugar a un juego a mandar un mensaje por telegram. Nosotros lo vamos a usar para tener un ambiente de CI en nuestra aplicación Rails.

¿Qué vamos a hacer?

Vamos a partir de un proyecto de Rails que hice hace algún tiempo que se llama Beer API.

Esta aplicación es una Api muy sencilla que hice para hacer algunas pruebas de diferentes frontends, con diferentes tecnologías, usando la misma API.

Este proyecto tiene corriendo algunos tests de Rspec.

Workflow en Github Actions

Lo primero que tenemos que hacer en nuestro proyecto de Github es hacer click en Actions.

Ahora buscamos en la sección Continuous integration workflows la acción que más nos convenga. En este caso Ruby y hacemos click en Set up this workflow.

Esto nos abre un editor con un archivo pre-creado.

Modifiquemos el workflow

	name: CI
	on:
	push:
	branches: [ main ]
	pull_request:
	branches: [ main ]
	jobs:
	rspec:
	name: Rspec
	runs-on: ubuntu-latest
	services:
	postgres:
	image: postgres:11
	env:
	POSTGRES_USER: postgres
	POSTGRES_PASSWORD: postgres
	POSTGRES_DB: postgres
	ports:
	– 5432:5432
	options: –health-cmd pg_isready –health-interval 10s –health-timeout 5s –health-retries 5
	env:
	POSTGRES_HOST: 127.0.0.1
	steps:
	– uses: actions/checkout@v2
	– uses: actions/setup-ruby@v1
	with:
	ruby-version: 2.7.2
	– name: Install Dependencies
	run: |
	gem install bundler
	bundle install
	– name: Run Migrations
	run: bundle exec rails db:create db:migrate RAILS_ENV=test
	– name: Run Rspec
	run: bundle exec rspec

view raw main.yml hosted with ❤ by GitHub

Como yo no necesitaba la estrategia de Matrix, para probar esta api en múltiples versiones de Ruby, borre todo lo relacionado a eso y solo deje una Ruby 2.7.

Lo primero que hice fue cambiar el name por CI (acronimo para Continuous Integration).

Luego en la sección de jobs cree uno que se llama rspec, que tiene el servicio de postgres. Esto lo que va a hacer es levantar un container con Postgres, para que desde el container donde se ejecutan los tests pueda usarlo y ejecutarlos usando una base de datos.

Agregué una sección de options, esto sirve para que los tests ejecuten recién cuando el servicio de la base de datos esté funcionando y no nos fallen los tests porque no se puede conectar. Esto es una configuración que es necesaria para evitar fallas del CI aleatorias.

Luego en la sección env, configuré el host donde va a correr postgres, en este caso 127.0.0.1. En esto tuve algún problema, si no lo ponia o si ponia localhost, por eso les recomiendo agregarlo.

Por último la sección de steps, los primeros son los que vienen por default (el de setup de ruby es un poco distinto porque no uso la matrix) y después agregue:

• Install Dependencies: Ejecuto bundle install para traer todas las gemas que necesito.
• Run Migrations: Creo la base de datos y ejecuto las migraciones
• Run rspec: Ejecuto los tests.

Más Jobs

En este mismo workflow yo podría poner múltiples jobs, en el caso de Beer API, agregué un job que corre Rubocop, para el estilo del código.

Para eso en la sección de jobs agregue uno nuevo que se llama rubocop con la siguiente configuración.

	jobs:
	rubocop:
	name: Rubocop
	runs-on: ubuntu-18.04
	steps:
	– uses: actions/checkout@v1
	– uses: actions/setup-ruby@v1
	with:
	ruby-version: 2.7.2
	– name: Install Rubocop
	run: |
	gem install rubocop
	gem install rubocop-rails
	gem install rubocop-rspec
	– name: Run Rubocop
	run: rubocop

view raw main.yml hosted with ❤ by GitHub

Para verlo funcionando solo nos queda hacer commit de nuestro archivo de configuración y listo.

Ahora cada vez que se abra un Pull Request, o haga un Merge a main, se van a ejecutar los tests y además el chequeo estático de la sintaxis.

Espero que les sirva para tener mejores prácticas en sus proyectos.

Nos leemos.

Introducción a Angular 2

Hace unas semanas estuve dando, Junto con @nicotourne,  un curso de Introducción a Angular en la UNICEN como propuesta de seminario para la Tecnicatura Universitaria en Desarrollo de Aplicaciones Informáticas.

El curso estuvo bueno y tuvimos  una muy buena retrospectiva al terminarlo, como para poder mejorar en la próxima iteración.

La idea de este post es comentar algunos highlights que descubrí en clases y compartir el material.

Alumnos del Curso

Material

El material esta basado en un ejemplo de una app de una Cervecería. La home page tiene una lista de cervezas y un carrito de compras. Durante las clases fuimos construyendo la lista de cervezas, explicando a la par los conceptos de Angular.

Los temas fueron:

• Introducción
• Components
• Directives & Pipes
• Mocks, Models & Property Binding
• Event binding & 2 Ways Data Binding
• Services & Dependency Injection
• Routing
• Communication Between Components

Algo que sumamos, es un branch de cada slide en el repositorio de GitHub para que los alumnos puedan ver qué cambios se van haciendo con cada nuevo concepto.

También durante la clase @nicotourne, fue aportando todo su conocimiento de Angular en producción, dando tips de buenas prácticas y detalles a tener en cuenta cuando hacemos una app un poco mas grande.

Trabajo Final

El trabajo fue agregar algunas features al proyecto:

• Filtrado en la tabla de cervezas.
• Hacer un componente que consuma la API de AccuWeather y muestre el clima de Tandil.
• Agregar un botón que guarde la compra en Firebase
• Hacer un componente de Contacto que guarde los mensajes en Firebase.
• Agregar la opción de Agregar Cervezas a la lista.

Highlights

La dinámica de la clase

Dar clases, siguiendo las slides, codeando la solución en vivo en el proyector y que los alumnos puedan seguirlo e ir haciendolo en sus computadoras.

Esto nos permite tener feedback de los alumnos en el momento, validar si se entendió el concepto o no. En base a esto podemos volver a explicar o avanzar con el siguiente concepto.

Branches con las soluciones

En la retrospectiva surgió, como algo muy bueno, poder acceder a solo la porción de código de ese juego de slides. Los alumnos pudieron usarlo para encontrar más rápidamente la solución a los problemas que les surgían en el trabajo final.

Trabajo final, Fork y Pull Requests

Para el trabajo final, los alumnos tuvieron que hacer un Fork del repositorio del curso y al terminar postear el PR.

Esto nos ayudo a corregir mas rápido, y poder agregar comentarios en el mismo código, aprovechando esto como una instancia más de aprendizaje.

Firebase

Wow! Que buenas cosas que están haciendo con Firebase en Google. Agregarlo al curso fue una excusa para aprender un poquito de esta plataforma. Sin dudas es para seguir aprendiendo y usándolo en otros cursos/seminarios o en la materia Web.

A los alumnos les sirvió para ver como una plataforma, que tiene una interfaz REST, es muy fácil de integrar.

Recibida de la primer alumna de TUDAI

Con la finalización de este curso Lucre, fue la primer graduada de la carrera, así que los compañeros y familia aprovecharon a hacer el clásico ritual de tirarle «Con de Todo». Felicitaciones Lucre!

Comentarios, ideas, Pull Requests, etc. son más que bienvenidos!

Travis CI – Integración Continua fácil!

 

Hace poco estuve trabajando en un proyecto en Ruby, el cual tenía configurado Travis como servicio de integración continua.

Me llamo muchísimo la atención lo sencilla que es la configuración y la buena documentación que tiene. Con un simple archivo .yml y unas pocas líneas tenemos configurado nuestro servidor de integración continua, que incluso puede correr nuestra suite de tests en diferentes versiones de Ruby paralelamente.

Travis tiene soporte para multiples lenguajes, yo solo lo probé con Ruby, pero estoy seguro que voy a seguir haciendo algunas pruebas más con algún otro lenguaje como PHP, C# o Go.

Una última característica genial es que es gratis para proyectos Open Source.

Como funciona Travis CI

Tenemos que tener una cuenta de Github y entrar a travis-ci.org. Autorizamos a Travis a acceder a nuestros repositorios y voilà todo listo.

Los pasos a seguir son:

• Seleccionar el repositorio que queremos, haciendo click el botón que lo habilita.
• Subir a nuestro repositorio el archivo .travis.yml con la configuración.
• Hacemos un push a nuestro repositorio y automáticamente se ejecuta el primer build.

Travis.yml

Vamos a usar un ejemplo de un proyecto en Ruby.

	language: ruby
	sudo: false
	cache: bundler
	rvm:
	– 2.1.0
	– 2.2.1
	before_script:
	– chmod +x build_travis.sh
	script: "./build_travis.sh"

view raw

travis.yml

hosted with ❤ by GitHub

Como ven la configuración es sencilla, con las palabras claves nos damos cuenta que significa:

language: Es el lenguaje en el que esta escrita nuestra app. Ejemplo: ruby, go, rust, scala, etc.

sudo: Si vamos a ejecutar la suite como super usuarios. En nuestro caso vamos a hacerlo como usuarios normales.

cache: Los que programamos en Ruby sabemos que hacer un bundle install suele tardar un buen rato, es por eso que con esta opción, podemos tener el cache de la instalación de bundler hasta que nuestro Gemfile cambie, acelerando la ejecución de nuestros tests.

rvm: Esta opción nos permite tener diferentes versiones del lenguaje contra las cuales queremos probar nuestro código. Algo muy bueno de esto, en caso de usar Ruby, es que podemos probar nuestro código contra versiones de jRuby y con diferentes JDKs.

before_script: Podemos ejecutar comandos antes de ejecutar el script de build. En este ejemplo estoy dándole permisos de ejecución al script que va a correr mi build.

script: Es el script (o comandos) para ejecutar el build. En este caso arme un script de bash que contiene solo una linea bundle exec rake spec. Podría incluso escribir esta linea en el este archivo sin necesidad de llamar a un script para hacerlo.

Hay bastante mas posibilidades de configuración y de hacer cosas con Travis, pero en este post pretendo cubrir solo el escenario de correr una suite de test de Rspec.

Configuraciones en la aplicación

Haciendo click en More Options -> Settings accedemos a las configuraciones de Travis.

Podemos ver que tenemos activado el build con cada push a nuestro repositorio. Si nosotros hacemos un push a master o cualquier branch, Travis va a detectarlo y ejecutar un build.

También vemos que esta activado el build pull request. Esta característica es muy útil, ya que podemos estar trabajando en una algo nuevo, enviamos un PR para que nos revisen el código, y podemos asegurarnos que el código que vamos a mergear esta ‘Verde’ y no va a romper el build.

Vemos también una configuración de limitar jobs concurrentes. Esto nos sirve cuando tenemos tests de integración y estamos accediendo a la misma base de datos o API. No podemos ejecutar tests concurrentemente ya que los datos de prueba no serían consistentes. En este ejemplo no hay necesidad de limitar esto, ya que estoy buildeando una aplicación sencilla de una calculadora.

Por ultimo, si prestamos atención abajo de los botones están las Environment Variables. Estas variables las podemos configurar en el archivo .travis.yml, pero podemos también podemos configurarlas aquí. Podríamos poner en estas variables una conexión a una base de datos o alguna configuración del ambiente. Si es información sensible podemos ocultarla simplemente haciendo que la información no se muestre en el log con el botón al lado de la carga de la variable.

Esta del build en README.md

Un último detalle es que cuando usamos Travis, podemos tener el estado de nuestro build en nuestro repositorio.

Para eso podemos agregar al README.md la línea que nos da travis cuando hacemos click en el estado de nuestro build y seleccionamos Markdown como se puede ver en la siguiente imagen.

Con lo sencillo que es configurar Travis y si estas haciendo un proyecto open source, ya no hay mas excusas para no tener integración continua.

 

Git – Comandos Básicos #1

Siguiendo con la serie de posts Git lo estas usando mal les voy a comentar los comando básicos y algunos conceptos que nos vas a ayudar a entender un poco más.

Lugares en GIT

Para comenzar con los comandos básicos tenemos que entender que en Git podemos distinguir 4 lugares.

 

El primero es el directorio local de trabajo,  es donde se trabaja, se crean nuevas funcionalidades, se arreglan bugs, se crean archivos, etc.

Luego el area de cambios (Staging), en este lugar vamos a poner todas las cosas que queramos versionar con Git.

Una vez que estemos seguros de lo que queremos versionar, lo vamos a pasar al repositorio local.

El último lugar es el repositorio remoto, donde vamos a enviar los cambios que tengamos en nuestro repositorio local, para hacerlos públicos.

A medida que vayamos viendo los diferentes comandos vamos a ir refrescando estos lugares.

Comandos Básicos

Crear repositorio

Lo primero que vamos a hacer es crear un repositorio en Github. Un repositorio es el lugar donde vamos a guardar el código fuente de nuestra aplicación.

Desde la pagina de inicio podemos crear un repo haciendo click en «+ New Repository»

Ponemos un nombre de repositorio y seleccionamos «Initialize this repository with a README»

Clone

En la página del repo nos va a indicar la dirección ssh.

Una vez que la copiamos, vamos a la consola y ejecutamos

git clone [dirección ssh]

En mi caso es

git@github.com:ignaciojonas/test-git.git

Este comando nos va a crear una carpeta (Directorio de trabajo local) con le nombre del repo que tiene, el README.md y una capeta oculta que se llama .git

Status

Con este comando vamos a ver el estado actual de nuestro repositorio local. Es importante recalcar que en Git siempre vamos a ver el estado de nuestro repositorio en nuestra maquina, ya que Git guarda toda su información localmente y te permite seguir trabajando aunque estés desconectado de internet.

Dentro de la carpeta del repositorio ejecutamos

git status

Si no cambiamos nada nos debería mostrar algo como esto:

• En que branch estamos parados (Ya vamos a ver esto mas adelante)
• Si nuestro branch esta sincronizado con el repositorio en Github (por defecto el repositorio de donde clonamos se llama origin)
• Por ultimo que no tenemos ningún cambio, y que nuestro directorio esta limpio

Si ahora modificamos el archivo README.md y le agregamos por ejemplo

Este es un repositorio de prueba para comenzar a usar Git.

Una vez que grabamos el archivo y volvemos a ejecutar git status vamos a ver algo parecido a esto:

Las primeras lineas son lo mismo que antes, pero vemos que ahora dice «Changes not staged for commit:» y nos da instrucciones para actualizar el archivo en el repo o rechazar los cambios. Por ultimo en rojo vemos el archivo que se modificó.

Add

Con el comando add vamos a indicarle a Git que queremos agregar algo al repositorio, ya sea algo nuevo o algo que modificamos.

Por ejemplo vamos a agregar el archivo README.md

git add README.md

Cuando tenemos muchos archivos y queremos agregar todos al area de stage podemos hacerlo con

git add .

Si tenemos archivos nuevos, tenemos que agregarlos por nombre (como lo hicimos con README.md) o bien agregando todo pero usando el siguiente comando.

git add -A

Ahora cuando ejecutamos git status vemos algo como esto:

 

Vemos en la segunda linea, «Changes to be commited», esto quiere decir que ya tenemos los achivos seleccionados para poder grabarlos en la historia.

Ahora nuestros archivos se encuentran en el segundo lugar de Git, el area de cambios (Staging). Para tener una imagen gráfica de esto es como poner las cosas arriba del mostrador, para que después alguien del otro lado lo guarde.

Commit

El comando commit nos va a permitir «grabar» en la historia los cambios que hicimos.

git commit -m "[mensaje representativo]"

Es muy importante que los mensajes de commit (Lo que esta entre comillas dobles) sean representativos. De nada sirve un mensaje muy genêrico, como por ejemplo «Cambios Varios», siempre es mejor ser explícitos. Pensemos que lo que escribamos en la historia de git va a ser leído por todos los de mi equipo y cada uno le puede interesar ver donde se hizo un cambio especifico.

Por ejemplo en el ejemplo que estamos siguiendo en este post un buen mensaje sería

git commit -m "README.md - Agrego información de prueba"

Cuando ejecutamos este comando vamos a ver algo asi

Una vez ejecutado este comando, habremos agregado los archivos al repositorio local. Este commit queda grabado en la historia de Git en mi repositorio local hasta que lo subamos a un repositorio publico.

Ahora cuando ejecutamos git status, vamos a ver que nos da un mensaje que dice: Your branch is ahead ‘origin/master’ by 1 commit. Esto quiere decir que lo que esta en Github, esta «viejo», ya que yo tengo un cambio en mi maquina que no esta en ese repositorio publico.

En este punto nuestro archivos están en el tercel lugar de Git, el repositorio local, el cambio que hicimos a README.md esta grabado en la historia de Git.

En la próxima entrega de Git – Lo estas usando mal, vamos a ver como hacemos para que todos estos cambios que hicimos localmente, lo pueda ver otro miembro de nuestro equipo, como sincronizar nuestro repositorio local con el repositorio remoto y las primeras resoluciones de conflictos.

 

Configurar GIT

Siguiendo con la serie de post, hoy les voy a comentar como tengo configurado GIT en mi maquina.

Configuración basica

Identidad

Para empezar, tenemos que configurar el nombre de usuario y el mail. Para esto ejecutamos los siguientes comandos, reemplazando con nuestro nombre y nuestro email.

$ git config --global user.name "Ignacio Jonas"
$ git config --global user.email ignaciojonas@example.com

Editor de texto

Cuando queramos editar un mensaje de un commit o hacer un rebase o algunas otras cosas que vamos a ir viendo mas adelante, algo que vamos a necesitar es un editor de texto. El que más me gusta a mi es Vim, pero ustedes pueden usar el que quieran.

$ git config --global core.editor vim

Si no se sienten cómodos usando un editor de consola pueden incluso usar cualquier otro editor gráfico. Para configurar Atom por ejemplo:

git config --global core.editor "atom --wait"

El flag –wait hace que Git espere a que cerremos el editor para commitear.

AutoCRLF

Cuando estamos trabajando en diferentes plataformas (parte del equipo en Linux, otros en Mac OS y otros en Windows) es importante prestarle atención a cómo tenemos configurado Git con respecto a los fines de línea, ya que puede que tengamos algunos problemas.

Git nos ayuda a no tener estos problemas convirtiendo los fines de linea CRLF (Windows) en fines de linea LF (Unix).

Si usas Windows conviene tenerlo configurado en true, esto convierte los fines de linea LF en CRLF cuando hacemos checkout del código.

$ git config --global core.autocrlf true

Si estas trabajando en un sistema operativo Unix (Linux o MacOS), no es necesario que Git convierta los fines de linea, sin embargo, si por casualidad introducimos un fin de linea CRLF, conviene que Git se haga cargo por nosotros de convertirlo en LF. Para esto lo configuramos con el siguiente comando.

$ git config --global core.autocrlf input

Por último, si todo el equipo esta trabajando en Windows, haciendo un proyecto para funcionar solo en Windows.

$ git config --global core.autocrlf false

Como veo las configuraciones?

Para ver como tenemos configurado Git lo único que tenemos que hacer es ejecutar el siguiente comando

$ git config --list

Configurar la clave SSH

Para poder identificarnos contra un servidor que tenga una copia de el repositorio lo podemos hacer de diferentes maneras. La más común es conectarnos usando una clave SSH.

Para todos los ejemplos de esta serie de posts, vamos a usar GitHub. Si no tenés un usuario podes registrarte acá.

Crear una clave SSH

Si tenés una clave ssh creada, entonces podes ir a Configurar la clave SSH en Github.

Para generar una clave SSH basta ejecutar el siguiente comando.

$ ssh-keygen -t rsa -C "your_email@example.com"

Cuando ejecutamos, nos va a aparecer algo parecido a lo siguiente, apretamos enter. La clave SSH se va a guardar en una carpeta .ssh dentro de la carpeta de nuestro usuario.

Generating public/private rsa key pair.
# Enter file in which to save the key (/Users/you/.ssh/id_rsa): [Apretar Enter]

Luego nos va a pedir que ingresemos un passphrase. Es recomendable que pongamos una buena frase, aunque no es obligatoria.

Una vez que hecho esto tenemos la clave SSH generada.

Configurar la clave SSH en GitHub

Para agregarla a Github, lo primero que hacemos en loguearnos con nuestro usuario.

Vamos a Settings->SSH Keys y hacemos click en Add SSH Key.

Completamos un titulo (Para recordar donde tenemos configurada esa clave SSH) y en el campo Key ponemos el contenido de nuestro archivo ./ssh/id_rsa.pub.

Para copiar el contenido (al menos en Mac OS) podemos ejecutar

$ pbcopy < ~/.ssh/id_rsa.pub

Este comando nos copia el contenido de la clave publica en el portapapeles.

Por último hacemos click en Add Key.

Con esto terminamos la configuración básica de Git. En los próximos posts les voy a contar como empezamos a usarlo.

Atom – El editor de @github

Hace un tiempo conocí Sublime Text, un genial editor de texto multi -plataforma en el cual podes escribir en cualquier lenguaje de programación y tenes muchísimos plugins que te facilitan la vida.

La única desventaja que le encontré es que es pago y para usarlo sin pagar hay que «aguantar» un cartel que aparece de vez en cuando.

Hace ya un tiempo la gente de GitHub crearon Atom, su propio editor de texto, que se parece muchísimo a Sublime.

Lo instale en mi maquina y el cambio a usar Atom fue automático, simplemente hay que acostumbrarse a los atajos de teclado.

Atom, Git y GitHub

Algo que es genial de éste editor es que podemos ver el estado de nuestro repositorio solo viendo el árbol de archivos a la izquierda de la pantalla. Como es esto?, con colores nos indica si tenemos un archivo que aun no esta en staging, o que fue modificado o que esta en su ultima version.

Por ejemplo, aun no hice ningún cambio en este proyecto, entonces en el árbol de archivos todo es gris.

Si creo un nuevo archivo este aparece de color verde y si modifico otro aparece de color naranja.

Otra cosa que es muy útil es la previsualización de archivos escritos en Markdown. Como seguramente vieron, los archivos Readme.md de todos (o gran mayoría) de los repositorios de GitHub están escritos en Markdown.

Para usarlo simplemente en un archivo markdown apretamos ⌘ + shit + p, buscamos markdown, apretamos enter y voila.

Packages

Hay montones de plugins (packages) que se pueden instalar desde el menu de settings (⌘ + ,).

Solo les voy a recomendar uno que me viene salvando mucho tiempo Pretty-JSON. Ejecutando este plugin en un archivo JSON nos lo indenta automaticamente, ideal cuando se esta trabajando con APIs que deveulven JSONs gigantescos (No se olviden de seleccionar el  lenguaje del archivo como JSON, abajo a la derecha).

 

 

 

 

 

 

Instalar GIT

Empezando con esta serie de posts, les voy a contar como instalar GIT.

Hace muy poco me mude a trabajar en Mac OS Yosemite y un colega del trabajo me mostró iTerm2, es una consola mejorada para Mac OS. La verdad que es mejor que Terminal (Default en Mac OS). Así que te recomiendo que la instales porque mejora muchísimo la experiencia.

Si estas pensando usar GIT en Linux, la consola por default esta más que bien.

Si vas a usar Windows, te recomiendo que te instales cygwin, que es un emulador de la consola de Linux para Windows. Con esto tenes todo el poder de la consola de Linux, pero en Windows.

Si no sos muy amigo de las consolas, existen interfaces gráficas para GIT y en algún post voy a publicar algunas, pero para entender bien el funcionamiento de GIT lo mejor es la consola (@mrleinad dixit).

Instalación en Mac OS

En Mac OS, GIT, viene instalado por default, pero es recomendable que te instales la ultima version usando brew y algunos plugins más.

Antes de empezar podemos ver que GIT es el que tenes instalado, abrí iTerm y ejecutas

which git

Si la ruta de GIT es /usr/local/git entonces vamos a desinstalarlo haciendo lo siguiente (Usar sudo en los comandos cuando sea requerido).

rm -rf /usr/local/git
rm /etc/paths.d/git
rm /etc/manpaths.d/git

Ahora vamos a instalar brew con el siguiente comando:

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Una vez instalado brew vamos a seguir con la instalación de GIT

brew install git
brew link git

Si el último comando produce un error podemos arreglarlo haciendo

brew update
brew upgrade
brew doctor

Por último instalamos git-completion que nos sirve para que la consola autocomplete los comandos de GIT cuando apretamos TAB.

brew install git bash-completion

Instalar GIT en Windows

Para empezar hay que bajarte la ultima versión de cygwin.

Ejecutas el instalador de cygwin y seleccionas todas las opciones por default hasta el menu de seleccionar paquetes (Select Package)

En ese menu hay que elegir:

• git-gui
• gitk
• git-completion
• openssh
• vim (si no esta seleccionado por defecto)

Update: Un aporte del grande  de @andresgariglio

@osolaborioso También para la windola tenés https://t.co/ioGRJp3BKS

— andres (@andresgariglio) January 15, 2015

Instalar GIT en Linux (Ubuntu)

Simplemente

sudo apt-get install git-core git-completion

Con esto tenemos todo el ambiente funcional para empezar a aprender GIT.

Git – Lo estas usando mal

Muchos sabemos que GIT es un «muy potente» sistema de control de versiones. Y también muchos pasamos horas/días tratando de entender que es lo que «esta haciendo». Cuando me pasa eso, @falvarisqueta siempre me dice a tono de chiste «Los estas usando mal», o también, «el problema esta entre la silla y el teclado; y no en GIT».

En esta serie de posts (GIT – Lo estas usando mal) voy a ir publicando lo que fui aprendiendo en este último tiempo que comencé a usarlo de una forma un poco más intensiva y profesional.

Algunos de los tópicos que tengo planeados:

• Instalar GIT
• Configurar GIT
• Comandos Básicos
• Rebasing
• Como hacer un merge
• Re-escribir la historia
• Workflows de Trabajos – Feature Branch

 

Git – Cómo poner el nombre del branch en la Consola

Para todos los usuarios de Git, algo importantísimo es saber donde uno esta parado, en que branch está. Hace unos meses estoy usando Ubuntu para el trabajo y modifique un poco la consola para que se vea el nombre del branch cuando estoy parado en un repositorio.

Para hacer esto hay que seguir los siguientes pasos:

• Parados en el home de nuestro usuario ejecutamos: gedit .bashrc
• Agregamos el siguiente código en el archivo (abajo del todo)

• Guardamos y cerramos .bashrc
• Ejecutamos: source .bashrc.  Esto recarga la configuración de la consola
• Voila el nombre del branch va a aparecer en la consola cuando estemos dentro de un repositorio de Git.

Debian + Jenkins + PHP + GitHub

Preparando una taller para unos alumnos sobre Integración Continua, configure un servidor utilizando Jenkins. A continuación los pasos que fui siguiendo para instalar las herramientas necesarias.

 

Herramientas que vamos a utilizar

• Debian– www.debian.org
• Jenkins CI – www.jenkins-ci.org
• Apache Ant – ant.apache.org
• PHP QA Tools – www.phpqatools.org
• PHP – www.php.net
• Pear –  www.pear.php.net

Paso a Paso

Instalar Debian

Lo primero que tenemos que hacer es instalar Debian, en el cuadro de «Software Selection» elegimos:

• Web Server
• SSH Server
• Mail Server

Instalar PHP y algo más…

Nota: Para los pasos que siguen, todos los comandos se ejecutan en una terminal como root.

Lo siguiente que vamos a hacer, como estamos creando un servidor de integración continua para PHP, es instalar PHP y Pear.

apt-get install php5 php5-dev php5-xdebug php-pear

Instalar Jenkins

Los siguientes pasos están tomados de la documentación oficial de Jenkins.

wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
apt-get update
apt-get install jenkins

QA Tools

Para instalar las QA tools vamos a usar Pear.

pear upgrade PEAR
pear config-set auto_discover 1
pear install pear.phpqatools.org/phpqatools
pecl install xdebug

Instalar Apache Ant

Como nuestro template para contruir proyectos PHP va a utilizar Ant, vamos a instalarlo.

wget http://www.us.apache.org/dist/ant/binaries/apache-ant-1.9.2-bin.tar.gz
tar xvfvz apache-ant-1.9.2-bin.tar.gz -C /opt
ln -s /opt/apache-ant-1.9.2 /opt/ant

Configurar la variable de entorno para que podamos ejecutar Ant desde cualquier lugar

sh -c 'echo ANT_HOME=/opt/ant >> /etc/environment'
ln -s /opt/ant/bin/ant /usr/bin/ant

Para verificar que Ant se instalo bien, ejecutamos:

ant -version

Instalar Git

Por último, para que Jenkins pueda traer el código a integrar desde GitHub, necesitamos instalar git

apt-get install git-core

Luego tenemos que generar una RSA key para el usuario jenkins (el usuario que ejecuta jenkins). Para eso desde una consola de root, cambiamos el usuario a jenkins y generamos la key.

su - jenkins
ssh-keygen -t rsa -C "your_email@example.com"

Luego copiamos nuestra clave publica.

Para eso podemos hacer:

cat .ssh/id_rsa.pub

Copiamos la salida del comando cat y la pegamos en SSH keys en nuestro usuario de GitHub.

 

Por último, con el usuario Jenkins, ejecutamos

ssh -T git@github.com

Y aceptamos github.com como parte de nuestros know hosts.

Últimos detalles

Para poder acceder a Jenkins desde otra maquina, vamos a tener que configurar IP Tables para que nos permita acceder al puerto 8080, desde afuera. Para eso podemos ejecutar, nuevamente como root.

iptables -A INPUT -p tcp --dport 8080 -j ACCEPT

Ahora ya tenemos Jenkins andando en nuestro Debian.

En proximos posts voy a mostrar como configurar un proyecto PHP en Jenkins.