Gestión del proyecto Chromium
Grupo 7 Evolución y Gestión de la Configuración (EGC) Tabla de control de versiones y cambios
Descripción Nº de Autores Revisado Fecha de versión modificación
Creación del documento 1.0 Jesús Díaz Sí 21/11/2013
Inserción del mapa de 1.1 Jesús Díaz Sí 28/11/2013 herramientas y creación de índice
Integración de partes en el 1.2 Jesús Díaz No 03/12/2013 documento
Integración de partes en el 1.3 Jesús Díaz No 03/12/2013 documento
Gestión del código y ejercicios 1.4 David Romero, Sí 18/12/2013 Sergio Trigos
Algunas correcciones 1.5 Jesús Díaz Sí 19/12/2013
Integración de partes faltantes 1.6 Daniel Platas Sí 22/12/2013
Finalización para versión 1.7 Daniel Platas Sí 23/12/2013 entregable
Incluir hoja de cambios 1.8 Jesús Díaz Sí 21/01/2014
Integración de partes 1.9 Daniel Platas Sí 06/02/2014 corregidas y actualización
2.0
Versión Actual: 1.9
Tabla 1: Control de versiones y cambios del documento de memoria
2
ÍNDICE
1 Resumen ...... 5
2 Introducción ...... 6
3 Gestión del código fuente ...... 8
3.1 Ramas ...... 9
3.2 Parches ...... 12
3.3 Gestión de los cambios en el código ...... 12
3.4 Procesos a seguir para el cambio del código ...... 14
3.5 Estados por los que pasa el código ...... 15
3.6 Políticas para descartar, fomentar o retardar un cambio ...... 15
3.7 Roles en la gestión del código ...... 16
3.8 Políticas de nombres y estilo ...... 17
3.9 Ejercicios ...... 19
4 Gestión de la construcción ...... 23
4.1 Cómo construir Chromium ...... 24
4.1.1 Obtener un el código fuente para la construcción ...... 24
4.1.2 Crear ficheros de construcción ...... 25
4.1.3 Construir Chrome ...... 25
4.1.4 Construir Test ...... 26
4.2 Resultados obtenidos ...... 27
4.2.1 Modo Debug ...... 27
4.2.2 Modo Release ...... 27
4.3 Ejercicios ...... 27
5 Construcción e Integración continua ...... 32
5.1 Definición de BuildBot ...... 35
5.2 Instalación de BuildBot ...... 36
3
5.3 Ejercicios ...... 39
6 Gestión de entregables ...... 43
6.1 Cómo se generan ...... 43
6.2 Cómo se identifican ...... 43
6.3 Cómo se gestiona la publicación ...... 44
6.4 Dónde se publican los entregables ...... 45
6.5 Ejercicios ...... 45
7 Gestión del despliegue ...... 46
7.1 Integración / despliegue continuos ...... 46
7.2 Mecanismos y procesos de despliegue ...... 48
7.3 Establecer los permisos (policy) ...... 50
8 Gestión de incidencias y depuración ...... 53
8.1 Gestión de incidencias ...... 53
8.1.1 Estados posibles para una incidencia (bugs) ...... 54
8.1.2 Creación de una incidencia ...... 55
8.1.3 Resolución de una incidencia ...... 56
8.2 Mecanismos de depuración ...... 57
8.3 Ejercicios ...... 58
9 Gestión de la variabilidad ...... 60
9.1 Modelo de variabilidad ...... 60
9.2 Modelo de Características ...... 61
9.3 Ejercicio ...... 62
10 Mapa de herramientas ...... 63
11 Conclusiones ...... 66
12 Anexos ...... 66
4
1 RESUMEN
Este documento refleja el estudio sobre la gestión de la configuración sobre el proyecto de software libre Chromium. En este proyecto podemos destacar diversos campos los cuales son explicados con profundidad a lo largo del texto.
En la gestión del código podemos encontrar cual es la herramienta utilizada para el desarrollo del proyecto, concretamente git-svn, que utiliza en general las instrucciones de gestión de código de git, pero se integra con un servidor svn para el control de versiones. Después podemos observar en esta sección las diferentes categorías o papeles que poseen los diferentes responsables del proyecto como pueden ser Sheriff, Trooper o Gardener. También podremos encontrar unos ejercicios sobre la utilización de git-svn.
El método seguido para la realización de cambios es una interacción entre el afectado, conocido como code owner y el reviewer que va a revisarlo. Esta interacción estará basada en una estructura pregunta-respuesta entre ambos individuos hasta que el reviewer dé el visto bueno al código. También encontraremos una descripción de cómo el reviewer depurará este código mediante la herramienta GDB.
En la construcción definiremos cómo se construye el navegador mediante los comandos indicados para Linux, así como una serie de ejercicios para ejemplificar el funcionamiento de las herramientas usadas en este ámbito.
En la sección de los entregables del observaremos cuales son los entregables a realizar en el proyecto, como son el código y el navegador. La forma de generarlos para el código seria la programación y para el navegador la compilación del código y la forma de liberarlos.
En el apartado de la variabilidad, hablaremos sobre las extensiones del proyecto y cómo están gestionadas.
5
En conclusión, la gestión del proyecto puede resultar costosa y difícil al principio pero después de que se aprende a manejar las herramientas y a tratar con ellas es sencillo entender la mayoría de conceptos y problemáticas.
2 INTRODUCCIÓN
Chromium es un proyecto de navegador de código abierto que tiene como objetivo mejorar la experiencia web de modo más seguro, más rápido y más estable para todos los usuarios de Internet. Este documento contiene información de su diseño, descripciones de su arquitectura, información de pruebas, etc; en términos generales se recoge la información sobre la gestión de dicho proyecto.
Para comenzar la descripción de la gestión de la configuración del proyecto necesitamos explicar qué es y qué ventajas presenta en el desarrollo de un proyecto software.
La gestión de la configuración es un proceso que se realiza durante todo el ciclo de vida de un proyecto, en el que se estudian, miden, contabilizan ciertos aspectos del proyecto para controlar los cambios que se van produciendo. La aprobación de dichos cambios y su integración dentro del proyecto provoca que haga falta asegurar que los miembros de trabajo del proyecto dispongan de las últimas versiones del producto que se genera.
En esta memoria recogemos el estudio de las siguientes partes de la gestión de la configuración del proyecto:
Gestión del código fuente: Se explican los procesos y técnicas para la gestión
del código del proyecto: gestión de ramas, aplicación de parches, aprobación
de cambios, roles en la gestión del código y estilo del código fuente.
Gestión de la construcción: Se definen los procesos que se usan a la hora de
construir el proyecto y cómo se usan.
6
Gestión de los entregables: Se describe qué elementos son los entregables,
cómo se generan, cómo identificarlos y cómo se gestiona la publicación y la
entrega.
Gestión del despliegue: Se detallan los mecanismos de despliegue que se
definen, sus procesos y las plataformas para las que se desarrolla.
Gestión de incidencias y depuración: Se recogen los mecanismos de
depuración usados, la gestión de los cambios, los estados que se manejan en
los procesos y qué roles y políticas se usan para descartar o aplicar un cambio.
Gestión de la variabilidad: Se explica como se controla la variabilidad del
proyecto ya que al ser un navegador web no sigue los estándares de un
proyecto software cualquiera.
Integración y despliegue continuos: Se definen los métodos que utiliza
Chromium para informar de los continuos cambios a los desarrolladores ya
que no dispone de herramientas concretas.
Mapa de herramientas: Se detallan las herramientas que se usan en el
desarrollo de Chromium en las distintas plataformas posibles y las relaciones
entre ellas.
Una vez que hemos detallado la lista de partes en las que se explicará la gestión de la configuración aportaremos unas conclusiones sobre la realización de esta memoria según la experiencia de los miembros del equipo.
En todos los apartados que lo permiten hemos planteado una serie de ejercicios y su resolución para analizar y fomentar el aprendizaje de las herramientas de Chromium para habituarnos a trabajar con ellas.
Además, se describe las posibles maneras de desplegar Chromium, así como, una vez desplegado éste en una organización, se pueden gestionar qué permisos tiene cada usuario al usar el navegador dentro de la misma.
7
3 GESTIÓN DEL CÓDIGO FUENTE
En esta sección hablaremos sobre la gestión del código fuente del proyecto
Chromium. Este proyecto utiliza dos tipos de repositorios, los repositorios git para el desarrollo de código y los repositorios svn para recoger todo el código almacenado en los repositorios git. En las siguientes imágenes podemos ver como la arquitectura de los repositorios se divide en 3 capas al igual que la arquitectura de trabajo.
En la primera capa (refs/heads/git-svn) se encuentran los repositorios git que con la herramienta git-svn pueden comunicarse con los repositorios svn situados en la segunda capa (refs/heads/master) y para finalizar tenemos la tercera capa
(refs/heads/lkgr o refs/heads/work) utilizada para comprobar las aportaciones realizadas a los repositorios svn y donde trabaja el equipo de admisión de cambios.1
1 http://dev.chromium.org/developers/how‐tos/git‐repo
8
Al utilizar dos tipos de repositorios es necesaria la utilización de la herramienta git-svn para poder administrar los diferentes repositorios, así que esta es una herramienta que permite seguir el conjunto de cambios producidos en subversion y git, provocando un flujo bidireccional entre ambos repositorios. 2
3.1 Ramas
Para comenzar a desarrollar código en este proyecto necesitamos la herramienta de gestión de código git-svn, mencionada anteriormente, que nos permitirá crear ramas según las necesidades que tengamos que realizar. Existen 2 tipos de ramas la rama principal llamada oringin/master y las ramas de release las cuales indicamos a continuación como se generan. Utilizando para ello las funciones “git branch” para mostrar todas las ramas creadas y la función “git checkout” para situarse en una determinada rama. Estos comandos deben realizarse en el espacio de trabajo para ello usamos las instrucción “cd src” .Un ejemplo de uso lo podemos ver a continuación.
"Enumerate your local branches: cd src git branch Switching from one branch to another: Example: Switching from branch 'mywork' to branch 'master. cd src git checkout master " 3
En este texto podemos ver cómo realizar la identificación de un branch y la posterior selección de este.
2 https://www.kernel.org/pub/software/scm/git/docs/git‐svn.html 3 http://dev.chromium.org/developers/how‐tos/get‐the‐code#Branches
9
Para la creación de nuevas ramas donde realizar diferentes trabajos del proyecto
Chromium utilizamos el método más recomendado por Chromium:
"Remote master style (RECOMMENDED): The master is on the server, referred to as the origin/master branch. All the branches are off the server. Create a new branch via: git checkout -b new_branch origin/master" 4
Para realizar un commit local de tus cambios es necesario realizar la siguiente instrucción “git commit -a -v”.
Si deseamos añadir nuevos archivos a la rama deberíamos que realizar la instrucción
“git add
Para la eliminación de una rama hemos seguido la forma recomendada por
Chromium. En este método habrá que asegurarse de la correcta unión de la rama al trunk principal con la instrucción “git rebase origin/master” estando en la rama que se desea unir a la principal, ademas podemos usar opcionalmente “git diff --stat origin/master” que nos aportará las diferencias de los cambios realizados, si no obtenemos ningún diferencia entonces podemos borrar la rama.
"To check that the branch has been committed upstream (using remote repository - RECOMMENDED): git checkout mywork git rebase origin/master git diff --stat origin/master # optional check" 4
Podemos observar que no se utiliza el comando “git merge”, en su lugar se utiliza el comando “git rebase” para la unión de la rama con la rama principal llamada origin/master
4 http://dev.chromium.org/developers/how‐tos/get‐the‐code#Branches
10
Una vez comprobado que no existe ningún error en el código añadido se procede al borrado de la rama:
"If there are no differences, delete the branch: git checkout origin/master git branch -d mywork # will only work if has been merged" 4
Si queremos recuperar una rama borrada necesitamos su SHA-1.
SHA-1 es un algoritmo resumen o hash utilizado por git para proporcionar integridad a los datos. Esta clase de algoritmos cifran el código (en este caso la rama) en texto de menor tamaño, en el caso de SHA-1 cifra toda la rama en un texto de 160 bits5. En el siguiente texto se nos indica como realizar la eliminación de las ramas.
"Deleted branch mywork (was 123abc0)." "If you forget the hash, you can find it via git reflog" 6
Una vez obtenido el SHA-1 que en este caso seria 123abc0 podemos recuperar la rama con el nombre mywork con la siguiente instrucción:
"git checkout -b mywork 123abc0" 6
Para poder enviar el trabajo realizado a los revisores de chromium en necesario realizar la siguiente instrucción “git cl try”.
Según algunos participantes del proyecto las ramas deben de ser pequeñas, en lo referente al tiempo de vida de estas, por lo cual una rama con más de 3 meses está desactualizada y daría problemas su integración con la rama principal.
"We try to have our branches as short lived as possible. With a 6 weeks of dev, beta and stable channels, a branch lives roughly for 18 weeks, or 3 months. Which means
5 http://en.wikipedia.org/wiki/SHA‐1#Data_integrity 6 http://dev.chromium.org/developers/how‐tos/get‐the‐code#Branches
11
that we don't care about any code that is more than 3 months old, which helps us tremendously to stay flexible on the code base refactoring.
That's really a huge advantage. The pipelining here is really what makes us much more efficient because we get different kind of feedback from each of the channels. Let's talk about user feedback. " 7
3.2 Parches
Si se desea añadir parches a una determinada rama tenemos que realizar las siguientes instrucciones:
" git checkout -b myworkfrompatch git cl patch 12345 # Using CL issue number, not bug number, applies latest patch set git cl patch https://codereview.chromium.org/download/issue12345_1.diff # Use URL of raw patch for older patch sets" 8
Donde la primera instrucción es para crear una rama donde poder realizar el parche, la segunda instrucción podemos introducir un parche mediante números de cuestión mientras que la tercera instrucción introduce un parche mediante URL.
3.3 Gestión de los cambios en el código
El proyecto Chromium especifica que se debe realizar, si realizas algún cambio, una lista de cambios donde recogeremos todos los cambios realizados. Cada cambio debe poseer los siguientes atributos descripción del cambio: realizador, error y pruebas. En el siguiente texto podemos observar cómo se documenta un cambio:
"This will open your text editor. Write the change description at the top of the file. The description should describe what your patch changes and why. This is important for people who are looking at commit logs in the future to track down an issue: they should be able to see why you changed it without going anywhere else. If there's an associated bug file, you should also add a BUG=bug_number line so they can find the associated bug. If you have manual test instructions that you want to pass to the test
7 http://dev.chromium.org/developers/tech‐talk‐videos/release‐process#TOC‐Pipelining‐releases 8 http://dev.chromium.org/developers/how‐tos/get‐the‐code#Branches
12
team so that they can validate the fix, add TEST=how_test_test at the end of the description.
If there is no bug or test, leave out the lines. Multiple bugs can be listed, comma separated. Example:
Increase the goat teleporter timeout threshold to 100 because the old value of 10 caused problems for extremely overweight goats. Tests show
that the largest goat in existence should be teleported in 50ms, so...
BUG=31337,2754
TEST=Try loading an overweight goat and confirm the teleporter works." 9
Si se van a realizar cambios sobre un código ya existente, Chromium aconseja discutir los cambios con los desarrolladores de ese código.
Se define también en la documentación del proyecto algunos “trucos” a la hora de hacer debug. Estas anotaciones vienen a resolver distintos problemas que suelen surgir cuando se intenta depurar este código, como por ejemplo:
“The sandbox can interfere with the internal symbolizer. Use --no-sandbox (but keep this temporary) or an external symbolizer (see tools/valgrind/asan/asan_symbolize.py).
Generally, do not use --no-sandbox on waterfall bots, sandbox testing is needed. Talk to [email protected] .”9
9 https://code.google.com/p/chromium/wiki/LinuxDebugging
13
3.4 Procesos a seguir para el cambio del código
Tras realizar un cambio en el código, el aftectado realizará una petición de revisión según lo indicado en el siguiente fragmento:
“Request review
Go to the supplied URL or just go to the respective code review page (Chromium) and click Issues created by me. Select the change you want to submit for review and click Edit Issue. Enter at least one reviewer's email address and click Update Issue. Now click on Publish+Mail Comments, add any optional notes, and send your change off for review. All Chromium code reviews are automatically cc'd to their respective review groups, so that everyone has an opportunity to see and comment on the changes being made.” 10
En el texto indica que hay que enviar la petición expresamente a un revisor que tenga conocimientos en el tema, para lo cual indica lo siguiente:
“Find a reviewer
Ideally, the reviewer is someone who is familiar with the area of code you are touching. If you have doubts, look at the svn blame or git blame for the file to see who else has been editing it. Failing that, ask on #chromium or #chromium-os on irc.freenode.net. You can also just request review from the respective lists (Chromium | Chromium OS), but more specific review requests will be attended to sooner. Your review must include one person from the OWNERS file for every directory you change code in.” 10
Tras esto comenzará la revisión propiamente dicha, y consistirá basicamente en una conversación, normalmente vía e-mail, entre el revisor y el propietario del código, que discutirán sobre dónde puede estar el problema y sus posibles soluciones:
"Chromium and Chromium OS reviewers try to review code that conforms to these guidelines as quickly as possible. You should hear back within 24-48 hours. Remember though, if you submit a giant patch, or do a bunch of work without discussing it with the relevant people, you may have a hard time convincing anyone to review it! [...]
10 http://www.chromium.org/developers/contributing‐code#TOC‐Request‐review
14
You will likely get email back from the reviewer with comments. Fix these and update the patch set in the issue by uploading again. The upload will explain that it is updating the current CL and ask you for a message explaining the change." 10
3.5 Estados por los que pasa el código
En primer lugar, el código pasa a formar parte de un CL (Change List) como se describe en el apartado “Gestión de los cambios”. Más tarde, cuando un revisor revisa un código, este pasa por dos estados distintos, dependiendo de qué opinión le merece el código en cuestión al susodicho:
• LGTM: El código es correcto y recibe la aprobación.
“When the reviewer is happy with your patch, they will say "LGTM" ("Looks Good To Me")”. […] You need approval from OWNERS of all affected files, either before committing (ex ante) or after committing (ex post).
LGTM gives ex ante approval, which is generally best, and if you have a LGTM from OWNERS of all affected files, you can commit the CL.”11
• TBR: En caso contrario al anterior, el código necesita ser revisado.
“Alternatively (instead of getting an LGTM), you can list the OWNERS in the TBR= "To Be Reviewed" field of the CL description, and they will review it after it has been committed. TBR is generally used either for urgent changes (when dcommitting), so the CL is reviewed but not blocked, or for routine changes, where it primarily functions as an FYI.
It is also possible to get an LGTM from some OWNERS and list others in TBR.” 11
3.6 Políticas para descartar, fomentar o retardar un cambio
Se deduce por lo anteriormente descrito que la decisión de qué hacer con un cambio reside en el revisor experto en el código del cambio propuesto (OWNER), ya que este es el que decide si hay que revisarlo o es correcto. Hasta que el revisor no dé su visto bueno el código quedará retrasado hasta su arreglo o descarte definitivo.
11 http://www.chromium.org/developers/contributing- code#TOC-Approval
15
3.7 Roles en la gestión del código
En la gestión del código existen los siguientes roles para la gestión de cambios en el código tenemos:
- Desarrolladores del código: Son aquellas personas encargadas de generar el
código de chromium.
- Revisores de código: Son desarrolladores especializados en áreas concretas
del código los cuales aprueban el código de otros desarrolladores.
En la gestión de la estructura del código existen los siguientes roles:
- Sheriff: Persona encargada del mantenimiento de la estructura del árbol donde se pueden destacar las siguientes funciones:
"Closes, throttles, and opens the tree Tracks down people responsible for breakage Backs out broken changes When idle, the sheriff: improves the tools, updates the doc, fix flaky tests, remove reliability signatures" 12
- Trooper: En cargados del mantenimiento de los buildBot Master en el siguiente texto se nos ofrece una definición de este rol en el proyecto:
"Troopers know more about maintaining the buildbot masters and slaves themselves. They're the people to look for when the bots need an OS update, a machine goes offline, checkouts are failing repeatedly, and so on. Chromium troopers: Please email chrome-troopers [at] google.com Refer to the rotation calendar to find the current trooper (look in "more details">"Guests")." 12
12 http://dev.chromium.org/developers/tree-sheriffs
16
- Gardener: Son las personas encargadas de la vigilancia de la liberación de los componentes y su desarrollo. Esta información la podemos encontrar en el siguiente texto.
"Gardeners are watchers of particular component interactions. They generally watch a component's release or development and move the version included forward when it is compatible. Of particular interest to the Chromium projects are the gardeners who watch the interaction between WebKit, Skia and Chromium, and those who watch the interaction of Chromium and ChromiumOS." 12
3.8 Políticas de nombres y estilo
El estilo de código utilizado en este proyecto es el seguido por la guía de estilo de google C++, dado que es el lenguaje predominante en el proyecto, este estilo lo podemos encontrar en la siguiente dirección http://google‐ styleguide.googlecode.com/svn/trunk/cppguide.xml además este estilo es flexible por lo que podemos variarlo.
Los archivos java utilizados por android deberían seguir la guía de estilo de Java que la podemos encontrar en http://source.android.com/source/code‐style.html.
En el siguiente texto se exponen las políticas seguidas en lo referente a la utilización de nombres:
""Chromium" is the name of the project, not the product, and should never appear in code, variable names, API names etc. Use "chrome" instead. Though the Google C++ Style Guide now says to use kConstantNaming for enums, Chromium was written using MACRO_STYLE naming. Continue to use this style for consistency. Unit tests and performance tests should be placed in the same directory as the functionality they're testing. Functions ending with a ForTesting suffix will be checked at presubmit time to ensure they're only called in a test situation."13
13 http://dev.chromium.org/developers/coding‐style
17
Un resumen de este texto es que el proyecto sigue MACRO_STYLE para nombrar los diferentes componentes de proyecto y las pruebas deben ir en el mismo directorio donde se encuentra la funcionalidad.
MACRO_STYLE es el modelo a seguir a la hora de crear instrucciones complejas en el código.14
Para el formateo del código se recomiendan las siguientes directrices explicadas en el siguiente texto:
"Put * and & by the type rather than the variable name. Always linebreak after a conditional, even if the body is only a return or other simple action. Wrap after binary operators, not before. Exception: when you have a log line that is longer than 80 characters, subsequent lines should start with the << operator and should be aligned based on the first << from the original line: VLOG(1) << "I have a long log message here, with variables like " << var1 << " and var2: " << var2;
When you derive from a base class, group any overriding functions in your header file in one labeled section. Use the OVERRIDE specifier on all these functions.
For function declarations and definitions, put each argument on a separate line unless the whole declaration fits on one line. void OK1(TypeA first_argument, TypeB second_argument, TypeC third_argument); void OK2(TypeA first_argument, TypeB second_argument, TypeC third_argument); Prefer (foo == 0) to (0 == foo).
Function declaration order should match function definition order. Prefer putting delegate classes in their own header files. Implementors of the delegate interface will often be included elsewhere, which will often cause more coupling with the header of the main class. Don't use else after return: if (foo) return 1; else return 2; if (foo) return 1; return 2; return foo ? 1 : 2;"15
14 http://es.wikipedia.org/wiki/Macro 15 http://dev.chromium.org/developers/coding‐style
18
3.9 Ejercicios
Ejercicio 1: Crear una rama a partir de la rama principal, cambiar alguna función (ej: exportación a pdf cambiar los margenes a 5 unidades) y comprobar que se puede cambiar de rama correctamente.
Introducir el siguiente comando: “git checkout -b branch_egc origin/master” donde branch_egc seria el nuevo branch para poder observar el branch que estamos utilizando utilizamos el comando “git branch”.
Después vamos a realizar la modificación en un fichero que contiene la rama creada anteriormente para ello realizamos los siguientes pasos:
1. localizamos el fichero a modificar.
19
2. Cambiamos el fichero.
→
3. Realizamos un commit local con la instrucción “git commit -a -v”, para ello
debemos identificarnos y después realizar el commit.
A continuación aplicamos el commit y tenemos:
20
Introducimos una breve descripción en una linea del cambio realizado y guardamos los cambios.
Después de salir tenemos:
y hemos acabado el ejercicio.
Ejercicio 2: Unir una rama a la branch principal localmente.
Para unir una rama al principal necesitamos la instrucción “git rebase origin/master” situados en el branch a unir:
21
Ejercicio 3: Eliminar la rama.
Para la eliminación de una rama es necesario la siguiente instrucción “git branch -d new_branch_egc” situado en la rama maestra.
Podemos ver como desaparece la rama new_branch_egc y nos muestra su SHA-1 por si queremos recuperarla.
22
4 GESTIÓN DE LA CONSTRUCCIÓN
Debido al tamaño y la complejidad del proyecto Chromium es necesario la utilización de herramientas que nos permitan realizar un check-out satisfactorio con lo que conlleva (Librerías, branches, versiones,..)
Las herramientas que utiliza Chromium son:16
Gclient17
Crear una revisión de código conlleva hacer pull sobre aproximadamente unos
100 repositorios de código SVN. Este proceso se lleva a cabo con la herramienta
gclient. Esta terminología se debe a la arquitectura en tres capas de Chromium.
Gyp
El sistema multiplataforma de configuración de la construcción que se utiliza es
gyp. Ejecutar gyp es análogo al paso ./configure que se realiza en la mayoría
del resto de software.
Ninja
Es un conjunto de herramientas agrupadas en una sola que permite la
construcción del proyecto completo en tiempos de ejecución que pocas
herramientas te lo permiten. El mayor componente de Ninja es Gold una
herramienta de link dinámico para librerías.
Chroot (opcional)
Con esta herramienta podemos aislarnos cambiando la el directorio raíz y el de
sus hijos para poder obtener una copia independiente y virtualizada del
entorno. Se suele utilizar para Testing.
16 https://code.google.com/p/chromium/wiki/LinuxBuildInstructions 17 https://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites
23
4.1 Cómo construir Chromium
Todo el análisis e investigación está hecho sobre Linux (Ubuntu) debido a las recomendaciones del proyecto Chromium.
4.1.1 Obtener un el código fuente para la construcción
Para la construcción del cualquier sistema el primer paso que se debe realizar es obtener todo el código necesario para su construcción, es decir, un instante del proyecto dentro de la máquina del tiempo. Para ello realizaremos la descarga del código fuente para la versión que estimemos oportunos.
Pre requisitos
Los requisitos necesarios a tener antes de obtener realizar un check-out son
tener instaladas las herramientas mencionadas con anterioridad. Lo ideal es
generar un sencillo programa de instalación que aglutine a todas las
herramientas para una instalación más sencilla y controlada. El proyecto
Chromium cuenta con este asistente de instalación y se denomina:
install-build-deps.sh
Obtención del código
Para la obtención del código debemos utilizar una de las herramientas
instaladas con anterioridad. Para el proyecto Chromium, se ha creado la
herramienta fetch que nos permite hacer un check-out:
fetch chromium --nosvn=True fetch blink --nosvn=True fetch android --nosvn=True fetch ios --nosvn=True 18
18 http://dev.chromium.org/developers/how‐tos/get‐the‐code
24
Con cualquiera de estas 4 operaciones obtendríamos el código referido a los
parámetros que se introducen. El parámetro “—nosvn=True” se realiza para
usuarios que no son commiters.
El parámetro que va detrás de fetch indica que parte del proyecto chromium
te descargas. Por ejemplo, fetch ios descargará el código de chromium para
ios.
4.1.2 Crear ficheros de construcción
Tras obtener el código fuente es necesario crear los ficheros de configuración necesarios para construir un proyecto de tal envergadura. El Proyecto Chromium nos ofrece una herramienta para tal acción. Esta herramienta es gyp_chromium. Esta herramienta prepara los ficheros que necesita la herramienta ninja para compilar19.
build/gyp_chromium.
Para la construcción se utilizará la herramienta ninja que es una herramienta propia del proyecto. Para mayor información podríamos afirmar que tiene un comportamiento similar en algunos aspectos a maven.
4.1.3 Construir Chrome
Para construir Chrome debemos utilizar la orden o comando Ninja, con él, se realiza la construcción de todo el entorno de Chrome.
Se puede crear en dos modos, Debug y Release. Modo Debug para pruebas y modo
Release versión final.
19 https://code.google.com/p/chromium/wiki/CommonBuildTasks#Configuring_the_Build
25
En concreto la instrucción para Debug es20:
ninja -C out/Debug chrome
En concreto la instrucción para Release es:
ninja -C out/Release chrome
4.1.4 Construir Test
Podemos construir todas las librerías y todos los componentes para realizar tests a todos los módulos del proyecto. La única diferencia es el directorio de salida. A través de este directorio ninja establece un modo u otro, es decir, modo Release o Debug.
Estas dos carpetas deben estar creadas o el proceso de construcción fallará20.
ninja -C out/Debug
Dentro de los test se pueden especificar qué tipo de test realizar algo necesario a la hora de construir los test ya que construir todos los test puede ser bastante costoso en tiempo. En el siguiente ejemplo comprobaremos como construir los test unitarios para Chrome20.
ninja -C out/Debug base_unittests
La utilidad de estos test es poder añadirlos a algún servidor de construcción continua para poder realizar los test automáticamente. Este servidor existe y se ve con detalle en el apartado 5.
20 https://code.google.com/p/chromium/wiki/LinuxFasterBuilds
26
4.2 Resultados obtenidos
Salidas obtenidas tras los procesos de construcción:
4.2.1 Modo Debug
Los ejecutables son escritos en src/out/Debug.
4.2.2 Modo Release
El modo reléase es la versión final de un entorno de pruebas, es decir, la versión que podríamos entregar al “cliente”.
Nos dirigiremos al directorio src/out/Release/ para construcciones de ejecutables en modo reléase.
4.3 Ejercicios
Para la realización de estos ejercicios se ha utilizado una máquina virtual sobre Virtual
Box (Versión 4.3.4) con el sistema operativo Ubuntu en su versión Ubuntu 12.04.3 LTS.
Todos los ejercicios que se muestran a continuación parten desde esta base.
Ejercicio 1: Construir todo el código fuente de Chromium.
Consiste en el ejercicio básico de gestión de la construcción. En este sentido consiste en compilar el código.
27
Ejercicio 2: Realizar un cambio en el código y construir para comprobar los errores.
Para la realización de este ejercicio se ha eliminado la carpeta de la extensión “Google
Drive” y se ha realizado la compilación, obteniendo el resultado de error esperado. El objetivo es entender que para la compilación completa de Chrome es necesario todo el código fuente. Este ejercicio también se ha utilizado para el chequeo de errores.
Ejercicio 3: Crear una prueba unitaria y construirla.
Para este ejercicio hemos creado una prueba en JAVA a partir de las pruebas ya existentes en Chromium, esta prueba consiste en probar los diferentes Layout disponibles en Android para un correcto funcionamiento de Chrome. A Continuación se muestran las imágenes de la creación del test.
Como se puede comprobar en el ejemplo en este test se probará Chrome sobre un
Relative Layout. También se podrían crear pruebas a través del framework desarrollado por Google para test gtest.
En la siguiente ilustración podremos ver la creación de los test unitarios:
28
Test Chrome Android
Creación test unitarios
29
Ejercicio 4: Construir una nueva reléase con alguna modificación.
Para la realización de este ejercicio tomaremos como base el ejercicio número 1 del apartado gestión del código fuente en el cuál se cambió en la versión para Android de
Chromium los márgenes a un valor fijo de 5 unidades para la exportación que realiza
Chromium de páginas webs a PDF.
Tras efectuar los cambios en el código indicados anteriormente pasamos a construir
Chromium de la siguiente manera
1. Ejecutamos el siguiente comando para generar los ficheros de construcción.
build/gyp_chromium
2. A continuación, construimos Chrome a partir de Chromium y del cambio realizado en el código fuente con anterioridad
ninja -C out/Debug chrome
Este proceso puede tardar varias horas, en la imagen de a continuación se
muestra el resultado tras dos horas.
Proceso después de tres horas:
30
Proceso finalizado
3. Después del proceso de compilación y construcción de Chrome
Resultado de la compilación
31
5 CONSTRUCCIÓN E INTEGRACIÓN CONTINUA
El proceso de construcción e integración continua de Chromium está basado en un proceso automatizado llevado a cabo por Buildbot, como podemos ver en las ilustraciones 4 y 5 (Ver apartado 5.1). Este proceso comienza con los servidores masters de Buildbot observando en los repositorios de git y subversion para nuevas revisiones del código. Aunque pueda parecer ineficiente por estar continuamente
“escuchando” en los servidores de SVN de tercer nivel, este proceso de escucha continua a los servidores está diseñado así debido a que solo las personas con rol de
“commiters” pueden realizar cambios en las revisiones del código y por tanto la construcción está relativamente controlada.
Ilustración 4 Muestra de la continua búsqueda de nuevas revisiones en el código por parte del servidor Master
32
Tras la revisión de los repositorios por parte de los servidores master, si estos detectan nuevas revisiones de código lanzan la ejecución de sus servidores “slaves” para que empiecen la construcción. Por ejemplo imaginemos que el servidor master principal (que se denomina Chromium Continuous) detecta nueva revisiones, entonces lanzaría todos los servidores “slaves” que se encuentran vinculados a este master. La gran mayoría son los diferentes sistemas operativos existentes y se denominan
“Linux”, “Win” y “Mac”. Cada uno de ellos empezaría a construir Chromium en Linux,
Windows y Mac en función a los últimos commits obtenidos en los repositorios de código escuchados.
Por razones de escalabilidad los servidores “slaves” y “master” se encuentran en equipos diferentes. Tras la ejecución se muestra en el servidor Waterfall (ver
Ilustración 6) los resultados obtenidos de lanzar todas las pruebas establecidas en la construcción en relación a los diferentes “slaves” establecidos.
Buildbot se encarga del proceso de construcción continua y de realización de test.
Existen diferentes estados en el árbol o máquina del tiempo de la construcción:
Abierto: Es el estado normal. Acepta “commits” ilimitados por parte de
cualquier persona que tenga rol de “commiter”.
Cerrado: Cuando una prueba falla o se un produce un error en la construcción
en cualquiera de los “slaves” o “Tree closers”, (slaves fundamentales que
pueden cerrar el árbol), se establece este estado, impidiendo los commits y se
avisa al denominado “build sheriff”. Este rol se denomina para las personas
33
destinadas al control de la construcción y a los responsables del servidor que
ha provocado el fallo.
En este estado solo las personas con el rol de “build sheriff” pueden realizar
acciones sobre el código para arreglar el fallo producido. Estos cambios pueden
ser nuevos commits, revertir algún commit, etc...
Estrangulado: Cuando el sistema se encuentra en este estado se establece un
límite de “commits” para personas con el rol de “build sheriff”. Con esta acción
se quiere mantener la integridad del proceso.
En las distintas imágenes que se ofrecen en este apartado se muestran los diferentes estados del árbol y el árbol oficial de Chromium se encuentra en: http://build.chromium.org/p/chromium/waterfall
34
5.1 Definición de BuildBot
“Buildbot is a software development continuous integration tool which automates the compile/test cycle required to validate changes to the projectcode base. It began as a light- weight alternative to the Mozilla project's Tinderbox, and is now used at Mozilla, Chromium and many other projects” 21
Ilustración 5 Arquitectura de BuildBot
“At its core, Buildbot is a job scheduling system: it queues jobs, executes the jobs when the required resources are available, and reports the results.
Your Buildbot installation has one or more masters and a collection of slaves. The masters monitor source-code repositories for changes, coordinate the activities of the slaves, and report results to users and developers. Slaves run on a variety of operating systems.
You configure Buildbot by providing a Python configuration script to the master. This script can be very simple, configuring built-in components, but the full expressive power of Python is available. This allows dynamic generation of configuration, customized components, and anything else you can devise.
The framework itself is implemented in Twisted Python, and compatible with all major operating systems.” 22
21 http://en.wikipedia.org/wiki/Buildbot 22 http://buildbot.net/
35
5.2 Instalación de BuildBot
Para una instalación del servidor BuildBot es aconsejable realizarla en Linux ya que es más fácil, cómodo y generará muchos menos inconvenientes que en Windows a la hora de tener un Master y un Slave.
Pasos a seguir23:
1. En el directorio donde se quiera construir ejecutar los siguientes comandos: mkdir tools && cd tools Creamos una carpeta para alojar el buildbot gclient config --git-deps https://chromium.googlesource.com/chromium/tools/build.git gclient sync Añadimos a la herramienta gclient el repositorio en el que se encuentra
BuildBot y sincronizamos para descargar todo lo necesario
2. Crear un fichero de contraseña para poder conectar tu servidor slave con el master: echo password > build/site_config/.bot_password
3. Añadir los test que deseen realizar en la sección FACTORIES del archivo master.cfg(Optional) Para identificar los test debemos buscarlos en el fichero scripts/master/factory/chromium_factory.py
4. Dentro del master que se desee arrancar debemos lanzar el comando make restart, por ejemplo, dentro del directorio /masters elegimos el master experimental (master.experimental) y dentro de ese directorio lanzamos el comando make restart Si la ejecución de este comando nos muestra un error relacionado con tener instalado gclient o depot_tools debemos instalar depot_tools en el directorio superior /build con esta instrucción:
23 Las instrucciones se han obtenido de http://dev.chromium.org/developers/testing/chromium‐build‐ infrastructure/getting‐the‐buildbot‐source/configuring‐your‐buildbot
36
svn co http://src.chromium.org/chrome/trunk/tools/depot_tools
5. Tras la finalización del paso anterior el master debería estar corriendo ya con una apariencia de este modo.
Últimos commits
Ilustración 6 Waterfall
Ilustración 7 Waterfall
37
Ilustración 8 Waterfall Grande
38
5.3 Ejercicios
Para la realización de estos ejercicios se ha utilizado una máquina virtual sobre Virtual
Box (Versión 4.3.4) con el sistema operativo Ubuntu en su versión Ubuntu 12.04.3
LTS. Todos los ejercicios que se muestran a continuación parten desde esta base.
Ejercicio 1: Construya un servidor BuildBot a través del cual se ejecute un servicio master que lea los servidores gestores del código fuente.
El principal objetivo de este ejercicio es analizar como es el funcionamiento y la instalación de BuildBot aunque como conclusión que hemos obtenido al realizar el análisis completo hemos llegado a la conclusión de que contar con un servidor
BuildBot propio es una gran herramienta para comprobar que los cambios que puedes realizar sobre el código no afectan a la estructura del proyecto. Esto se debe a que podríamos añadir nuestro servidores SVN a la lista de servidores escuchados por
BuildBot para que construya, integre y realice todas las pruebas que se realizan de forma oficial, con lo cual podríamos tener un propio navegador Chome modificado por nosotros pero que pasé todos los test oficiales de Chromium Project.
Para resolver este ejercicio en primer lugar debemos crearnos un directorio en el cual almacenar todo el proceso de construcción y todos los ficheros relacionados con
Buildbot. Tras este paso inicial debemos irnos al master que deseamos ejecutar y lanzarlo. Veremos la secuencia del ejercicio con más detalle a continuación.
1. Crear carpeta en la que almacenar todo lo necesario
mkdir tools && cd tolos
2. Indicamos que queremos obtener las herramientas de construcción a la herramienta gclient añadiendo la dependencia de git
gclient config --git-deps https://chromium.googlesource.com/chromium/tools/build.git
3. Sincronizamos para obtener las herramientas de construcción
gclient sync
A Continuación mostramos imágenes de cómo se ha realizado.
Ilustración 9 Sincronización herramientas
4. Introducimos una contraseña para el master
echo password > build/site_config/.bot_password
40
5. Seleccionamos el master que deseamos lanzar (Máster de Chromium) y a continuación dentro del directorio del master seleccionado lanzamos el comando:
make restart Con este comando arrancamos el servidor
Ilustración 10 Arranque del master de BuildBot
41
Tras este paso ya podemos ver el servidor master corriendo en nuestro equipo
Ilustración 11 Resultado Final de la instalación de BuildBot
42
6 GESTIÓN DE ENTREGABLES
Los elementos entregables del proyecto Chromium son dos: el navegador Google
Chrome, desarrollado por Google Inc., y la versión más actual del código en sí, ya que se trata de un proyecto de código libre.
6.1 Cómo se generan
Para la generación de entregables tenemos 2 métodos:
1. El primer método seria la compilación del código de chromium del cual
tenemos como resultado el chrome.
2. El segundo método es la inclusión del código local en el código principal donde
al cabo de un cierto tiempo se incluyen en la siguiente versión.
6.2 Cómo se identifican
Los entregables se liberan con una combinación de cuatro dígitos que se van actualizando según los cambios que se generen en el mismo. La información concreta viene descrita en el siguiente texto:
“Chromium version numbers consist of 4 parts: MAJOR.MINOR.BUILD.PATCH. • MAJOR and MINOR may get updated with any significant Google Chrome release (Beta or Stable update). MAJOR must get updated for any backwards incompatible user data change (since this data survives updates). • BUILD must get updated whenever a release candidate is built from the current trunk (at least weekly for Dev channel release candidates). The BUILD number is an ever-increasing number representing a point in time of the Chromium trunk. • PATCH must get updated whenever a release candidate is built from the BUILD branch. MAJOR and MINOR track updates to the Google Chrome stable channel. In this sense, they reflect a scheduling or marketing decision rather than anything about the code itself. These numbers are generally only significant for tracking milestones. In the event that we get a significant release vehicle for Chromium code other than Google Chrome, we can revisit the versioning scheme. The BUILD and PATCH numbers together are the canonical representation of what code is in a given release. 43
The BUILD number is always increasing as the source code trunk advances, so build 180 is always newer code than build 177. The PATCH number is always increasing for a given BUILD. Developers and testers generally refer to an instance of the product (Chromium or Google Chrome) as BUILD.PATCH. It is the shortest unambiguous name for a build. For example, the 154 branch was originally released as 0.3.154.9, but now stands at 1.0.154.65. It's the same basic code with a lot of bug fixes applied. The fact that it went from a Beta release to several 1.0 stable releases just reflects the decision to call some version (1.0.154.36) 'out of Beta'.”24
6.3 Cómo se gestiona la publicación
La publicación se realiza de la siguiente forma: Las versiones del código son liberadas en los meses de Diciembre, Febrero, Marzo, Mayo, Junio, Agosto Septiembre y
Noviembre en algún lunes de una de sus semanas.
El versionado que se sigue en este proyecto para los entregables del código está establecido según los diferentes canales que dispone para cada plataforma.
Teniendo que existen 4 canales (dev, beta, stable, canary) estos canales se encuentran en todas las plataformas y cada uno puede poseer una determinada versión de chromium por ejemplo para la plataforma Windows tenemos la versión estable sería la 31.0.1650.63 mientras que la beta sería 32.0.1700.68, en el canal de desarrollo podemos encontrar la 33.0.1750.3 y en el canal canary tenemos la versión
34.0.1752.0. Como podemos comprobar utilizan una estructuración de versión basada en 4 parámetros donde el parámetro mayor es la versión que será liberada.
Para el versionado de chrome se sigue el versionado del código.
Se puede obtener más información visitando las páginas:
http://dev.chromium.org/developers/calendar http://dev.chromium.org/getting-involved/dev-channel
24 http://www.chromium.org/developers/version-numbers 44
6.4 Dónde se publican los entregables
Cuando se libera una nueva versión del navegador y del código, estos se publican en la página oficial de Google Inc. (https://www.google.com/intl/es/chrome/browser/?hl=es) y en el servidor svn respectivamente. La información de cómo obtener el código se encuentra en la siguiente sección: http://www.chromium.org/developers/how‐tos/get‐the‐code.
También podemos encontrar las diferentes versiones y en que canal se encuentran en la siguiente dirección http://dev.chromium.org/developers/calendar.
6.5 Ejercicios
• Ejercicio 1: Identificar los principales entregables, su generación y el periodo
en el que se publican.
Los principales entregables son el código generado mediante la aceptación e
inclusión de los diferentes repositorios git de los desarrolladores y los objetos
generados a partir de la compilación del código los cuales siguen el mismo
versionado que el código. La fecha de publicación de estos entregables es un
lunes de los siguientes meses: Diciembre, Febrero, Marzo, Mayo, Junio, Agosto,
Septiembre o Noviembre.
45
7 GESTIÓN DEL DESPLIEGUE
El despliegue, es decir, el cojunto de actividades a realizar con el fín de que nuestro software esté disponible para su uso, varía según la plataforma en la que queramos disponer de chromium (chrome); según el tipo de sistema operativo se desplegará de una manera u otra. Nosotros nos centraremos en Linux. También, como se explica en el desarrollo de la construcción, destacar que, como se ha comentado anteriormente, la principal herramienta utilizada para el despliegue es Ninja.
7.1 Integración / despliegue continuos
Chromium nos ofrece los llamados “reléase channels” o “canales de lanzamientos”.
Dicho medio es usado por Chromium para llevar a los usuarios poco a poco los cambios que se realicen. Dicho periodo de “actualización” va desde casi diariamente de los “Canary Channels” a unas 6 semanas en los “Stable Channels” o canales estables:
"Stable channel: This channel has gotten the full testing and blessing of the Chrome test team, and is the best bet to avoid crashes and other issues. It's updated roughly every two-three weeks for minor releases, and every 6 weeks for major releases.
Beta channel: If you are interested in seeing what's next, with minimal risk, Beta channel is the place to be. It's updated every week roughly, with major updates coming every six weeks, more than a month before the Stable channel will get them.
Dev channel: Want to see what's happening quickly, then you want the Dev channel. The Dev channel gets updated once or twice weekly, and it shows what we're working on right now. There's no lag between major versions, whatever code we've got, you will get. While this build does get tested, it is still subject to bugs, as we want people to see what's new as soon as possible.
Canary build: Canary builds are the bleeding edge. Released daily, this build has not been tested or used, it's released as soon as it's built. Because there's no guarantee that it will even run in some cases, it uses it's own profile and settings, and can be run side by side another Chrome channel. By default, it also reports crashes and usage statistics to Google (you can disable this on the download page)." 25
46
Chromium ofrece una descripción de qué significan estos canales:
"How do I choose which channel to use?
The release channels for chrome range from the most stable and tested (Stable channel) to completely untested and likely least stable (Canary channel). Note, you can run the Canary channel builds alongside any other channel, as they do not share profiles with other channels. This allows you to play with our latest code, while still keeping a tested version of Chrome around." 25
Los canales que actualmente existen son:
Ilustración 2 : http://www.chromium.org/getting‐involved/dev‐channel
Una vez seleccionas uno de los canales, se te ofrecerá la última reléase /construcción disponible.
25 http://www.chromium.org/getting‐involved/dev‐channel 47
7.2 Mecanismos y procesos de despliegue
Como hemos mencionado en apartados anteriores, llamamos release a una versión de lanzamiento (o liberación), es decir, que el software, en nuestro caso una versión de chromium, se hace público.
En Linux, tenemos 3 modos de obtener un release:
1) Descargando el último release disponible. En este primer caso, obtendremos
directamente ya una versión desplegada de Chromium, siguiendo los siguientes
pasos:
a) En un terminal ejecutaremos el siguiente comando:
sudo add-apt-repository ppa:chromium-daily
De esta manera, añadimos un PPA (Personal Package Archives) a nuestra
lista de fuentes, de tal manera que, en nuestro caso Ubuntu, será capaz de
buscar actualizaciones que provengan de dicha fuente o repositorio,
además de aquellas fuentes oficiales de Ubuntu.
Así, ahora podremos bajarnos sin problemas archivos que provengan del
repositorio "chromium-daily", en este caso.
Y entonces, ¿qué hay en este chromium-daily? Pues corresponde al canal
estable (stable channel) para Linux de Chrome, que, como ya decíamos en
el apartado 5.4 (Cómo se gestiona la publicación) de este documento es
uno de los 4 tipos de canales de lanzamiento o "release channels" de
Chrome.
He aquí una descripción detallada de éste PPA:
48
Descripción del PPA: Chromium - Stable Channel26
b) Tras esto, actualizamos los repositorios, haciendo efectiva la inclusión de
chromium-daily entre ellos:
sudo apt-get update
c) Hecho esto podremos proceder a instalar Chromium, como si de otra
aplicación se tratara introduciendo el siguiente comando en consola:
sudo apt-get install chromium-browser
Así, nos traeremos e instalaremos el último reléase disponible. En
cuanto a cuál será y si podemos elegir un reléase en concreto, hablaremos
en el tema de despliegue continuo.
26 https://launchpad.net/~chromium‐daily/+archive/stable 49
2) Descargando la release a través de code.google.com. Otra manera de
obtener una versión funcionante de Chromium es seleccionando la release
adecuada para nuestra distro de linux de entre las opciones disponibles en el
siguiente enlace:
https://code.google.com/p/chromium/wiki/LinuxChromiumPackages
3) Desplegando Chromium. Un tercer y más interesante modo de adquirir una
version operativa de nuestro navegador es desplegando nuestro "propio"
código.
Nótese que es necesario para ello obtener el código fuente y construirlo, y
luego el uso de la herramienta ninja.
Todos los pasos necesarios para el despliegue han sido explicados en el
apartado 4.2 (Gestión de la Construcción).
7.3 Establecer los permisos (policy)
Esta sección se centra en, suponiendo que se instala chrome o chromium en una organización, establecer qué permisos (policies) podrá tener una máquina concreta, es decir, limitar qué podrá o no hacer desde el navegador instalado en un computador.
Todos los ficheros de configuración de la policy se encuentran en el directorio
/etc/chromium (para Chromium) o /etc/opt/chrome (para Google Chrome).
Hay dos conjuntos de policies en estos directorios: uno que es necesario para y usado por el administrador, y un conjunto que es recomendado para los usuarios pero no es obligatorio. Dichos conjuntos se encuentran en:
/etc/opt/chrome/policies/managed/
/etc/opt/chrome/policies/recommended/
50
De tal manera que el primer directorio deberá tener los permisos del administrador o administradores, que presumiblemente dispondrá de todos o casi todos los permisos y deberá gestionar aquellos del resto de usuarios, que estarán en la carpeta recommended de sus máquinas correspondientes. Así pues, dichos directorios deberán ser creados si es que no existen:
>mkdir /etc/opt/chrome/policies
>mkdir /etc/opt/chrome/policies/managed
>mkdir /etc/opt/chrome/policies/recommended
Cabe decir que es necesario asegurarse de que los archivos bajo el directorio /managed
(es decir, de los usuarios "normales") no deberán ser escribibles por usuarios que no sean administradores, ya que en caso contrario podrían modificar ellos sus propios permisos a su antojo, ya que el administrador es el único que debe poder otorgar o quitar permisos a un usuario.
>chmod -w /etc/opt/chrome/policies/managed
Para establecer las policies obligatorias, es decir, aquellas acciones que un usuario tenga derecho (o no ) a realizar, crear un archivo llamado “test_policy.json” en :
/etc/opt/chrome/policies/managed/
>touch/etc/opt/chrome/policies/managed/test_policy.json
Y escribir en él lo siguiente:
{ "HomepageLocation": "www.chromium.org" }
Así, la próxima vez que se inicie Google Chrome en tal máquina, la página de inicio estará bloqueada a este valor.
51
Dicho archivo podrá ser modificado por el administrador en remoto mediante mecanismos de push-filing, por ejemplo, de tal manera que si el administrador desea modificar (o crear) los permisos de uno o varios usuarios le baste sobreescribir o crear el archivo test_policy.json en el ordenador remoto, en este caso, el del usuario.
Se pueden muchos más permisos, por ejemplo, en Google Chrome 32, para los permisos de accesibilidad:
Policy Name Description
Accessibility settings
ShowAccessibilityOptionsInSystemTrayMenu Show accessibility options in system tray menu
LargeCursorEnabled Enable large cursor
SpokenFeedbackEnabled Enable spoken feedback
HighContrastEnabled Enable high contrast mode
ScreenMagnifierType Set screen magnifier type
DeviceLoginScreenDefaultLargeCursorEnabled Set default state of the large cursor on the login screen
DeviceLoginScreenDefaultSpokenFeedbackEnabled Set the default state of spoken feedback on the login screen
DeviceLoginScreenDefaultHighContrastEnabled Set the default state of high contrast mode on the login screen
DeviceLoginScreenDefaultScreenMagnifierType Set the default screen magnifier type enabled on the login screen
La información de la tabla se encuentra en la siguiente url, donde también pueden verlas todas al completo con sus respectivas descripciones: http://www.chromium.org/administrators/policy-list-3
Por último, cabe señalar que deberá existir un mecanismo mediante el cual el administrador envíe (haga push) a los demás usuarios para asi configurar los navegadores con los respectivos permisos.
52
8 GESTIÓN DE INCIDENCIAS Y DEPURACIÓN
En este apartado haremos un estudio del sistema que usa el proyecto Chromium para llevar a cabo el reporte y la solución de incidencias y qué herramientas se usan para la depuración del código una vez identificado un error.
Hablando de la gestión de incidencias, principalmente, veremos que se usa una aplicación de Google donde se exponen las diferentes incidencias encontradas a modo de lista, a la espera de que un reviewer la atienda y nos ayude a solucionarla. A priori puede parecer poco útil ya que parece no contar con funciones de seguimiento de las incidencias, pero indagando un poco más podemos encontrar todas las herramientas que la aplicación nos brinda.
Por otro lado, para la depuración del código, la herramienta estándar del proyecto es
GDB, la cual trabaja por consola y nos ofrece distintos comandos para depurar un programa ya compilado. No se tiene constancia por lo investigado en la documentación del proyecto que el uso de esta herramienta sea un requisito a la hora de depurar, por lo que se entiende que los afectados en última instancia utilizarán su herramienta preferida dado el caso.
8.1 Gestión de incidencias
Como comentábamos al principio, a la hora de generar una incidencia los desarrolladores del proyecto Chromium cuentan con una herramienta en forma de aplicación web desarrollada por el propio Google. Esta herramienta dispone de todos los utensilios que podremos necesitar a la hora de reportar, seguir y monitorear el estado de una incidencia, tales como estados para la incidencia, subida de archivos adjuntos, y un sistema de comentarios que será el modo principal de comunicación de los usuarios a la hora de resolver el problema.
53
8.1.1 Estados posibles para una incidencia (bugs)
Para comprender los distintos estados por los que pasa un bug reportado, en la página nos ofrecen información al respecto, ya que, por un lado estarían los bugs en estados abiertos, los cuales todavía no han sido resueltos:
Y por otro, están los bugs ya resuelto, que dependiendo de qué solución tuvieron y cómo afectan al proyecto, tendrán un estado u otro del mismo modo:
Estos estados se suceden como es usual en un llamado ciclo de vida, los cuales vienen detallados en la misma página:
“Bug life cycle When a bug is first logged, it is given Unconfirmed status. The status is changed from unconfirmed to Untriaged once it has been verified as a Chromium bug. 54
Once a bug has been picked up by a developer, it is marked as Assigned. A status of Started means a fix is being worked on. A status of Fixed means that the bug has been fixed, and Verified means that the fix has been tested and confirmed. Please note that it will take some time for the "fix" to make it into the various channels (canary, beta, release) - pay attention to the milestone attached to the bug, and compare it to chrome://version.”27
La información y las tablas han sido sacadas de la misma página que la anterior cita.
8.1.2 Creación de una incidencia
Se accede a la creación de una incidencia mediante el previo registro de una cuenta con el dominio gmail tras lo que podremos dirigirnos a la url https://code.google.com/p/chromium/issues/entry que directamente nos abrirá una ventana que nos permite registrar una incidencia:
27 http://www.chromium.org/for‐testers/bug‐reporting‐guidelines 55
Como podemos observar en la imagen, tendremos que incluir en el reporte una serie de campos, los cuales vienen descritos en el campo Description por defecto. En este caso, el reporte estaba a nombre de la cuenta logueada en el navegador en ese momento, por lo que vemos que el reporter se incluye por defecto desde el perfil de usuario que se encuentre activo en ese momento.
Tras esto, la incidencia quedará registrada en el listado, al cual podremos acceder mediante la url https://code.google.com/p/chromium/issues/list. Destacar que este listado es únicamente para las incidencias del desarrollo de Chrome, existiendo otro distinto para el de Chrome OS.
8.1.3 Resolución de una incidencia
Una vez que la incidencia ha sido reportada exitosamente y está registrada en la anterior lista, comenzará el proceso de resolución de la incidencia. Se trata de un proceso como el que puede seguir cualquier otra herramienta de resolución de incidencias, es decir, siguiendo el ciclo de vida de una incidencia anteriormente comentado:
En un principio la incidencia está sin confirmar (unconfirmed).
Alguien la valida y comprueba su veracidad (untriaged).
Después se clasifica (available).
Se asigna a un revisor (assigned), definido como owner en la aplicación.
Cuando este comienza a trabajar en ella, actualiza de nuevo su estado
(started).
Una vez en ese punto, el owner o persona asignada a ella, comienza a trabajar en la resolución de la incidencia con la ayuda de otros usuarios de la comunidad de confianza o que se ofrezcan a ayudarle, intercambiando mensajes a través del sistema de mensajes de la propia aplicación, que actúa como un foro para cada incidencia. 56
Nota: se ha tratado de explicar lo más minuciosamente posible el proceso anterior ya que no consideramos factible añadir un ejercicio tratando este tema, ya que se interactúa con una comunidad de desarrolladores real.
8.2 Mecanismos de depuración
Para la depuración del proyecto se usa la herramienta GDB, creada por los desarrolladores del proyecto GNU para tal fin. La descripción de la herramienta es bastante simple y se puede encontrar en su página web:
“GDB, the GNU Project debugger, allows you to see what is going on ‘inside’ another program while it executes -- or what another program was doing at the moment it crashed. GDB can do four main kinds of things (plus other things in support of these) to help you catch bugs in the act: Start your program, specifying anything that might affect its behavior. Make your program stop on specified conditions. Examine what has happened, when your program has stopped. Change things in your program, so you can experiment with correcting the effects of one bug and go on to learn about another. The program being debugged can be written in Ada, C, C++, Objective-C, Pascal (and many other languages). Those programs might be executing on the same machine as GDB (native) or on another machine (remote). GDB can run on most popular UNIX and Microsoft Windows variants.”28
Existe también en la misma página, la documentación de dicha herramienta, que podemos encontrar en https://www.gnu.org/software/gdb/documentation/, donde podemos encontrar toda la información necesaria para su uso.
En resumen, este es un debugger por consola, el cual nos permite acceder al código de forma clara y limpia del siguiente modo:
1. Nos ubicamos en la carpeta que contiene el fichero de código al que queremos
hacer debug.
2. En un terminal, escribimos "gdb
28 https://www.gnu.org/software/gdb/ 57
3. Entraremos en el prompt de la herramienta gdb, tras lo cual ya podemos
interactuar con el programa añadiendo breakpoints donde consideremos
necesario, evitando los molestos printf que ensuacian nuestro código, con el
comando break
4. Una vez que tenemos el programa preparado con breakpoints, lo ejecutamos
con el comando run, y a continuación veremos como la ejecución se detiene en
el punto especificado.
5. En este momento, podremos observar el código ejecutado, y mediante los
comandos print
variables y depurar nuestro código.
8.3 Ejercicios
Ejercicio 1: Haremos un pequeño programa en C++ para ejemplificar el uso de la herramienta gdb partiendo del siguiente fragmento de código:
58
A partir de esto, lo compilamos y abrimos el ejecutable con la herramienta gdb del siguiente modo:
Nota: Comentar que para el caso de C, C++ y similares, es necesaria la indicada opción de compilación
"-ggdb" para que la compilación incluya información de debug específica para la herramienta gdb. Esta información ha sido extraída del manual de linux (man gcc).
Observamos que al ejecutar el comando run, nos da un error ya que, en efecto el programa tiene un (evidente) error.
Ahora procedamos a hacer debug, creando un breakpoint donde creemos que puede estar el error y ejecutando el programa:
59
Al introducir el breakpoint el programa detiene su ejecución y podemos observar los valores de las variables y en efecto ver que estamos dividiendo por cero, y de este modo corregir el problema.
9 GESTIÓN DE LA VARIABILIDAD
En lo que respecta la variabilidad desarrollaremos un informe detallado de los modelos tanto el de variabilidad y como el característico.
9.1 Modelo de variabilidad
En Chrome podemos observar como partimos de lo que sería de un conjunto de elementos mínimos que sería el navegador en sí al cual se le agregan elementos adicionales. Para ello se accede a la web store de Chrome donde podremos encontrar dichas extensiones las cuales se auto instalan en el navegador.
60
Por tanto usa un modelo de variabilidad positiva; en este proyecto no tendría cabida la variabilidad negativa ya que de ser así tendríamos un paquete principal demasiado grande y en constante expansión, y no habría tantas facilidades a la hora de desarrollar, publicar y añadir nuevas extensiones.
9.2 Modelo de Características
El modelo de características de Chrome, debido a la variabilidad positiva es bastante sencillo:
Lógicamente la instalación de algunas extensiones implicará que ya existan otras pero de forma general este es el modelo de características que se sigue.
Por otra parte cabe destacar que no existe modelo de características entre versiones puesto que la forma que Chrome tiene de liberar distintas versiones, como se ha comentado anteriormente, no está basada en la adición de nuevas funcionalidades o características comunes, si no que a cada aproximadamente 6 meses se libera una versión nueva.
61
9.3 Ejercicio
Dado el siguiente conjunto de supuestas características de Chrome realizada un modelo característico que lo refleje, teniendo como núcleo Chrome.
1. Temas: podemos instalar distintos temas en Chrome, en este supuesto
utilizaremos tres tipos: oro y plata
2. Gmail: herramienta de correo electrónico que sirve para gestionar correo
propio y en muchos casos es utilizada como LDAP
3. aTube Catcher: extensión con la que podemos descargar video de Youtube
pero antes de poder utilizarla debemos tener correo Gmail
4. Media: podemos instalar Spotify para escuchar música y Real Player para ver
videos, pero para que funciones antes debemos tener instalado el Adobe Flash
5. Adobe: Adobe nos permite ver videos con adobe flash y leer documentos con
Adobe Reader.
Solución
62
10 MAPA DE HERRAMIENTAS
Dependiendo del sistema operativo se usarán unas herramientas u otras. Nosotros hemos decidido implantar el sistema y las herramientas que usan los desarrolladores principales de Chromium (Linux). También aportamos unos gráficos de como se usarían las distintas herramientas en los distintos sistemas operativos. Ya se hizo en el apartado 4 una enumeración de algunas de estas herramientas, per en esto caso añadiremos la totalidad de ellas:
• Ninja – Es un sistema de construcción por lineas de comando que es mucho
más rápido que construir desde IDEs o Xcode.
• gclient – Es el conjunto de funcionalidades que nos permite interactuar en los
todos los proyectos como uno sólo – para instanciar, usamos "gclient sync" y
"gclient runhooks" a veces.
• GYP – Esta herramienta genera nuestros archivos de proyecto para usar Ninja,
Visual Studio y/o Xcode. Corre bajo gclient, normalmente no se instancia
directamente. Los archivos .gyp se forman a partir de los archivos de
construcción de otros proyectos.
• Git, subversion – El repositorio base usa subversion, pero mucha gente usa git
como gestor. Hay trabajo en proceso para mover el repositorio entero a git.
• GDB – Herramienta de debug del proyecto GNU.
• DiffMerge – Herramienta gráfica para ver los cambios antes de haccer un
commit a tu branch. Se puede enganchar y hacer que funcione en Git y
Subversion. Hay otras herramientas similares, pero esta es la única que está
soportada por todas las plataformas de desarrollo.
63
• Editor extensions – Emacs tiene extensiones para hacer el desarrollo de
chromium más fácil. Se pueden encontrar aquí:
http://code.google.com/p/chromium/wiki/Emacs
Diagrama 1: Esquema de herramientas en Mac OS X
Sistema operativo: Mac OS X Snow Leopard
Chromium Dep Tools XCode Git SVN
Nota: Si no aparecen en los diagramas alguna de las herramientas anteriormente mencionados es o bien porque van incluidas dentro de las de Chromium (Ninja, Gyp, etc.) o porque vienen con el sistema (Emacs, GDB).
64
Diagrama 2: Esquema de herramientas en Windows
Sistema operativo: Windows 7 x64
Make patch Windows Driver Kit Chromium Dep Tools Python DirectX SDK June 2010 Visual Studio 2010 Windows 8 SDK
Git SVN
Chromium
Diagrama 3: Esquema de herramientas en Linux
Sistema operativo: Cualquier Linux
GClient Gyp Ninja Python Git SVN
65
11 CONCLUSIONES
Después de analizar en profundidad la gestión de este proyecto podemos concluir que resulta difícil introducirse al manejo de las herramientas y las denominaciones de las partes que conforman dicho proyecto, pero después de tratar con ellas durante el tiempo de realización del trabajo resulta más fácil manejarlas. También resultaría más fácil unirse al proyecto como colaborador ya que conocemos los mecanismos; cosa que costaría mucho más si no hubiéramos hecho el análisis de la gestión del proyecto. En resumen, el proyecto Chromium puede resultar confuso y dificultoso al principio pero una vez te metes a conocer aspectos más técnicos acabas por hacerte con el manejo de sus herramientas y técnicas de desarrollo.
12 ANEXOS
Junto al documento del trabajo se adjuntan el diario de grupo y las actas de reunión.
66