Desenvolvimento Profissional


Como você controla o desenvolvimento dos seus projetos?

Eu quero dizer, os requisitos, fontes, tickets, releases, documentação… ou seja, todo os artefatos do software.

Eu utilizo Git, Tickets, Wikis e GitLab para o controle de todos os meus projetos privados.

Unsplash image

Introdução

Codificar um software hoje em dia não é tão difícil. São tantas ferramentas automatizadas, vídeos com tutoriais completos ou IDE’s fantásticas, que praticamente qualquer pessoa que realmente se interesse pelo assunto iria conseguir fazer um software.

Isso é incrível.

Mas existe uma grande diferença entre fazer um simples programa e desenvolver um projeto profissional.

Controle

Como desenvolvedor, arquiteto e gerente de projetos pessoais ou de clientes, preciso ter o controle de todos os artefatos que compõe todos os softwares para qual eu trabalho.

Sendo o software um trabalho de engenharia, mas também arte e trabalho manual, ter o controle 100% de todos os detalhes é impossível.

No entanto precisamos ter o controle da qualidade, prazo e orçamento.

É necessário haver ferramentas para controlar tudo, desde o levantamento de requisitos, codificação, testes, acompanhamento de problemas, lançamento de versões e documentação.

As ferramentas para esse tipo de controle existem e estão a disposição para qualquer desenvolvedor, mas nem todos as utilizam.

O uso dessas ferramentas separam os amadores dos profissionais.

Ferramentas

Qualquer ferramenta que realmente ajude no controle do desenvolvimento de software é válida. No entanto algumas dessas ferramentas já foram e são utilizadas diariamente e, por serem tão eficazes, considero-as como um padrão no mundo do desenvolvimento de software. E é sobre elas que irei falar.

Git, segundo a Wikipedia, é um sistema de controle de versão distribuído e um sistema de gerenciamento de código fonte, com ênfase em velocidade. O Git foi inicialmente projetado e desenvolvido por Linus Torvalds para o desenvolvimento do kernel Linux, mas foi adotado por muitos outros projetos.

Ele é o padrão atual para o controle de versão de softwares. Mas, não apenas por isso, você deve utilizá-lo porque não há nenhum outro concorrente que seja tão simples e eficaz.

Ticket ou Issue é a ferramenta mais utilizada por um profissional. Tudo sobre o software deverá estar registrado em tickets. Desde uma dúvida do usuário sobre uma documentação, até a resolução de um bug complicado. Tudo, absolutamente tudo, deverá ser registrado antes do desenvolvimento ou execução da solicitação.

Eles mantém todo o histórico de solicitações e decisões desde o início do desenvolvimento.

Wikis são sites que permitem a edição colaborativa de seu conteúdo e estrutura pelos usuários do sistema. Os usuários são os arquitetos, desenvolvedores e stakeholders (partes interessadas).

Esses sites fazem parte da documentação do projeto. Todas as Regras de Negócio, configurações, manuais e informações gerais deverão estar preservados nas páginas desses sites. No entanto algumas poucas informações não deverão estar nesse formato, como configurações de usuário/senha, orçamentos e contratos.

Branches são ramificações do código indo em outras direções do branch principal, o master. O objetivo é manter o branch principal master sempre com a última versão liberada para o usuário, enquanto o desenvolvimento vai sendo feito em outros branches.

Todo projeto deve ter no mínimo dois branches: master e develop.

Enquanto o master é “intocável” pela maioria dos desenvolvedores, o develop está em constante desenvolvimento. Você pode até utilizar outros nomes, mas é isso aí.

Cada ticket poderá gerar um novo branch, porém temporario. Após mesclar o branch temporário no develop, ele poderá ser apagado. Isso melhora a rastreabilidade das modificações do código.

No momento que o develop está pronto para ser liberado como uma nova versão do sistema, uma mesclagem de todo o desenvolvimento deve ser feito no master.

Tags são como branches imutáveis. A cada release do software devemos criar uma tag correspondente a versão. Uma vez criada uma tag, seu código não poderá ser mais alterado. Elas devem contar a história de todas as versões do software.

Serviços

Existem vários serviços para o controle do desenvolvimento de softwares, no entanto vou escrever apenas sobre os três maiores, que são os mesmos no qual tenho maior experiência.

Github é um portal de projetos OpenSource incrível. Como o próprio nome diz, ele oferece repositórios Git. Todo mundo utiliza. Desde programadores amadores até grandes corporações privadas.

Eu o utilizo diariamente.

Essa página que você está lendo agora está hospedado lá, assim com alguns dos meus projetos OpenSource. Também contribuo em outros projetos e utilizo bastante libs e frameworks. É fácil encontrar outros projetos. Fácil de usar. Fantástico.

Mas se você quiser ter um projeto privado lá, terá que pagar. Não é caro, na verdade, porém nem todo mundo quer ou pode pagar. Talvez você apenas queira trabalhar num projeto acadêmico ou talvez só armazenar alguns exemplos de código… não importa o motivo, você não quer pagar um valor mensal.

BitBucket é outro serviço um pouco diferente do Github. Ele também oferece repositórios Git e outros serviços que são “instalados” se você quiser. No entanto sua interface e usabilidade não são tão simples como no Github.

A boa notícia é que ele dá direito a repositórios privados e gratuitos. Esse foi um dos fatores que me fez escolher o BitBucket como meu serviço para projetos privados desde 2012. Mas esses repositórios privados, somados todos, só podem ter até 5 desenvolvedores. Então quando seus projetos começarem a crescer e você ainda não quiser pagar ou não estiver satisfeito com o funcionamento geral do sistema, você terá que procurar outra solução.

GitLab é o melhor dentre eles pois une o que ambos acima tem de melhor: projetos privados, gratuitos, ótima interface e usabilidade.

Quem me indicou o GitLab foi meu amigo Fabricio Cabral, que também estava em busca de algo parecido com o Github.

O GitLab tem a interface parecida com o Github. Simples e elegante. No entanto o Github ainda consegue ser “perfeito” nesse quesito.

Mas o GitLab tem outras features que, até o momento — ou até onde eu saiba —, não existem no Github:

  1. Tickets com anexo
  2. Time tracking

Dar a possibilidade ao usuário para anexar um relatório, documento, prinscreen ou um esboço de tela sempre foi imprescindível pra mim.

Time tracking é uma feature nova que estou começando a utilizar. É aquele tipo de coisa que falamos: “Como ninguém havia pensando nisso antes?”

E você ainda tem a possibilidade de ajudar no desenvolvimento do projeto e propor melhorias. É tudo OpenSource — mas eles comercializam uma versão paga — e codificado em Ruby.

A companhia responsável pelo desenvolvimento do GitLab não para de crescer.

Por isso tudo acho que este é ótimo serviço de uma grande companhia. Não teria restrições se tivesse que pagar por ele no futuro, caso meus projetos ficassem maiores do que a versão gratuita é capaz de suportar.

Eu posso começar pequeno, com projetos privados e gratuitos, testar todo o sistema e ver se me adapto à ele antes de começar a pagar. Perfeito.

O único problema que tive até agora no uso do GitLab é encontrar o serviço temporariamente indisponível por estar sendo atualizado. Eles utilizam o GitLab para fazer o GitLab. Então a cada nova versão liberada o serviço pode ficar intermitente.

Mas quando você não está pagamento nada e ainda é avisado — por Twitter — antes do serviço ficar indisponível bem, você não teria o direito de reclamar, teria?

A verdade é que estou utilizando o GitLab a apenas 1 mês. Mas como tenho bastante conhecimento dos outros serviços, posso dizer que o GitLab superou minhas expectativas.

Atualmente estou migrando todos os meus projetos privados do BitBucket para o GitLab — ele tem um importador de projetos que facilita muito esse trabalho.

Mesmo em tão pouco tempo posso afirmar que o GitLab é um grande concorrente, senão o melhor. E, até agora, estou bastante satisfeito.

Conclusão

Projetos profissionais não são feitos apenas com código e boa intensão. Temos que ter o controle sobre todos os artefatos.

Esse controle é feito utilizando ferramentas especializadas. Acima você pode ver quais foram as minhas escolhas.

Mas, antes de tudo, é necessário ter disciplina e conhecimento. Do contrário nenhuma ferramenta será suficiente.

Até logo.

Posts Relacionados

  • Injeção de Dependência sem XML, Atributos/Anotações ou Frameworks

  • Nomeando Classes em Libraries

  • Versionando e Organizando seus Pacotes

  • Xavier Package

  • Inter-process Communication

  • Porquê eu escolhi Delphi e então, Object Pascal

  • Redefinindo Classes

  • Git-work Project

  • Imutabilidade do Estado

  • Diretivas de Compilação