Administración de landings en Vtex

Guía para la creación de una landing
Descarga el archivo HTML base para la creación de una landing

Éxito (Vtex IO)

Esta documentación es una guía para el desarrollo con Vtex IO

Lineamientos desarrollo
Recursos necesarios
Guía
Vtex Cli
Trabajando con Vtex + React
Integración continua

Lineamientos de Desarrollo

Estándar de manejo de Git

Referirse a GitFlow

Recomendaciones merge Develop / Master

Los pasos a Develop requieren de un Pull Request para la respectiva revisión par.
Mantener las ramas de desarrollo actualizadas antes de realizar merge contra Develop/Master, por lo tanto debe constanemente revisarse cambios que se estén realizando sobre la rama a la cual se pasarán los cambios.
Los warnings por errores de typescript deben estar corregidos antes de pasar los cambios a develop/master. De esta forma el comando vtex link -u que permite enlazar el proyecto contra el workspace de trabajo, solo es permitido para efectos de agilizar las pruebas de concepto del desarrollo que se esté llevando a cabo.

Versiones

Seguir el estándar de Semantic Versioning ver aquí

Publicación del store y componentes hijos

El vendor para el proyecto de store corresponde con la cuenta específica: exito, exitocol, carulla, carullaqa Para el resto de componentes siempre se usa exito. Esto mientras los componentes puedan ser comunes entre cuentas.

Lineamientos de aplicación de estilos en VTEXIO

Los estilos sobre los componentes en VTEXIO basados en la estructura HTML como div, p, section, html, e.g. div > div > span[foo="bar"], han sido deprecados. En lugar de eso, debe utilizarse el concepto de "CSS Handles" de VTEX para la aplicación de estilos CSS. Adicionalmente, para facilitar la detección de CSS Handles utilizados en algún elemento en una sección en VTEXIO, se ha puesto a disposición el parámetro ?__inspect

Mayor detalle sobre cómo utilizar CSS Handles y el parámetro ?__inspect aquí
Anuncio sobre los cambios en los lineamientos de aplicación de CSS aquí

Recursos necesarios

Node js
Yarn Gestor de paquetes de Facebook
Visual Studio Code Editor
3.1 Extensiones Básicas:
Create React App Repo
Create React App Npm
Vtex Cli Línea de comandos para vtex
Exito Cli Línea de comandos para éxito
CMDER Terminal Para windows
Iterm2 Terminal para Mac
Aws Cli Línea de comandos para Amazon

Guía

Cursos para iniciar

React Básico Youtube CodeJobs
React Curso Completo Udemy
Graphql + React Udemy
Guía Gitflow

React typescript tips

Cómo manejar la versión de los componentes (Semantic versioning)

para manejar la versión de nuestros componentes emplearemos la siguiente guía semantic-versioning

Como se deben de documentar el código en React

Para realizar la documentación en React se emplea el estándar definido por react-styleguidist donde se definen diversas técnicas necesarias para documentar los componentes creados, además de esto permite generar una documentación automática que permite visualizar muy bien el contenido que hemos documentado. demo

Se recomienda manejar el concepto de jsDoc para los comentarios de nuestros componentes.

Para la documentación emplearemos los archivos

Ejemplos para documentar:

Basic Changelog Basic Readme

Definición para los workspace empleados en el desarrollo

Se plantea la siguiente estructura, donde exito es el workspace principal o productivo, el workspace dev es el workspace pre productivo y los workspaces qa1, qa2, qa3 son los workspace destinados para los equipos de SQA para realizar las validaciones de los desarrollos que se planteen para el sprint. Cada desarrollador deberá de crear su workspace definiendo el equipo de SQA que realizará sus validaciones técnicas y el tipo de desarrollo que está realizando en ese momento.

Ejemplo:

qa1_header–exito.myvtex.com
qa1 —> Equipo de SQA encargado de la validación técnica
header —> Desarrollo asignado

Jerarquia de los workspace

	master
	dev
qa_feature	qa_feature	qa_feature
feature	feature	feature

Vtex Cli

Instalación de dependencias para el Admin de Vtex
Creación de un nuevo componente con Exito cli

Instalación de dependencias para el Admin de Vtex

Las siguientes dependencias permiten agregar comportamientos como el admin pages y el storefront en la página de vtex.

vtex install vtex.pages-editor
vtex install vtex.admin-pages

Actualización de las dependencias de una cuenta en Vtex

vtex deps update  
vtex infra update

Configuración de un componente editable en el StoreFront de Vtex

para la configuración necesaria para el storefront se necesitan tres métodos dentro de nuestro componente:

*getSchema : Define los diferentes atributos que se le pasarán al componente por medio de las propiedades.

    ClassName.getSchema = () => {
    return {}
    };

Ejemplos donde se emplean esquemas en los componentes:

Este método es empleado por Vtex para la creación de las opciones del storeFront

Ejemplo aquí

Promover un workspace a producción

los pasos para promover un workspace son:

vtex workspace production true Cambiamos el modo producción del workspace a true

callback

info: Workspace dev set to production mode
info: You can now check your changes before publishing them
info: If everything is fine, promote with vtex promote

vtex publish [path] Publicar todos los componentes o los componentes que vayamos a emplear, para realizar la publicación de un componente debemos de tener en cuenta el orden de importancia de los componentes. de lo contrario obtendremos error al subir los componentes
vtex promote Promovemos el workspace actual a ser una integración con el master, este paso eliminará el workspace actual.

Cómo publicar una aplicación

vtex workspace production true Cambiamos el modo producción del workspace a true
vtex publish [path] Publicar todos los componentes o los componentes que vayamos a emplear, para realizar la publicación de un componente debemos de tener en cuenta el orden de importancia de los componentes. de lo contrario obtendremos error al subir los componentes, además se debe de tener en cuenta la versión de la aplicación.
Luego de publicar los componentes, volvemos a indicar que el workspace está en modo desarrollo vtex workspace production false

Nota: Podemos realizar la publicación directa en el workspace master.

Integración continua

Explicación del flujo que se realiza para publicar un componente.

Creación de los triggers para los proyectos:

generate triggerConfig: Comando que genera un archivo base con la configuración para los triggers.

[{
"name": "develop",
"customData": {
	"code_build": "exito-vtex-deploy-develop",
	"vendor": "exito",
	"workspace": "dev",
	"code_commit_branch": "develop",
	"url_to_clone": "https://git-codecommit.us-east-1.amazonaws.com/v1/repos"
	}
}]

Para crear diferentes triggers en un solo proyecto es necesario copiar la configuración base y reemplazar los puntos importantes, name code_build vendor workspace code_commit_branch

El atributo url_to_clone no se debe de cambiar, este es el endpoint para el repositorio de aws code commit

Ejemplo

[{
	"name": "develop",
	"customData": {
		"codeBuild": "exito-vtex-deploy-develop",
		"vendor": "exito",
		"workspace": "dev",
		"codeCommitBranch": "develop",
		"urlToClone": "https://git-codecommit.us-east-1.amazonaws.com/v1/repos",
		"linkCommand": "'vtex link'",
		"publishCommand": "'vtex workspace use master && vtex publish --verbose'"
	}
},
{
	"name": "master",
	"customData": {
		"codeBuild": "exito-vtex-deploy-master",
		"vendor": "exito",
		"workspace": "master",
		"codeCommitBranch": "master",
		"urlToClone": "https://git-codecommit.us-east-1.amazonaws.com/v1/repos",
		"linkCommand": "'vtex link'",
		"publishCommand": "'vtex workspace use master && vtex publish --verbose'"
	}
}]

Con esta configuración se generarán dos triggers apuntando a diferentes branchs y llamando a diferentes codebuild. además de realizar un proceso de login en un workspace llamado dev y otro master

generate trigger <arn>: Comando que genera un archivo .json que contiene la configuración para agregar los trigger necesarios para realizar la comunicación con el CodeBuild de develop o master.
run triggers: Comando que se encarga de leer el directorio actual y permitir realizar la ejecución de los archivos .json que contienen la configuración para actualizar o agregar los triggers de un repositorio.

Como puedo verificar el build realizado cuando realice un push a los branchs `develop`y `master`

En el servicio de Amazon de CodeBuild pueden encontrar los siguientes proyectos para realizar el build de nuestros componentes

exito-vtex-deploy-develop: Empleado para hacer el build del branch develop
exito-vtex-deploy-master: Empleado para hacer el build del branch master

Proceso para la actualización de dependencias

Creación de un archivo con las ultimas versiones de las dependencias

vtex deps list > current-dependencies.json

Para estar seguros de tener las últimas versiones en este archivo, se recomienda previamente correr en el worskpace que se esté trabajando el comando vtex deps update con esto actualizamos todas las dependencias a su última versión

Creación del archivo de configuración que contendrá las últimas versiones a emplear en la actualización

generate configDependencies <criteria>: Comando que toma el archivo current-dependencies.json del directorio actual y genera un archivo update-dependencies.json con las dependencias filtradas y el formato igual al de el atributo dependencies del archivo manifest.json

ejemplo: exito generate cd vtex.: genera el archivo con todas la dependencias que coincidan con el criterio indicado vtex. Nota: Cuando un proyecto posee mas de una versión empleada actualmente, se pasa a armar el nombre de la dependencia junto a sus posibles versiones separadas por un - ejemplo: "vtex.styleguide": "9.67.0-8.67.0", donde las posibles versiones son 9.67.0 y 8.67.0

Ejecución del proceso para actualizar las dependencias run overWriteDependencies <criteria> [lastVersion]: Comando que toma el archivo update-dependencies.json en el directorio actual y luego se encarga de buscar todos los proyectos que hayan en el directorio para listarlos y permitir la selección de los proyectos a actualizar. luego de seleccionar los proyectos se pasa a realizar una validación para saber si poseen cambios a nivel de dependencias y de ser así se pasa a actualizar las dependencias encontradas. este proceso actualiza un dígito la versión del proyecto y genera un mensaje en el archivo CHANGELOG.md indicanto que cambios se realizaron.

Nota: por defecto el comando trae la última versión de la dependencia que posee el proyecto. con el flag --last luego del criterio de búsqueda se pasa a emplear la última versión disponible de la dependencia.

Ejemplo: exito run ov vtex. --verbose

Ejemplo empleando la ultima versión: exito run ov vtex. --last --verbose

Preparación del branch de los proyectos

Creación del branch en el que se realizarán los cambios

aws runGitCommand <commandTouse> comando que permite seleccionar los proyectos en el directorio actual y se encarga de correr el comando de git indicado.

Para realizar el proceso de creación de los branchs en todos los proyectos se corre el siguiente comando.

exito aws rgc 'git checkout -b name-branch'

Para pasar los comandos de git, encerramos los comandos en comillas simples para poder indicar los comandos a ejecutar.

Se puede indicar el nombre del branch de la siguiente forma:

name-branch feature/name-branch hotfix/name-branch

Cambiar entre branchs

Para realizar el cambio entre branchs de todos los proyectos puede emplear la combinación de comandos de git para hacerlo

exito aws rgc 'git checkout develop && git pull'

Si el branch que se indica no existe, puede emplear -b para realizar la creación exito aws rgc 'git checkout -b develop && git pull'

Descartar los cambios realizados

Para remover todos los cambios realizados y volver a dejar los proyectos en su ultima versión puede correr la siguiente combinación de comandos

exito aws rgc 'git reset --hard && git pull'

Eliminar branchs de los proyectos

Para realizar la eliminación de un branch en todos los proyectos podemos emplear la siguiente combinación de comandos.

exito aws rgc 'git branch -D feature/deps-update'

Preparar los cambios realizados

para preparar los cambios realizados se puede emplear la siguiente combinación de comandos

exito aws rgc 'git add . && git commit -m "Update dependencies"'

Realizar merge entre el branch creado y un branch indicado

exito aws rgc 'git add . && git commit -m "Merge feature/deps-update into develop" && git merge -X theirs feature/deps-update'

Subir los cambios realizados

Pueden emplear la siguiente combinación

exito aws rgc 'git push'

Paso a paso

vtex workspace reset
vtex deps list > current-dependencies.json
exito generate configDependencies vtex.
exito aws rgc 'git checkout -b feature/exito-cli-update-dependencies'
exito run overWriteDependencies vtex. --verbose
exito aws rgc 'git add . && git commit -m "Update all vtex dependencies in the current data 2019-07-22"'
exito aws rgc 'git push --set-upstream origin feature/exito-cli-update-dependencies'
exito aws rgc 'git checkout develop && git pull'
exito aws rgc 'git merge -X theirs feature/exito-cli-update-dependencies && git add . && git commit -m "Merge feature/exito-cli-update-dependencies into develop"'
exito aws rgc 'git push'

Cambios que se deben de realizar en los proyectos

Cambios para el sonar.scanner

Se deben de comentar las keys de login para sonarqube. ya que esto se agrega automaticamente con la cli de exito

La carpeta config ya no se usa y se debe eliminar

El proceso de integración continua ya no necesita que se tenga la carpeta config con los archivos de configuración, por lo que se debe de eliminar del proyecto.

Cambios en jest Coverage

Se debe de realiza la creación del archivo jest.config.js si no se posee en el proyecto, en este archivo debe de ir la configuración de jest que actualmente algunos projectos lo poseen en el package.json, sin este archivo el proceso de integración continua puede lanzar error.

Name		Name	Last commit message	Last commit date
Latest commit History 236 Commits
directory		directory
resources		resources
.DS_Store		.DS_Store
README.md		README.md

grupo-exito-ecommerce/exito-vtex-doc

Folders and files

Latest commit

History

Repository files navigation