Aula 11 - Ferramentas de Controle de Versão SVN CVS Git Análise Estática de Código-Fonte SonarQube Integração Contínua (e outros)

Prévia do material em texto

Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 2 de 80 
 TEMAS DE CONTROLE DE VERSÃO 
 
Professor, o que seria um Sistema de Controle de Versão? É um sistema que 
registra as mudanças feitas em rquivo u um onjunto e rquivos ao o go 
do t mpo e rma que ja possível recuperar rsões específicas. Eu, por 
exemplo, uso um sistema de controle de versão para guardar todas as versões das 
aulas que eu faço – já pensou se eu perco isso?  
 
Galera, se um sistema desses é importante para que eu controle as versões das 
minhas aulas, imaginem para quem gerencia um projeto de software – muitas 
vezes com 800 módulos e 400.000 linhas de código! O desenvolvedor deve poder 
conseguir erenciar as diferentes versões de digo-fonte, documentação, etc do 
software que ele está desenvolvendo. Vamos ver um pouquinho de história... 
 
No ano de 1972, foi criado o primeiro Sistema de Controle de Versões – Source 
Code Control System (SCCS). Passados dez anos, foi desenvolvido o Revision 
Control System (RCS), utilizando técnicas mais avançadas e já mantido pelo GNU 
Project. No entanto, uma e s esvantagens era que ele só permitia gerenciar 
versões de rquivo dividualmente. 
 
Dessa forma, em 1986, foi iniciado o projeto de criação do Concurrent Versions 
System (CVS) – esse, sim, era capaz de gerenciar projetos inteiros. Em 2000, foi 
lançada rimeira rsão o Subversion SVN) m a roposta e lhorar s 
funcionalidades do VS. Ele bombou, popularizou e fez muito sucesso – tanto que 
é utilizado até hoje! 
 
Paralelamente ao desenvolvimento e surgimento de novas ferramentas de 
controle de versão, que trabalhavam de forma centralizada, a Sun Microsystems – 
criadora do Java – começou a desenvolver o TeamWare, um software para 
controlar projetos internos da empresa. Ele trabalhava e orma istribuída 
posteriormente passou a ão ser utilizado. Por que, professor? 
 
Porque a comunidade de desenvolvedores optou por softwares que já 
trabalhavam com o mesmo conceito de distribuição, mas com funcionalidades 
mais modernas, como o Mercurial. Dos sistemas de controle de ersão que 
trabalhavam de orma istribuída, dois tiveram bastante ceitação o ado: 
Mercurial, criado por Matt Mackall; e o Git, criado por Linus Torvalds (aquele cara 
do Linux). 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 5 de 80 
 
E se ele sobrescrever arquivos indevidamente sem intenção? Pois é, para esolver 
esse problema ram desenvolvidos os Sistemas de C ntrole de V são Locais! 
Eles armazenam todas as alterações dos arquivos sob controle de revisão. Como 
assim? Ora, basta salvar o arquivo e ele é gravado no diretório com cada uma de 
suas versões. No entanto, há um probleminha... 
 
 
 
Para uma pessoa apenas, é uma abordagem razoável. Imaginem agora dez 
desenvolvedores trabalhando com tecnologias diferentes e armazenando suas 
versões cada um em seu computador! Ora, como eles podem trabalhar em 
conjunto integrando seus componentes? Para dar com esse problema, foi criado 
o t ma de C ntrole de V são C ntralizado! 
 
Eles possuem um servidor ou repositório central único e várias cópias de trabalho, 
que contêm todos os arquivos versionados. As operações de commit e update 
ocorrem entre Cliente e Servidor. Uma vantagem é ue s desenvolvedores têm 
uma ão geral sobre projeto. Uma desvantagem é que, se o servidor falhar, 
todos param de trabalhar; e se o armazenamento for corrompido, já era! 
 
A rotina básica de um desenvolvedor que trabalha com um sistema de controle de 
versões centralizado começa pela execução do comando checkout, em que é 
carregada uma cópia de trabalho no local especificado por ele. Para t zer s 
alterações do epositório para a rea e abalho, o esenvolvedor eve 
executar o omando update. 
 
Após realizar s modificações desejadas, o desenvolvedor xecuta omando 
commit, que esponsável por nviar essas modificações ao epositório. Entre a 
execução dos comandos commit e update, podem ocorrer conflitos entre os arquivos 
manipulados por essas operações e para sanar tal problema deve-se utilizar o 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 7 de 80 
 
 
 
Apesar de os Sistemas de Controle de Versão Distribuídos terem surgido mais 
recentemente já com grande aceitação do mercado, em muitos casos, ainda é 
melhor e mais viável o uso de sistemas que trabalham com o modelo centralizado. 
O uso esses sistemas tem se opularizado, devido o aixo c sto e 
implantação, o rande mero e rramentas gratuitas e a asta ocumentação 
disponível. 
 
 
 
 
 
 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 11 de 80 
O Subversion gerencia rquivos e iretórios, e s modificações feitas neles o 
longo o empo. Isto permite que você recupere versões antigas de seus dados, 
ou que examine o histórico de suas alterações. Devido a isso, muitas pessoas 
tratam-no como uma espécie de “máquina do tempo”. Ele pode funcionar em 
rede, o que lhe possibilita ser usado por pessoas em diferentes computadores. 
 
Em certo nível, a capacidade de várias pessoas modificarem e gerenciarem o 
mesmo conjunto de dados de seus próprios locais (podem estar em cidades, 
países, continentes diferentes) é o que fomenta a colaboração. Progressos podem 
ocorrer ito mais rapidamente quando ã há um argalo único por nde todas 
as modificações devam acontecer. 
 
Sua portabilidade é bacana! Cliente e Servidor podem trabalhar com Windows, 
Unix, etc – facilitando o trabalho de desenvolvedores que precisam interagir com 
diferentes sistemas operacionais. Os criadores do SVN se esforçaram em sanar 
problemas causados por diferenças entre esses sistemas, de odo que s 
comandos em linha e ódigo jam os mesmos, independentemente o O! 
 
Outro ponto forte é a interoperabilidade! Existem dezenas de plug-ins para 
diversas IDEs (Ex: Subclipse/Subversive para Eclipse; VisualSVN para Visual Studio; 
etc). O próprio Netbeans já possui funcionalidades nativas para t abalhar m 
SVN. Um ponto fraco: implantação! Como ele não está disponível em um pacote 
completo, existe um certo grau de dificuldade em instalar os componentes do 
servidor. 
 
A ferramenta permite, além do desenvolvimento colaborativo, o merge de 
conteúdo, armazenamento de logs e geração de estatísticas diversas. E mais: ele 
permite comentar as revisões, com o objetivo de facilitar o entendimento das 
alterações realizadas. Coloca-se o iretório trunk o ódigo ronto ara ser 
compilado e colocado em produção. 
 
E como alho stá rsionado, você precisa r edo de que s u 
trabalho perca qualidade or o ter essa a ica para dificações. É muito 
simples: se os dados sofrerem alguma modificação indevida, apenas desfaça tal 
modificação. Alguns Sistemas de Controle de Versão também são Sistema de 
Gerenciamento de Configuração (GC). 
 
Estes sistemas são especificamente desenvolvimento para gerenciar árvores de 
código-fonte, e possuem muitos recursos específicos para o desenvolvimento de 
software – como identificação nativa de linguagens de programação, ou 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 17 de 80 
que o usuário navegue através da árvore e das várias revisões dos arquivos, além 
de possibilitar a execução de diffs, o trabalho com o formato rss, a execução de 
checkouts, entre outras funcionalidades. 
 
São exemplos declientes de interface web para o SVN: ViewVC, WebSVN, 
ViewSVN, Trac, SVN Browser, Insurrection, etc. Existem também muitos clientes 
que trabalham em modo gráfico para o SVN. Esta u a terística portante 
na valiação e rramentas de ntrole de rsões, pois muitos desenvolvedores 
não gostam de abalhar m linhas de omando (Ex: RapidSVN, TortoiseSVN, 
JSVN, etc). 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 22 de 80 
 CONCURRENT VERSIONS TEM (CVS) 
 
 
 
Concurrent Version System (ou CVS) é um Sistema de Controle de Versão! E ele 
serve para quê? Ele gerencia várias versões de documentos, além de permitir que 
várias pessoas possam trabalhar no mesmo arquivo, organizado em um diretório 
local ou remoto. Ele é open source, bastante lizado em ambientes de ftware e 
pode r xecutado por quipes distribuídas. 
 
Possibilita rmazenar o rico dos arquivos-fonte m conomia e spaço, 
através do armazenamento somente as diferenças entre as versões. Ele utiliza 
uma arquitetura cliente-servidor em que o servidor armazena as versões atuais do 
projeto e seu histórico, e os clientes se conectam a esse servidor para obter uma 
cópia completa do projeto. 
 
Ele foi desenhado para ntrolar digos-fonte, no ntanto pode r ut ado 
com qualquer arquivo aseado m xtos. Seu sistema estabelece um repositório 
simples; mantém todas as versões de um arquivo em um arquivo único ao 
armazenar apenas as diferenças; e protege contra mudanças simultâneas a um 
arquivo ao estabelecer diferentes diretórios para cada desenvolvedor. 
 
Galera, sabe quando você está com o código funcionando, aí você decide tentar 
fazer uma implementação específica de uma maneira diferente e dá tudo errado? 
Pois é, bugs podem aparecer quando o software é modificado, e pode demorar 
um bom tempo após a modificação do software para conseguir encontrar o erro. 
O CVS permite ecuperar rsões antigas em que ão a sse rro! Bacana? 
 
Professor, mas eu não preciso de um programa para isso! Basta eu salvar cada 
versão do meu software. Bem, além de isso ser extremamente trabalhoso, pode 
ocupar bastante espaço dependendo do tamanho e complexidade do arquivo. Já 
imaginou que, em um único dia, você pode criar centenas de versões? Pois é, o 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 23 de 80 
nosso t ma de ntrole de rsões t za a bordagem incremental para 
salvar s arquivos. 
 
Ademais, já imaginaram se houver mais de uma pessoa trabalhando no mesmo 
projeto? Pode contecer e ocê brescrever rquivo ue não i salvo 
anteriormente. O CVS resolve esse problema ao isolar diferentes desenvolvedores 
um do outro, i.e., cada desenvolvedor trabalha em seu próprio diretório e o CVS 
funde esses dois diretórios posteriormente. 
 
Cabe lientar que le não t ta e istema e build, ., le não vai 
compilar da. Ademais, não é um substituto para gerenciamento, i.e., não há 
cronogramas, marcos, datas de release, nem nada disso – ele não faz 
gerenciamento. Ele também não é um substituto para a comunicação entre 
desenvolvedores, i.e., eles devem se comunicar por outro meio de contato. 
 
Por fim, é bom enfatizar que ele não se trata de um sistema de gerenciamento de 
configuração, visto que não possui rastreamento de dependências, rastreamento 
de bugs, procedimentos de testes, entre outras características de um verdadeiro 
sistema de gerenciamento de configuração. Bacana? Agora mos ver lguns 
conceitos básicos bre le! 
 
CVS armazena todos os arquivos em um repositório centralizado: um diretório (tal 
como /usr/local/cvsroot) que é populado com uma hierarquia de arquivos e 
diretórios. Os arquivos no repositório são organizados em módulos – cada um é 
composto de um ou mais arquivos, e podem ser incluídos a partir de diversos 
diretórios. Um uso ípico é definir ódulo por projeto. 
 
Cada versão de um arquivo possui um Número de Revisão (Tag) único (Ex: 1.1, 
1.2.1.4, etc). Por definição, a revisão inicial é a 1.1! Cada commit altera o número 
de revisão. 
 
 
 
Observem pela gura abaixo ue VS não é imitada ao esenvolvimento inear! A 
Árvore de Revisão pode ser dividida em branches (ou galhos). 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 24 de 80 
 
 
O CVS possui algumas limitações: os arquivos em epositório não podem ser 
renomeados evem r xplicitamente emovidos e eadicionados. Ademais, o 
protocolo não permite que os diretórios sejam movidos ou renomeados. Cada 
arquivo do subdiretório em questão deve ser individualmente removido e 
readicionado. Bacana? 
 
Outros conceitos importantes: o epositório é a pia stre onde rvidor 
mantém o s órico de evisões. Cada projeto contém exatamente um repositório. 
Já uma Cópia de Trabalho (ou Cópia Local) é a cópia em que se faz as alterações 
nos arquivos do projeto. Podem existir diversas cópias em um mesmo arquivo do 
projeto. Em geral, cada desenvolvedor possui a sua. 
 
Checkout é o ato de pedir uma cópia par ao repositório; Commit é o ato de enviar 
alterações da cópia local para o repositório (alguns chamam de Checkin); 
Mensagens de Log são arquivos que armazenam informações sobre alterações; e 
Update to e t azer lterações feitas no epositório para pia al, i.e., 
seria o rso o Commit. 
 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 25 de 80 
Pessoal, eventualmente pode ocorrer de dois desenvolvedores tentarem comitar 
mudanças em uma mesma região do arquivo. O CVS não resolve o conflito, 
apenas avisa aos desenvolvedores. O CVS está cada vez mais em desuso, por 
contado do Subversion (SVN). Não i ainda porque bram em alguns editais, no 
entanto há porque reocupar: há ouquíssimas questões, logo não é 
comum cair. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 31 de 80 
A grande vantagem da implantação do GIT é o fato de existirem pacotes 
completos para a sua instalação. No inux stalação pode er eita través de 
seu sistema t vo e erenciamento e pacotes. Para o Windows, está disponível 
o pacote msysgit, que possui diferentes versões, desde um instalador portátil até um 
instalador com todo o código fonte do GIT e um compilador em C. 
 
A instalação m plataformas Unix m ambiente a também é t al. Ele 
permite também trabalhar com diversos protocolos de ede. Similar ao SVN, a 
operação commit é atômica, i.e., se uma operação é interrompida, ela é 
desconsiderada e o repositório não fica em um estado inconsistente. Por ser 
descentralizado, clonar um repositório é comum e trivial. 
 
 
 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 32 de 80 
O GIT permite definir ermissões tanto ara epositório como t do uanto 
para iretórios e rquivos. O controle dessas permissões pode ser feito de várias 
maneiras, como – por exemplo – através do protocolo SSH, que permite criar 
chaves para controle de autenticação ou através do protocolo HTTP, que permite 
definir permissões de leitura e escrita para cada arquivo ou diretório. 
 
O histórico do G T registra as revisões, quem realizou s alterações e quando ssas 
alterações foram realizadas em um rquivo udiretório. Os desenvolvedores do 
GIT consideram a palavra changeset inadequada para a ferramenta, pois alegam que 
o GIT não grava alterações, mas estados. É possível mover arquivos e diretórios, 
porém ele não oferece suporte à operação de rename como acontece no 
Subversion. 
 
Para falar a verdade, essa funcionalidade está disponível através do comando git 
mv, que ao invés de renomear o arquivo, o apaga, fazendo em seguida uma 
réplica idêntica à apagada, com o nome desejado. No so de um merge com u 
arquivo enomeado, é ar o bversion, i.e., ele não consegue reconhecer o 
arquivo e copia o arquivo de origem para o local destinado, apagando o arquivo 
de destino. 
 
A operação de cópia não é suportada. Todo commit pode ser acompanhado de 
uma mensagem de log, i.e., o usuário pode descrever todas as alterações relativas 
aquele commit em uma mensagem, que fica gravada no repositório. Ele ambém 
permite apenas uma nsagem de para t do njunto de danças, não 
permitindo ue c da rquivo ossua a nsagem de o particular. 
 
Diferente o , le oferece o uário a pção de ealizar checkout 
parcial, ou ja, realizar checkout m apenas um diretório por xemplo. O GIT 
não possui tantos clientes baseados em interface web como o Subversion, porém 
sua distribuição já possui um cliente, o Gitweb, que foi desenvolvido na linguagem 
Perl e permite navegar pelos diretórios através de revisões desejadas. 
 
Existem bons clientes de modo gráfico disponíveis para a ferramenta. O cliente 
Gitk já acompanha a distribuição do GIT! Há também o QGIT, GIT-GUI e 
TortoiseGIT. Mesmo com uma boa documentação disponível, a curva de 
aprendizagem do GIT um pouco íngreme, logo ele é ecomendado para ários 
que j ossuam algum grau de conhecimento em controle de versões. 
 
A maior diferença entre GIT e outras ferramentas está na forma que ele trata os 
dados. Conceitualmente, a maior parte dos outros sistemas armazena informação 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 33 de 80 
como uma lista de mudanças por arquivo. Esses sistemas tratam a ormação que 
mantém como onjunto e rquivos e s mudanças feitas a ada rquivo o 
longo o t mpo, conforme stra a agem: 
 
 
 
GIT não armazena sua informação assim. Em vez disso, ele considera que os 
dados são como um conjunto de snapshots (captura de algo em um determinado 
instante, como em uma foto) de um mini-sistema de arquivos. Cada z que cê 
salva ou consolida (commit) estado do eu projeto, é omo e ele tirasse a 
foto de t dos os seus arquivos naquele momento rmazenasse a eferência 
para ptura. 
 
Para ser eficiente, se nenhum arquivo foi alterado, a informação não é 
armazenada novamente - apenas um k para rquivo dêntico nterior que 
foi armazenado. Vejam na imagem abaixo que quando não há alterações, 
continua o mesmo arquivo, com o mesmo nome, mas pontilhado para indicar que 
se trata de um link para o arquivo original. 
 
 
 
Tudo no GIT tem seu checksum (valor para verificação de integridade) calculado 
antes que seja armazenado e então passa a ser referenciado pelo checksum. Isso 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 36 de 80 
• Se uma versão particular de um arquivo está no Diretório GIT, então é 
considerada consolidada (ou inalterada). 
 
• Caso seja modificada, mas foi adicionada à Área de Preparação, então está 
preparada (ou selecionada). 
 
• E se foi alterada desde que foi obtida, no entanto não foi preparada, está 
modificada (ou alterada). 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 40 de 80 
 NÁLISE TÁTICA DE CÓDIGO-FONTE 
 
A Análise Estática e digo-Fonte a a o rocesso e etecção de rros código 
sem, de to, executá-lo pode er onsiderado rocesso de evisão 
automática e digo3! Em geral, é utilizada para encontrar bugs ou garantir 
conformidade com boas práticas de programação. Querem um exemplo comum? 
Um compilador! Ele é capaz de encontrar erros léxicos, sintáticos e, até mesmo, 
semânticos. 
 
Sommerville define como: “Técnica automatizada de análise de programa na qual 
o programa é analisado detalhadamente para encontrar condições 
potencialmente errôneas”. Inspeções são uma forma de análise estática, em que se 
examina um programa sem executá-lo. As inspeções são frequentemente dirigidas 
por ecklists de rros e eurísticas que dentificam erros comuns em diferentes 
linguagens. 
 
Para alguns erros e heurísticas, é possível automatizar o processo de verificação de 
programas em relação a essa lista, o que resultou no desenvolvimento de 
analisadores estáticos automatizados para diferentes linguagens de programação. 
Analisadores estáticos ferramentas de software ue em o ódigo-fonte de 
um rograma e etectam possíveis defeitos e nomalias. 
 
Eles analisam o código e, assim, reconhecem os tipos de declarações no 
programa. Podem portanto detectar se as declarações estão bem formuladas, 
fazer inferências sobre o fluxo de controle do programa e, em muitos casos, 
computam o conjunto de todos os valores possíveis para os dados de programa. 
Eles omplementam os recursos de detecção de rros providos pelo compilador 
da inguagem. 
 
Podem ser usados como parte do processo de inspeção ou como uma atividade 
separada do processo de verificação e validação. A intenção da análise estática 
automática é chamar a atenção do inspetor para anomalias do programa, como 
variáveis usadas sem serem iniciadas, variáveis não usadas ou dados cujos valores 
poderiam ficar fora de extensão. 
 
 
3 Na maioria das vezes, a análise é executada em alguma versão do código-fonte, e em outros casos é 
executada no código-objeto (i.e., código de máquina ou de montagem). 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 42 de 80 
Inconsistências entre as interfaces dos módulos e componentes. 
 
Variáveis que nunca são usadas ou impropriamente declaradas. 
 
Código morto. 
 
Falta de lógica ou lógica errada (loops infinitos). 
 
Construções excessivamente complicadas. 
 
Violação de padrões de programação. 
 
Vulnerabilidade na segurança. 
 
Violação de sintaxe e de modelos. 
 
 
Os estágios envolvidos na análise estática incluem: 
 
▪ Análise de uxo de ntrole: identifica e enfatiza os loops com vários pontos 
de saída ou de entrada e código inacessível. Código inacessível é aquele 
código cercado por declarações incondicionais 'goto' ou em uma ramificação 
de uma declaração condicional na qual a condição de guarda nunca pode ser 
verdadeira, portanto nunca é acessada. 
 
▪ Análise de U o de Da os: enfatiza como as variáveis do programa são usadas. 
Detecta variáveis usadas sem prévia iniciação, variáveis escritas duas vezes sem 
uma tarefa de impedimento e variáveis declaradas mas que nunca são usadas. 
A análise de uso de dados também descobre testes não eficientes nos quais a 
condição do teste é redundante. 
 
▪ Análise de nterface: verifica a consistência das declarações de rotina e de 
procedimento e seus usos. Ela é desnecessária se uma linguagem com tipagem 
forte for usada, uma vez que o compilador realiza essas verificações. Detecta 
erros de tipo em linguagens com tipagem fraca; funções e procedimentos 
declarados e nunca chamados; ou resultados de funções que nunca são 
usados. 
 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólonwww.estrategiaconcursos.com.br Pág. 43 de 80 
▪ Análise de uxo de nformações: identifica as dependências entre variáveis de 
entrada e de saída. Embora não detecte anomalias, mostra como o valor de 
cada variável é derivada de outros valores de variáveis. Com essas informações, 
a inspeção de código deve ser capaz de encontrar valores que foram 
erroneamente computados. 
 
▪ Análise de C minho: identifica todos os caminhos possíveis por meio do qual o 
fluxo de um programa pode passar durante sua execução e estabelece as 
declarações executadas naquele caminho. Essencialmente, ela elucida o 
controle do programa e permite que cada predicado possível seja analisado 
individualmente. 
 
Analisadores estáticos s o particularmente valiosos quando uma nguagem de 
programação, como C for da. A linguagem C não possui regras de tipagem 
estritas e a verificação que o compilador C pode executar é limitada. Portanto, é 
fácil para programadores cometerem erros e a ferramenta de análise estática pode 
descobrir automaticamente alguns dos defeitos de programa resultantes. 
 
Isso é particularmente importante quando C (e, em menor extensão, C++) for 
usada para o desenvolvimento de sistemas críticos. Nesse caso, a análise estática 
pode descobrir um grande número de erros potenciais e reduzir significativamente 
os custos de teste. No ntanto, os projetistas de inguagens de rogramação 
modernas, como ava4, têm removido lgumas características propensas a erro. 
 
Todas as variáveis devem ser iniciadas, não há declarações 'goto'; assim, os 
códigos inacessíveis são menos prováveis de serem criados acidentalmente e o 
gerenciamento de armazenamento é automático. Essa bordagem de prevenção 
de rros m z de detecção de rros é ais eficiente aprimoramento a 
confiabilidade e programa. 
 
Voltando um pouco na história, a Revisão de Código é um dos métodos mais 
antigos e seguros para detecção de defeitos. Em geral, trata-se a a 
atenciosa do ódigo e ecomendações de omo elhorá-lo. Um programador 
geralmente não revisa seu próprio código, visto que é mais fácil encontrar erros 
nos códigos alheios do que em seu próprio código – entretanto, esse é um 
processo caro. 
 
 
4 Embora analisadores estáticos para Java estejam disponíveis, eles não são amplamente usados. 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 44 de 80 
Já imaginaram alocar diversos programadores regularmente para revisar códigos, 
e eventualmente re-revisar após receber recomendações de melhoria? Pois é, 
pode se tornar um processo inviável! Logo, pode-se fazer uso de ferramentas 
automáticas de análise de código5, que farão recomendações ao programador
Apesar de substituir um programador experiência, é barato 
viável. 
 
As questões que podem ser resolvidas por ferramentas de análise de estática de 
código-fonte podem ser divididas em três categorias: detecção de erros em 
programas; recomendações de formatação de código; e cálculo de métricas. 
Existem dezenas de rramentas de nálise estática e ódigo-fonte om suporte 
a iversas linguagens de programação (C, C++, C#, Java, Ada, Fortran, Perl, etc). 
 
Deve ser ficar cristalino que essa técnica possui seus pontos fortes e pontos fracos. 
Nenhum todo de ste e ftware deal iferentes todos produzirão 
diferentes resultados para diferentes classes de ftware. Apenas com a 
combinação de vários métodos, será possível alcançar o mais alto nível de 
qualidade de um software. Captaram a mensagem? 
 
A grande vantagem da análise estática de código-fonte é que ela permite que 
você reduza enormemente o preço de eliminação de defeitos em um software, 
visto que quanto mais cedo se detecta um erro, menor será o preço para 
consertá-lo. De acordo com Steve cConnell, consertar erro a a e de estes 
custa dez vezes mais do que ase e plementação. 
 
 
CUSTO MÉDIO DE CONSERTO DE DEFEITOS DEPENDENDO DO MOMENTO EM QUE FORAM FEITOS E DETECTADOS. 
 
5 O termo Análise Estática, em geral, refere-se a ferramentas automáticas. O termo Revisão de Código, em 
geral, refere-se à análise feita por programadores. 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 45 de 80 
 
Por fim, é importante citar – com relação às práticas ágeis na análise estática de 
código-fonte – que a evisão por pares apresenta similaridades ao processo 
proposto pela programação m pares (pair programming) as práticas ágeis. 
Quanto à automatização da análise estática, não há menção nem mesmo 
recomendação entre as práticas ágeis para essa técnica automatizada. 
 
Dessa rma, pode-se izer que s processos de nálise stática nas práticas ágeis 
são ontemplados parcialmente. Consequentemente, sob a ótica de que há 
necessidade de se realizarem técnicas de análise estática de código juntamente 
com análise dinâmica (testes), as práticas ágeis não podem ser consideradas 
completas e eficientes. Bacana? Isso já foi tema de discursiva! 
 
 
 
 
 
 
 
 
 
 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 50 de 80 
 
O SonarQube é bacana por conta disso! Ele consegue oferecer uma porrada de 
métricas sobre o código-fonte de um sistema. Dessa rma, o programador pode 
ter a ão struturada bre plicação que stá ndo desenvolvida pode 
controlar qualidade. Gente, uma pancada de empresas competentíssimas 
utiliza o SonarQube, como IBM, EBay, HP, Nike, Cisco, PayPal, etc. 
 
 
 
Em suma, podemos dizer que le propõe r ntral de qualidade o u 
código-fonte, possibilitando ntrole sobre rande n mero de tricas de 
software, e inda apontando u a série de ossíveis bugs. Tudo gerado através de 
uma análise completa do código-fonte, e apresentado por meio de uma interface 
web, em forma de dashboards e gráficos, como é mostrado acima. 
 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 51 de 80 
 
A Arquitetura do SonarQube é composta de três componentes: 
 
▪ Banco e D dos: 
 
Deve haver apenas um! Ele mantém os resultados da análise, os projetos e 
configuração global, mas também mantém uma análise histórica. 
 
▪ Servidor Web: 
 
Deve haver apenas um! Ele é responsável por fornecer aos usuários diversos 
painéis de qualidade de código-fonte e por configurar a instância do SonarQube. 
 
▪ Analisadores: 
 
Um conjunto de analisadores de código-fonte que são agrupados e acionados por 
demanda – eles utilizam a configuração armazenada no banco de dados. 
 
Por ele suporta iversas linguagens de rogramação; pode r izado ara 
análise de desenvolvimento bile; fornece um histórico de métricas e gráficos de 
evolução (chamado Time Machine) e diferentes views; integra bem com Maven, 
Ant, Grandle, Jenkings, Hudson, etc; integra bem com Eclipse, Mantis, LDAP; é 
bastante extensível por meio de plug-ins; entre outras funcionalidades. 
 
 
 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 55 de 80 
 
Já imaginaram fazer cada passo desse por vez ‘na mão’? Com um nte de 
passos assim, você provavelmente precisaria de cklist. Ora, por que não 
fazer desse checklist um script de build e utilizar uma ferramenta para rodá-lo? 
Isso reduz erros e proporciona uma maior consistência e padronização. Professor, 
e quanto à Integração Contínua? 
 
Ora, na minha opinião omter , mas le não é stritamente cessário. Ele 
ajuda a dentificar os problemas de construção is cedo. Se você tiver vários 
desenvolvedores fazer check-in do código o dia inteiro e, talvez, não 
sincronizando seus workspaces constantemente, há um risco de que as mudanças 
interfiram uma na outra. Um Servidor de Integração Contínua pode ajudar a 
mitigar esse risco. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 58 de 80 
 
 P CHE MAVEN 
 
 
 
Maven é uma palavra de origem iídiche que significa acumulador de 
conhecimento! Trata-se de uma ferramenta de automação de builds, responsável 
por gerenciar dependências, controlar versões de artefatos, gerar relatórios de 
produtividade, garantir a execução de testes, manter o nível de qualidade do 
código, dentre outros. Entendido? Ele é lar o mas utiliza c nvenções no 
processo e mpilação. 
 
Pessoal, um dos principais problemas no desenvolvimento e mas é m 
que oda equipe construa o rtefato final da esma forma, i.e., com as 
bibliotecas e configurações corretas. É possível contornar esse problema por meio 
de ferramentas que entendam uma linguagem de script e copie as dependências e 
configurações para os lugares corretos, gerando um pacote com a aplicação. 
 
Por exemplo: o nt permite escrever ipts de uild ara piar ibliotecas de 
lugares específicos, arquivos de c nfiguração e qualquer utro po e ecursos 
para rtefato da plicação. Dessa forma, garante-se que qualquer 
desenvolvedor consiga gerar o artefato da aplicação localmente, sabendo que 
este artefato gerado é o mesmo que o resto da equipe irá utilizar. 
 
No entanto, onde devemos guardar as bibliotecas externas ao nosso projeto? A 
solução mais comum é guardá-las no repositório junto com o código fonte, assim 
todos os desenvolvedores compartilharão as mesmas dependências, e os 
caminhos das pastas são mantidos. Esse t po e rganização é ito dotada 
funciona ito bem para rojetos pequenos e m equipes bem pequenas. 
 
Quando começamos a prolongar a vida do projeto, percebemos que o overhead 
de manutenção começa a interferir no desenvolvimento. Isso porque o número de 
dependências começa a aumentar e com o tempo vão saindo versões novas de 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 59 de 80 
algumas dependências antigas. Se t das as dependências estão a sma pasta, 
fica ito difícil fazer ntrole de ersão e e ansitividade as mesmas. 
 
Portanto a rramenta de t gração e projetos que vita a 
necessidade de eplicar rmações em repositórios ara r dependências. 
Para tal, ele utiliza outra abordagem! Ele isola as bibliotecas utilizadas no projeto 
em um repositório compartilhado pela equipe. Assim, não há necessidade de se 
preocupar com duplicidade de dependências entre módulos do projeto. 
 
Já rsão das dependências fica centralizadas em arquivos de nfiguração dos 
projetos em rquivos POM! Assim, é possível realizar substituições de bibliotecas e 
identificar falhas de dependências. Por fim, ele permite a utilização de diversos 
plug-ins, tanto para geração de código quanto para integração com plataformas 
de teste ou suporte a famosas IDEs do mercado. 
 
Ele é utilizado para definir como um arquivo .java deve ser compilado para um 
arquivo .class; empacotá-los em um arquivo .jar (ou .war ou .ear); (pré/pós) 
processar com ferramentas; gerenciar o CLASSPATH; e outras atividades 
requeridas para compilar um projeto. Vamos ver agora alguns detalhes especiais! 
Ele é baseado nceito de PO (Project Object Model)! O quê, professor? 
 
 
 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 64 de 80 
 KINS 
 
 
 
Galera, o enkins é ma rramenta de t gração ntínua desenvolvida m Java 
e e ódigo berto! Ele fornece versões (builds) para os mais diferentes tipos de 
projetos possíveis. 
 
Como vimos, a integração contínua é uma das práticas mais populares no 
desenvolvimento de sistemas nos últimos tempos. Os desenvolvedores integram 
correção de bugs, novas funcionalidades ou mesmo alterações nas 
funcionalidades existentes. A ferramenta e t gração ntínua rifica 
processo de tegração m versões de uild utomatizadas m testes que 
detectam problemas no digo r t grado. 
 
O Jenkins é uma ferramenta simples, extensível, bastante amigável que provê 
serviços de integração contínua para desenvolvimento de sistemas. Ele suporta 
ferramentas de ntrole de rsão como t am, Subversion, CVS, Git, AccuRev, 
dentre outros. Jenkins pode mpilar criar rsões) de rojetos baseados no 
Freestyle, Apache n e pache aven. 
 
Pessoal, o Jenkins tem uma característica bem interessante que a possibilidade de 
estender suas funcionalidades a partir de plugins. Alguns exemplos de plugins 
disponíveis são de gerenciamento e código-fonte, controladores escravos, 
triggers para iação de uilds, notificação de uilds, relatórios e uilds, 
integração com sites externos, plugins de rface ráfica, de os de 
autenticação, desenvolvimento d id, iOS, .NET, Ruby e itos mais... ufa! 
 
O Jenkins define interfaces ou classes abstratas que modelam um build de um 
sistema. Elas são usadas para definir um contrato que determina o que precisa ser 
implementado e o Jenkins usa os plugins para estender essas implementações. 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 65 de 80 
Algumas características que tornaram o Jenkins muito popular são: 
 
• Fácil instalação em diferentes sistemas operacionais 
• Atualizações de versão (do Jenkins) fácil de instalar 
• Interface simples e fácil de usar 
• Facilmente extensível com mais de 400 plugins (até o fechamento dessa 
edição :P) 
• Fácil configuração do ambiente a partir da interface do usuário 
• Arquitetura mestre-escravo que permite a criação de builds de forma 
distribuída, reduzindo a carga no servidor de integração contínua 
• Possuis os testes baseados no famoso e bem suportado JUnit, apresentando 
resultados de forma gráfica e também tabular 
• Agendamento de builds usando expressões do cron, muito usado em 
ambientes Linux (http://en.wikipedia.org/wiki/Cron). 
• Notificações específicas para cada status de build (sucesso, falha, etc). 
 
Galerinha, somente para ver a carinha do Jenkins e mostrar como é fácil de 
instalar, vamos mostrar alguns detalhes! Os passos para instalação do Jenkins são: 
 
• Fazer o download do arquivo Java Web Archive do Jenkins (.war) no site 
http://jenkins-ci.org/. 
 
 
 
• Copiar o arquivo jenkins.war no sistema de arquivos 
• Abrir o prompt de comando (Windows, Linux, MacOs) e executar “java –jar 
Jenkins.war”. 
• Verificar se a instalação funcionou abrindo no navegador web o endereço 
http://localhost:8080 (ou onde você instalou o Jenkins) 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 66 de 80 
• Buscar a senha para desbloquear a instalação (imagem abaixo) 
 
 
 
 
Pronto!! Ele já está rodando, pronto para criar um projeto de integração 
contínua, ou, na linguagem do Jenkins, um novo Job. 
 
 
 
Esses são os tipos de Jobs que o Jenkins permite criar: 
 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 67 de 80 
 
 
Para iar u mbiente e gração contínua o z ro, o ais comumé 
selecionar a rimeira opção, que permite onstruir egras do ero. Outra opção 
interessante uscar digo-fonte ma conta de G thub. Para termos uma 
noção de como podemos gerar os builds, seguem as opções disponíveis na 
criação de um job: 
 
 
 
Legal, não acham?? Ele é bem flexível e permite criar vários passos como os 
mostrados acima para gerar os builds da sua aplicação. Depois de gerado o build, 
existem outras tantas opções disponíveis: 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 68 de 80 
 
 
 
Galerinha, esse é o Jenkins, uma ferramenta bem interessante para uso de 
integração de contínua bastante utilizado. Se encontrarem questões sobre o 
assunto, mande pra gente! 
 
 
 
 
Curso de Desenvolvimento de Software para Concursos 
Profs. Diego Carvalho e Leon Sólon – Aula 11 
 
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 72 de 80 
_______ é uma ramificação no desenvolvimento, usada para descrever o 
processo de divisão dos arquivos de um projeto em linhas de desenvolvimento 
independentes. 
 
Assinale a alternativa que preencha corretamente, de cima para baixo, as 
lacunas dos trechos acima: 
 
a) Checkout – Release – Branch. 
b) Commit – Revision – Branch. 
c) Update – Revision – Merge. 
d) Commit – Checkin – Hijack. 
e) Update – Checkin – Merge.