A importância de um repositório de versionamento
Não importa qual tipo de repositório de versionamento utiliza, a sua importância é prioridade quando se trabalha em ambiente de desenvolvimento separado de ambiente de homologação e produção.
Quando trabalhamos com linguagens como Visual Basic, ASP Classic, e até ASP.Net, não nos preocupamos tanto com versionamento pois o código só roda em um único lugar, o ambiente de produção, e os ajustes podem ser aplicados em tempo de execução, instantaneamente.
Porém, quando trabalhamos com linguagens como C++ ou Java, dependemos de repositórios de versionamento e precisamos que os mesmos estejam totalmente íntegros e que representem de fato o cenário em produção real.
No CVS, um sistema de versionamento básico, existe um repositório que é onde ficam salvos os arquivos atuais do projeto, e qualquer novo arquivo, é incluso utilizando apenas interface gráfica, de forma bem intuitiva, você resgata um repositório de algum lugar, realiza o checkout para sobrescrever alterações locais pegando do servidor, ou gravar para enviar sua alteração de código ao servidor do CVS, que pode ser conectado com um protocolo específico ou via SSH.
Após o CVS, temos vários outros tipos de versionamento de código, mas o mais popular atualmente é o Git, devido a popularidade também do site GitHub, que emerge com uma interface web para controlar seu repositório, e adiciona branches que são linhas de desenvolvimento separadas, que podem ser mescladas (merge) a uma linha principal.
A linha principal e as linhas de branches, podem mudar conforme o modelo de desenvolvimento, conforme estrutura técnica, mas se houverem 3 cenários separados, devem haver 3 linhas de desenvolvimentos separadas, e que a cada teste que sobe de nível, aplica-se o merge request para as alterações.
O Git é muito bom nisto, encontrando conflitos e partes de código que podem impactar outras partes, apesar de não ter sido desenvolvido pensando em uma linguagem específica, é praticamente essencial no desenvolvimento de projetos Java, pois reflete toda a segurança necessária como criar usuários que podem ter acesso de gravação a uma determinada branch, usuários que podem aceitar solicitações de "merge request", e então todos podem ter acesso ao código, mas o mesmo só pode ser de fato incluso ao "QA" ou "master", conforme o nível de usuário.
Quem é da área de desenvolvimento, não pode subir nada na linha de homologação ou produção, exceto se forem bugs, onde o processo pode ser o inverso, como aplicando o merge request em produção, e seguindo para homologação e desenvolvimento. Isto também é possível, mas depende do nível de acesso do usuário, e principalmente do modelo de desenvolvimento de linha de produtividade.
Saiba mais sobre Tortoise CVS:
http://www.tortoisecvs.org/
Veja um tutorial de um tipo de linha de produtividade, o Git Flow:
https://fjorgemota.com/git-flow-uma-forma-legal-de-organizar-repositorios-git/
Quando trabalhamos com linguagens como Visual Basic, ASP Classic, e até ASP.Net, não nos preocupamos tanto com versionamento pois o código só roda em um único lugar, o ambiente de produção, e os ajustes podem ser aplicados em tempo de execução, instantaneamente.
Porém, quando trabalhamos com linguagens como C++ ou Java, dependemos de repositórios de versionamento e precisamos que os mesmos estejam totalmente íntegros e que representem de fato o cenário em produção real.
No CVS, um sistema de versionamento básico, existe um repositório que é onde ficam salvos os arquivos atuais do projeto, e qualquer novo arquivo, é incluso utilizando apenas interface gráfica, de forma bem intuitiva, você resgata um repositório de algum lugar, realiza o checkout para sobrescrever alterações locais pegando do servidor, ou gravar para enviar sua alteração de código ao servidor do CVS, que pode ser conectado com um protocolo específico ou via SSH.
Após o CVS, temos vários outros tipos de versionamento de código, mas o mais popular atualmente é o Git, devido a popularidade também do site GitHub, que emerge com uma interface web para controlar seu repositório, e adiciona branches que são linhas de desenvolvimento separadas, que podem ser mescladas (merge) a uma linha principal.
A linha principal e as linhas de branches, podem mudar conforme o modelo de desenvolvimento, conforme estrutura técnica, mas se houverem 3 cenários separados, devem haver 3 linhas de desenvolvimentos separadas, e que a cada teste que sobe de nível, aplica-se o merge request para as alterações.
O Git é muito bom nisto, encontrando conflitos e partes de código que podem impactar outras partes, apesar de não ter sido desenvolvido pensando em uma linguagem específica, é praticamente essencial no desenvolvimento de projetos Java, pois reflete toda a segurança necessária como criar usuários que podem ter acesso de gravação a uma determinada branch, usuários que podem aceitar solicitações de "merge request", e então todos podem ter acesso ao código, mas o mesmo só pode ser de fato incluso ao "QA" ou "master", conforme o nível de usuário.
Quem é da área de desenvolvimento, não pode subir nada na linha de homologação ou produção, exceto se forem bugs, onde o processo pode ser o inverso, como aplicando o merge request em produção, e seguindo para homologação e desenvolvimento. Isto também é possível, mas depende do nível de acesso do usuário, e principalmente do modelo de desenvolvimento de linha de produtividade.
Saiba mais sobre Tortoise CVS:
http://www.tortoisecvs.org/
Veja um tutorial de um tipo de linha de produtividade, o Git Flow:
https://fjorgemota.com/git-flow-uma-forma-legal-de-organizar-repositorios-git/
Nenhum comentário
Deixe seu comentário abaixo e curta Tutorial TI no facebook!