Ejudge

1.  Introdução

1.1  Visão Geral

A plano de Gerência de Configuração de Software(GCS) será usado para refletir as necessidade de GCS do projeto ejudge. Tal projeto está sendo desenvolvido e mantido pelo professor Edson Alves da Universidade de Brasília, sendo a principal função do projeto facilitar a correção de provas de programação e também implementar um ambiente real de maratona de programação. Para implementar tais funcionalidade, o ejudge possui atualmente sete módulos;

• checker: script responsável por realizar as correções automáticas dos problemas recebidos como parâmetro.
• client: Quando se fazendo uma maratona de programação, este será o módulo responsável por mandar o problema ao servidor.
• core: biblioteca responsável por implementar as funcionalidade básicas do ejudge.
• problems: Script que permite a formatação e instalação de problemas.
• scoreboard: Em um contexto de competição, tal módulo será responsável por exibir o placar da maratona de programação.
• server: Em um contexto de maratona, este módulo será o responsável por receber um problema mandando pelo módulo client, ou seja, funcionará como o servidor.
• users: Módulo que proporciona que um usuário se cadastre na competição.

O software ejudge pode ser encontrado no link à seguir:

https://gitlab.com/groups/ejudge

Apesar de já possuir alguns instaladaroes automatizados para alguns de seus módulos, como o checker, o ejudge ainda carece de várias melhorias no contexto de gestão de configuração de software. Sendo assim, o plano de GCS criado irá descrever os principais pontos de melhoria levantados juntamente com o professor Edson e como tais problemas podem ser solucionados usando algum princípio de GCS adequado.

1.2    Propósito

Esse documento tem por objetivo propor uma metodologia para aplicação de práticas e e conceitos de gerência de configuração ao software Ejudge. Essa metodologia será utilizada ao longo de aproximadamente dois meses, visando o desenvolvimento de soluções de software que possibilitem que as praticas e conceitos de GCS possam ser materializados no contexto em que o Ejudge foi desenvolvido. Com isso visamos facilitar a instalação e configuração do software Ejudge em ambientes computacionais diversificados.

1.3    Escopo

Antes de explicar o escopo do projeto, vale ressaltar que as demandas aqui listadas foram selecionadas pelo próprio mantenedor do projeto. Dessa forma, vale ressaltar que novas demandas podem ser feitas ao decorrer do projeto ao até mesmo alteradas devido a uma das principais restrições do projeto, o tempo da disciplina.

Sendo assim, o projeto o escopo do projeto abrange 4 demandas para o software:

• Criar o setuptools para o módulo checker, possibilitando assim que o mesmo possa ser adicionado ao pypi.

• Empacotar a ferramenta FileSender presente no módulo do cliente, facilitando assim a instalação do mesmo por usuários.

• Empacotar o módulo de scoreboard, com o mesmo intuito da empacotação do FileSender

• Automatizar o processo de iniciar o servidor do módulo server.

Vale ressaltar que um estudo de caso ainda precisa ser feito para selecionar as ferramentas apropriadas para essas tarefas.

1.4    Definições, Acrônimos e Abreviações

Abreviação	Significado
GCS	Gerência de Configuração de Softwaew

2. Milestones

Os milestones irão formalizar as entregas que serão feitas ao longo do período de desenvolvimento. Essas entregas foram definidas juntamente ao criador do software Ejudge, Edson Alves, e são demandas reais e necessárias para a evolução do sistema em questão.

DATA	Descrição
20/05/2015	Implementar setuptools ao módulo checker do Ejudge.
27/05/2015	Subir o servidor do ejudge de maneira automatizada.
13/06/2015	Escrever testes para o ejudge
27/06/2015	Configurar ambiente de CI utilizando chef

3. Resultados

3.1 Empacotamento

O empacotamento do módulo client do ejudge foi concluído com sucesso. Entretanto, algumas considerações precisam ser feitas:

• Qt: Como o módulo client depende da biblioteca Qt, foi necessário entender quais bibliotecas o mesmo necessitava e enteder quais pacotes eram necessários para a compilação do pacote, chegou-se a conclusão que a módulo precisava dos seguinte pacotes para ser compilado: qt5base-tools, qtbase5-dev e qt5-qmake. Além disso, para a execução do pacote, os seguintes pacotes eram necessários: libqt5gui5, libqt5network5 e libqt5core5a.
• Estrutura do diretório: Originalmente, o ejudge apenas possuia os arquivos fontes juntamente com um arquivo .pro usado pelo qt para gerar o Makefile do projeto. Além disso, alguns arquivos bash também foram disponibilizados para a linkagem do binário ao módulos necessários do Qt. Dessa forma, a estrutura de diretórios foi totalmente refatorada, criando assim dois novos diretórios, debian/, que contém os arquivos relacionados ao empacotamento e src/ que contém a parte do código fonte. Além disso, um novo arquivo .pro foi gerado para facilitar a compilação, que está na raiz do projeto.
• qmake: Considerando que o Makefile era gerado pelo próprio comando qmake, também foi necessário modificar o rules para que o mesmo entendesse que o arquivo .pro deveria ser usado antes do Makefile. Vale ressaltar que essa etaoa foi simples graças ao fato de que o debian já consegue abstrair boa parte do empacotamento usando o qt.
• Ubuntu: Considerando que o pacote gerado precisava funcionar também no Ubuntu, foi necessário enteder quais seriam os pacotes equivalentes aos usados no Debian para a construção e executação do pacote criado. Foi identificado que apenas um pacote apresentava um nome diferente, o qt5base-tools, que no Ubuntu se chama qttools5-dev-tools. Além disso, a construção do pacote foi também feita em um ambiente rodando Ubuntu 14.04 e o pacote foi criado normalmente.

Para criar um pacote com base na estrutura criada, basta executar o comando:

$ debuild -us -uc

Vale ressaltar que o pacote ainda pode ser melhorado, retirando alguns warnings mostrados pelo lintian e também criando o pacote para outras arquiteturas, visto que atualmente, o pacote gerado é apenas para sistemas 64 bits.

A estrutura usada para a criação do pacote, juntamente com os arquivos usados pode ser vista no link à seguir:

Pacote client

3.2 Vagrant

Um projeto vagrant também foi criado para o projeto, visando criar um ambiente padrão de desenvolvimento e também facilitar o teste de construção de pacotes. A box escolhida para o vagrant foi um Ubuntu 14.04. Além disso, o ambiente também já possui provisions responsáveis por configurar o ambiente para desenvolvimento usando Qt juntamente com o empacotamento.

Para inicar o ambient usando o vagrant, os seguintes comandos devem ser executados:

$ vagrant up

Logo após a configuração e execução das provisions, deve-se executar o comando:

$ vagrant ssh

Para acessar toda a estrutura de diretórios do ejudge, e necessário antes entrar na pasta /vagrant. Para sair do ambiente, basta executar o comando:

$ exit

Vale ressaltar que todos essas informações, desde a execução das provisions, quanto a escolha da box, podem ser vista no arquivo Vagrantfile, que pode ser encontrado no seguinte link:

Vagrant para ejudge

3.3 Setuptools

A criação do setuptools ao módulo checker do ejudge foi feita para que o mesmo possar ser enviado ao pypi, possibilitando que os usuários consigam instalar tal módulo usando o pip. Vale ressaltar que para isso foi necessário criar um arquivo python, setuo.py, e preencher dentro deste arquivo os campos requisitados pelo pypi para um módulo ser aceito.

Por fim, vale ressaltar que a estrutura do módulo checker também foi alterada para facilitar a criação do pacote no pypi. A estrutura de exemplo foi a do módulo problems, que já estava configurado com o setuptools.

A estrutura de diretórios e o arquivo setup.py usado para o módulo checker pode ser vista no link à seguir:

Setuptools checker

3.4 Testes unitátios

Visando iniciar uma proposta de boas práticas de Engenharia de Sotware foram implementados testes unitários para o core do modulo "problems" do Ejugde. Esse foi o primeiro passo, no que viria a ser a configuração de um ambiente de integração contínua para o Ejudge. É sabido que testes são uma boa fonte de documentação para projetos de software, e permitem aos que queiram contribuir com o projeto iniciar em uma tarefa que não impacta diretamente no comportamento do código, e que permite identificar pontos de refatoração e melhorias. Além dos testes, alguns métodos também foram refatorados, permitindo que estes fossem mais atômicos e concisos.

https://gitlab.com/ejudge/ejtools/blob/master/problems/ejproblem/test/test_gentex.py

Um script shell, chamado run_ejproblem_tests.sh, foi criado para rodar os testes de maneira mais sistemática. Apesar de serem poucos testes, pensando na evolução do projeto, e na cofiguração do jenkins, criou-se esse script.

3.5 Jenkins

Com os testes escritos, iniciamos os estudos da ferramenta de integração contínua Jenkins. Essa ferramenta é escrita em Java e, utilizando o servidor web Apache, conseguimos configurá-la corretamente em um servidor na infraestrutura da organização "Digital Ocean".

O jenkins permite, que você diga de que maneira a build do projeto será criada. Isso foi feito a partir do script run_ejproblem_tests.sh. Basicamente na área de configuração do jenkins, definimos que para gerar a build, o jenkins deveria executar esse arquivo presente no repositório. Para que o jenkins pudesse gerar build do projeto, foi necessário criar um usuário jenkins no servidor.

jenkins ALL=(ALL:ALL) NOPASSWD:ALL

A opção NOPASSWD possibilita que a ferramenta de CI execute comandos com permissão de sudo sem a necessidade de informar uma senha. Essa linha deve ser adicionada no arquivo /etc/sudoers, dentro do servidor.

Como dito, foi necessário configurar o servidor web Apache, para que o jenkins pudesse ser acessado através de um ip externo. A requisição chega no Apache, e ele redireciona para o jenkins, que roda norlmamente na porta 8080.

3.6 Chake/Chef

O ultimo passo para que o ambiente de integração contínua pudesse ser gerenciado de maneira simples e efetiva, decidimos automatizar o processo de instalação e configuração do ambiente de CI. Utilizamos a ferramenta chef junto com a gem chake para realizar essa tarefa.

O chef é uma ferramenta que permite configurar ambientes diversos criando,removendo e alterando arquivos de configuração, instalando pacotes, iniciando serviços e muitas outras possibilidades. Um bom link para começar os estudos de chef https://learn.chef.io/.

O chake é uma gem, que permite aplicar as "recipes" escritas com o chef nos "nodes" definidos no arquivo nodes.yaml. Nodes são as máquinas presentes na infraestrutura que está sendo gerenciada. O chef provê um serviço chamado o chef-server. Com ele um servidor central é criado, e ele fica responsável por aplicar as receitas nos demais nodes. A escolha pelo chake se deu pela praticidade da gem, e por não ser necessário a existência de um servidor central para aplicar as receitas.

No chef, recipes são espécies de passo a passo, do que será feito em determinado node. Quais pacotes instalar, quais arquivos remover entre diversas outras opções. Os coobooks são diretórios que agrupam recipes e permitem executar tarefas em grupos de recipes. No link abaixo, se encontra a recipe feita para configurar o ambiente instalando jenkins, apache, criando arquivos de configuração e gerenciando serviços.

https://gitlab.com/ejudge/ejtools/blob/master/ci_deploy/cookbooks/jenkins/recipes/deploy_jenkins.rb

Para configurar o ambiente é necessário ter o chake instalado. sudo gem install chake.

O chake possui algumas restrições para que tudo ocorra bem. Uma delas é que o usuário da máquina em que você irá rodar o chake converge deve ter acesso ssh ao servidor. Para mais informações acesse https://gitlab.com/terceiro/chake.

Com a gem devidamente instalada, basta entrar no diretório ci_deploy e executar chake converge.