Leí dentro del foro algunos comentarios que indicaban el uso de GitHub. Personalmente conozco mejor el uso de dicha herramienta de repositorios en Linux, y dado que utilizo SAP en Windows, no había tenido chance de mezclar ambos conceptos.
Actualmente me encuentro en proceso de aprendizaje de ABAP, y quería almacenar mis códigos en un repositorio, aunque sea público. No me importa por varias razones, primero, no creo publicar código privado, segundo, creo que hoy en día compartir el conocimiento es en extremo importante, y ahora vale más que tanto compartes lo que sabes, que lo que sabes por sobre los demás.
Considerando lo anterior, quería compartir con ustedes un pequeño tutorial que he realizado con la ayuda de un amigo personal (que no pertenece al mundo SAP, por eso no está en la comunidad). Acá va:
Objetivo:
Utilizar Git para controlar versiones de código creado en lenguaje ABAP. Subir el código a un repositorio GitHub y publicar aportes en dicho lenguaje, todo, en un sistema operativo Windows.
Registrarse. Recordar bien las credenciales, pues serán usadas posteriormente:
Una vez registrado, iniciar sesión y crear un nuevo repositorio:
Asignar una url (nombre) al repositorio, una descripción, configurar la privacidad (público para servicio gratuito y privado si se paga por el servicio) y crearlo:
Instalar la aplicación usando la configuración por defecto. Sólo mantener precaución en instalarGit Bash
3. Crear directorio como repositorio local
Crear una carpeta donde se irá guardando el código fuente creado en ABAP. Dar clic derecho y seleccionar Git Bash Here:
Crear el primer archivo, llamado “readme.md”:
$ touch readme.md
Iniciar repositorio local creando carpeta “.git” con la metadata:
$ git init
Agregar cualquier cambio realizado al directorio actual (identificado por un punto “.”):
$ git add .
Ver cambios, o analizar qué está pasando:
$ git status
Realizar primer commit:
$ git commit -m "Primer commit"
Analizar el estado:
$ git status
4. Vincular repositorio local con GitHub
Ir a https://github.com/, y copiar la dirección del repositorio creado en el punto 1. Crear una cuenta en el repositorio GitHub:
Asociar el repositorio de GitHub a un nombre, y al repositorio local:
$ git remote add <nombre> <repositorio>
Donde es un nombre a elección y la url del repositorio de GitHub (puede ser otro directorio).
Subir el repositorio local, a GitHub:
$ git push -u <nombre> master
Donde es el nombre indicado en el punto anterior.
Se solicitará el usuario (correo electrónico) y contraseña de GitHub, creados en el punto 1. Crear una cuenta en el repositorio GitHub.
Ver el estado
$ git status
5. Modificar un archivo y verificar cambios:
Abrir con un editor de texto, el archivo “readme.md” y agregar contenido en formato MarkDown (opcional que tenga ese formato):
Verificar el estado, para ver cambios:
$ git status
Subir los cambios a GitHub. Este proceso se hará en adelante, luego de agregar carpetas, archivos y código nuevo, o modificar archivos existentes:
Edité un par de fotos, y creo que la versión actual es apta para ser publicada. Gracias por el interés
Hay un par de usuarios de GitHub que son verdaderos rockstars (guardando las proporciones) de ABAP. Por ejemplo Lars Hvam o Bryan Abrams han compartido mucho material interesante para los que estamos partiendo con este lenguaje.
Les recomiendo mirar estas fuentes, pues al igual que esta comunidad, sólo tienen como objetivo compartir conocimiento y fortalecer este microuniverso en el que estamos involucrados.
Les recomiendo mirar estas fuentes2, pues al igual que esta comunidad, sólo tienen como objetivo compartir conocimiento y fortalecer este microuniverso en el que estamos involucrados.
Este repositorio fue mi primer contacto con código ABAP!
Espero pronto poder aportar algo como esto!
Imaginate un grupo de 5 abapers tocando UN programa con 10 mil líneas.
Por más que SAP tenga su control de versiones, no podrían interactuar los 5 programadores en ese control, en cambio teniendo GitHub podrías unirlos.
Un ejemplo de usar ABAP con github en la práctica:
Sí entiendo el objetivo de GIT, no lo sabia la verdad. La interacción de SAP con GIT es mediante archivos de código planos tipo Notepad++ o se usa alguna herramienta que integre los entornos?
Hablo desde mi experiencia, no uso Git, uso Github.
El GUI toma un directorio como entorno de trabajo, los cambios que vos hagas automáticamente el GUI los va versionando y lanza los commit al repositorio.
Ayer probé con GIT, y hace lo mismo. Mejor si probas, y si quedan dudas abrí un tema nuevo así lo vemos.
Este tema es un tutorial, abramos un debate abierto sobre las dudas que queden
Exacto @mduenasp, eso es lo que hice en su momento. Generaba código directamente en SAP y luego de comprobar que era funcional lo exportaba en documentos de texto plano, los cuales “pusheaba” a GitHub.
El objetivo de un controlador de versiones es ordenar y controlar el desarrollo de un producto. Imagino que el controlador de versiones de SAP (no lo conozco) cumple con todas las características necesarias para ello, a saber: funcionar en un ambiente colaborativo, permitir rápidos rollback, generar distintos branch de desarrollo para que cada uno resuelva distintos issues sin “pisarse” el código entre sí, etc. Si es así, perfecto, funciona y es práctico.
Sin embargo, no es la razón por la que uso GitHub o GitLab (Git en general). Esos repositorios los uso para compartir conocimiento. Para mí no es sólo un controlador de versiones Web. Prácticamente lo uso para todo (subo ejemplos de código, tareas o trabajos de prueba, códigos de proyectos, documentación, tutoriales, etc.).
Creo que parte de la filosofía detrás de Git está en lo que puse en el inicio de mi post, me autocitaré:
creo que hoy en día compartir el conocimiento es en extremo importante, y
ahora vale más que tanto compartes lo que sabes, que lo que sabes por
sobre los demás
Creo que eso resume un poco el por qué del uso de uno, y no el uso de otro. Un controlador de versiones dentro de un ambiente SAP sería para temas netamente laborales, controlar un desarrollo, tener un historial, ver qué hace cada persona, etc. Pero ahí no hay una filosofía de compartir conocimiento. Como digo, ahora vale más cuánto compartes, que lo que sabes sólo tú.
Actualmente las herramientas que soportan el desarrollo para ambientes SAP ha ido evolucionando, con la inclusión de tendencias como IoT, Big Data, por ejemplo. SAP salio del entorno ABAP, que de por si el Workbench hace de manera integrada las tareas de versionamiento y distribución a través del workbench ABAP y el CTS (mejor conocido como el sistema de transporte). Si bien el workbench de ABAP no se puede definir como colaborativo, sobre todo porque su concepcion no se realizo en una época donde ese termino existía, si tienen elementos que pueden soportar un ambiente de desarrollo “colaborativo” ya que un mismo desarrollo que tengas varios elementos del proyecto de desarrollo, puede estar asociado a una sola orden de transporte y cada tarea puede estar asociada a uno o varios programadores.
Con la evolución en el área de desarrollo que empezó al crear elementos sobre JAVA en las aplicaciones sobre los AS JAVA hasta ahora con el uso de SAP Cloud Platform como soporte de servicios y plataformas de desarrollo, SAP empezo a introducir elementos como GIT o Jenkins para el versionamiento y distribución de los proyectos que se desarrollan sobre SCP (que son de naturaleza colaborativa) sobre todo para el ciclo de desarrollo y extender la funcionalidad del CTS al CTS+ para el transporte de los cambios de manera integrada para su transporte a ambientes de prueba y producción.
Ah, pero lógico. Incluso para los más apegados a ABAP se tiene abapgit o cosas más modernas y entretenidas. Claramente la publicación tenía más sentido en abril del 2016 que fue cuando la publiqué, hahaha.
De todos modos, creo que más importante que la inclusión de herramientas o tendencias, es la inclusión en las personas de filosofías y culturas diferentes (como hablar de DevOps, por ejemplo). Eso siento que aun falta, sobretodo en la comunidad de SAP. Pero bueno, para eso sirven comunidades como esta, para impulsar ese cambio
@MnKGuitarPro
Estoy de acuerdo con lo que indicas. Aun ese tema esta en desarrollo en la comunidad SAP, están haciendo un buen esfuerzo con el desarrollo del SAP CP, y alinearse con las tendencias agil, SCRUM y demás.Lo mas seguro que dentro de unos meses lo que cualquiera de nosotros sepa ya habrá cambiado. Hay que seguir leyendo e investigando.
