# data[].attributes.headline
1º PROBLEMA: Espaço de Trabalho compartilhado por vários desenvolvedores

# data[].attributes.subject
1º PROBLEMA: Espaço de Trabalho compartilhado por vários desenvolvedores

# data[].attributes.body
Imagine que uma organização desconhece o que seja Gerência de Configuração e que em um determinado projeto um desenvolvedor esteja modificando os artefatos C1, C2 e C3 em um diretório compartilhado na rede. Simultaneamente, um segundo desenvolvedor modifica os artefatos C4, C5 e também o artefato C3

Neste cenário, o segundo desenvolvedor não notifica o primeiro desenvolvedor sobre o impacto que a modificação do artefato C3 pode causar no código. Consequentemente, o primeiro desenvolvedor, que está usando o mesmo espaço de trabalho, não conseguirá identificar, de forma rápida, o motivo que levou sua implementação a falhar. Este problema acontece pela falta de notificação e pelo compartilhamento de artefatos de software por diversos desenvolvedores.

# data[].attributes.headline
2º PROBLEMA: Repositório centralizado compartilhado por vários desenvolvedores

# data[].attributes.subject
2º PROBLEMA: Repositório centralizado compartilhado por vários desenvolvedores

# data[].attributes.body
Imagine que agora foi acordado entre os desenvolvedores que o ideal seria centralizar os artefatos em um repositório e que cada desenvolvedor implementaria suas modificações em um espaço de trabalho privado. Após cada modificação, o artefato seria devolvido ao repositório. Considerando este cenário, freqüentemente ocorreriam sobreposições ou perdas de modificações implementadas nos artefatos comuns nas organizações sem a prática da Gerência de Configuração. Um desenvolvedor poderia implementar sua modificação em uma versão desatualizada do artefato e sobrepor a versão mais atual disponibilizada por outro. Este problema ocorre devido à atualização simultânea, quando dois desenvolvedores compartilham o mesmo repositório e não existe controle ou restrição quanto ao acesso a este repositório.

# data[].attributes.body
Esta atividade é responsável por apoiar as atividades de controle de mudanças e integração contínua. Basicamente o Controle de Versão fornece os seguintes serviços:

Identifica, armazena e gerencia os itens de configuração e as suas versões durante todo o ciclo de vida do software;

Mantém o histórico de todas as alterações realizadas nos itens de configuração;

Cria os rótulos e ramificações no projeto;

Recupera uma configuração em um determinado momento desejado tempo.

Entre os aplicativos Open Source disponíveis para o controle de versão temos o Mercurial, Git, Subversion e o CVS. Os aplicativos comerciais disponíveis temos o Team Foundation Server da Microsoft, Team Concert da IBM/Rational, StarTeam, entre outros.

As ferramentas mais utilizadas na indústria de software atualmente têm sido o SVN e o Mercurial que tem crescido bastante. O CVS já foi bastante utilizado, mas há anos tem sido substituído pelo SVN.

# data[].attributes.body
Esta atividade é responsável por fornecer um serviço complementar ao serviço oferecido pelo sistema de controle de versão onde o foco desse tipo de ferramenta está nos procedimentos pelos quais as mudanças de um ou mais itens de configuração são propostas, avaliadas, aceitas e aplicadas. O Controle de Mudanças fornece os seguintes serviços:

Identificar as mudanças nos itens de configuração;

Rastrear as mudanças nos itens de configuração;

Analisar as mudanças nos itens de configuração;

Controlar as mudanças nos itens de configuração;

Entre os aplicativos Open Source disponíveis para o controle de mudanças temos o Trac, Redmine, Mantis e o Bugzilla. Os aplicativos comerciais disponíveis temos o JIRA, FogBUGZ, CaliberRM, Perforce.

As ferramentas mais utilizadas na indústria de software atualmente têm sido o Mantis, Redmine e o Bugzilla. Todas essas ferramentas tem uma excelente aceitação sendo consideradas bastante robustas, mas ao mesmo tempo objetivas e com uma interface limpa.

# data[].attributes.body
Esta atividade é responsável por garantir que as mudanças no projeto são construídas, testadas e relatadas tão logo quanto possível depois de serem introduzidas. Todo esse processo é executado geralmente após cada mudança publicada no sistema de controle de versão ou em intervalos de tempo pré-definidos.

A integração contínua é realizada através da combinação de duas ferramentas separadas onde uma faz a construção do software e a outra monitora alterações no controle de versão e dispara a primeira para a construção.

Entre os aplicativos Open Source disponíveis para a integração contínua temos o Bitten, SCons, Ant, Maven, CruiseControl, Gump, TinderBox, entre outros. Os aplicativos comerciais disponíveis temos o AntHill Pro, FinalBuilder, e o BuildForge.

As ferramentas mais utilizadas na indústria de software atualmente têm sido o Ant, mas que tem sido substituído cada vez mais pelo Maven. O CruiseControl e o Jenkins tem sido bem utilizado também, mas ainda estão em crescimento.