Categoria: TFS

Git Bash: abrir a solução com o Visual Studio

Muitas vezes temos a nossa barra de tarefas lotada de atalhos, quanto que com alguns comando, sem sair da janela do Git Bash, podemos atualizar e abrir o projeto direto no Visual Studio.

Estes passos não exigem a criação de nenhum script específico, apenas comandos do próprio Git e Prompt do Windows. O roteiro a seguir tem no máximo 7 passos, que podem ser reduzidos com scripts, mas aqui você começa em uma branch desatualizada e termina dentro do Visual Studio, já pronto para trabalhar, sem nenhum clique a mais. Então vamos lá:

Criar uma nova branch a partir da master e abrir no Visual Studio

  1. Abra o Git Bash,
  2. Digite o comando que abre a pasta da solução,
  3. Atualize a master,
  4. Crie uma nova branch a partir da master,
  5. Digite cmd,
  6. Digite o nome da solução com a extensão e aguarde o Visual Studio carregar,
  7. Digite exit para sair do prompt do Windows e voltar ao Git Bash.

Segue um exemplo de comandos seguindo estes passos:

Atualizar uma branch existente e abrir no Visual Studio

  1. Abra o Git Bash,
  2. Digite o comando que abre a pasta da solução,
  3. Atualize a branch,
  4. Digite cmd que vai entra no modo prompt do Windows,
  5. Digite o nome da solução com a extensão e aguarde o Visual Studio carregar,
  6. Digite exit para sair do prompt do Windows e voltar ao Git Bash.

Dica

  • É possível configurar o atalho do Git Bash para abrir já na pasta dos projetos mais usados.

 

Git: convenção para estrutura de pastas

Desde que comecei trabalhar com repositórios de controle de versão do Git, tenho buscado melhores práticas, tanto para armazenar projetos como versioná-los de forma eficiente. Mas o meu espírito metódico começou perceber que as pessoas e empresas armazenavam coisas muito além dos códigos fontes de seus projetos, criando um verdadeiro ambiente com todas informações e ferramentas usadas centralizadas no mesmo repositório, tornando assim algo que pareça realmente um projeto completo.

Acredito que não há um convenção oficial explicando como a estrutura de pastas deveria ser organizada dentro de um repositório, mas encontrei alguns exemplos, nos quais os desenvolvedores justificam suas escolhas, e estas justificativas fazem muito sentido. Portanto, o melhor modelo, na minha opinião, que encontrei foi este:

A solução de organização apresentada, possui uma lógica bem coerente, mas que não está livre de sugestões, adaptações e críticas:

src

Projetos principais, ou seja, o código fonte do produto. Mas é preciso deixar claro que, quando criamos uma nova solução no Visual Studio, o padrão criado não é este, então, é preciso alguns ajustes nos projetos existentes e a criar novo selecionar a pasta.

core

Assim como temos a pasta src na raíz do repositório, podemos criar superclasses genéricas que podem ser reaproveitadas em outras soluções, para isso, é possível criar uma pasta chamada core e dentro dela ter outras pastas de projeto, como src e tests.

tests

Projetos de testes. Embora os projetos de testes possam estar incluídos na mesma solução, nesta convenção, eles são fisicamente alocados em um pasta própria. Mas cuidado para não confundir esta pasta física com as Solution folders, que são diretórios que apenas existem dentro da estrutura de projetos do Visual Studio.

tools

Ferramentas e utilitários em geral. Este diretório serve como apoio ao desenvolvimento do projeto, podendo centralizar softwares, addons, executáveis bibliotecas úteis no dia a dia.

docs

Documentação em geral como arquivos de notas, ajuda, relatórios, etc.

samples

Projetos de exemplo ou exemplos de uso. Esta é uma pasta opcional, mas pode ser útil para demonstrar algum recurso ou funcionalidade na prática.

lib

Coisas que nunca poderão estar em um pacote NuGet, por exemplo.

sql

Arquivos SQL para criação do banco de dados ou para suporte.

artifacts

Armezene aqui as saídas de compilações do produto, todavia, é preciso configurar a IDE para usar esta pasta em seus builds, como por exemplo arquivos nupkgs, dlls, pdbs, etc.

packages

Armazene aqui os pacotes NuGet compilados.

build

Builds dos projetos, assim como scripts de build customizados, como por exemplo, para o Msbuild. Pastas bin e obj. É quase igual ao artefacts, mas difere pela relação com o produto final, sendo que em artefacts serão armazenadas já versão estáveis dos builds e aqui é a pasta de cache para o desenvolvimento do dia a dia, podendo até estar no .gitignore.

build.cmd

Arquivos de comando que geram o build para windows

build.sh

Arquivos de comando que geram o build para unix, linux…

global.json

Arquivo de solução ASP.NET Core

LICENSE

Arquivo que contém a licença de uso do software e seu código fonte

README.md

Arquivo com informações relevantes do projeto em formato markdown, podendo  ser um tutorial ou resultados de testes

Outros arquivos

Os arquivos .editorconfig, .gitignore, .gitattributes são arquivos do Git e/ou para configurações pessoais de editores

NuGet.Config

Arquivo de configuração para pacotes NuGet

Referências:

https://gist.github.com/davidfowl/ed7564297c61fe9ab814
https://github.com/kriasoft/Folder-Structure-Conventions

Git: publicando em dois ou mais servidores de repositórios diferentes

Introdução

Quando pensamos em criar um projeto open-source, é preciso pensar na estratégia de publicação, e muitas vezes não queremos trabalhar direto no GitHub ou outro servidor de repositórios aberto durante algumas etapas de desenvolvimento. Pra isso é possível adotar um forma de publicar em dois locais o mesmo código, com os mesmos commits. Neste exemplo vou abordar uma projeto que nasceria no Git privado, dentro de um servidor de TFS da Microsoft e depois seria publicado em um diretório público do GitHub. Vou mostrar duas maneiras de fazer esta publicação dupla, uma onde os commits são simultâneos e outra onde trabalho em um repositório privado e depois envio o código para o espaço compartilhado.

Publicação simultânea

Crie dois repositórios em servidores diferentes, no caso, eu criei um repositório no TFS e outro no GitHub.

  • GitTFSProject
  • GitHubProject

Abra o GitBash e clone um dos repositórios.

Faça uma alteração no diretório, como incluir um arquivo de texto. Execute o comando:

E agora execute um commit com a devida mensagem:

Adicione a configuração de push para o diretório original:

Em seguida a configuração para o outro servidor:

Execute finalmente o push:

Se quiser ver todos os repositórios que estão configurados, execute:

Referência: https://stackoverflow.com/questions/14290113/git-pushing-code-to-two-remotes

Commits em tempos diferentes

Crie dois repositórios em servidores diferentes, no caso, eu criei um repositório no TFS e outro no GitHub.

  • GitTFSProject
  • GitHubProject

Abra o GitBash e clone um dos repositórios.

Abra o diretório pelo GitBash:

Neste caso, você pode criar uma branch a partir da master, executando o comando:

Faça uma alteração no diretório, como incluir um arquivo de texto. Execute o comando:

E agora execute um commit com a devida mensagem:

Faça mais algumas alterações, para que tenha ao menos 3 commits.

Execute o push e publique a branch.

Agora temos 3 commits com push no TFS.

Vamos alterar o servidor de repositórios para o GitHub e enviar pra lá estes commits.

Agora precisamos executar novamente o processo de publicação da branch e envio dos commits, com o comando:

Então, temos a mesma branch com os mesmos commits no GitHub!

Agora, retorne a configuração de push para a URL original:

Referência: https://git-scm.com/docs/git-remote

Conclusão

Assim é possível criar uma estratégia de publicação de códigos, sem precisar lançar em todos os diretórios ao mesmo tempo.

TFS: criar um projeto com vários repositórios

Muitos projetos são compostos por um arquitetura que envolve mais de uma solução, e pra que isso seja gerenciado como um projeto inteiro, é preciso gerenciar demandas em vários projetos menores. Um cenário bem comum são arquiteturas que usam microservices, onde a mesma equipe desenvolve vários serviços relacionados à uma ferramenta maior, ou quando temos uma aplicação monolítica que está sendo dividida a partir de um repositório único.

A aplicação de exemplo simula um ambiente onde teremos um projeto Rest API, um Gateway e uma aplicação Web que consome a API.

Crie o projeto principal dos repositórios

Abra a página principal dos projetos do TFS e clique em New Project.

Em  Create new project, preencha os campos de Project name, Description, em Version control selecion Git, em Work item process selecione Scrum e então clique em Create.

Crie os repositórios a partir do Visual Studio

Para fins de organização, crie um pasta com o nome do projeto no computador local. Como por exemplo C:\Contacts.

Abra o Visual Studio e em Team, clique em Manage Connections…, em Team Explorer – Connect, clique em Manage Connections, clique em Connect to a Project.

Em Connect to a Project, clique em Showing hosted repositories for e por ultimo em Add an account.

Digite as informações da Conta Microsoft e clique em Sign in, Clique no projeto e por último em Connect.

Crie um nova solução e deixe a opção Create new Git repository clicada.

Faça uma pequena alteração, como incluir uma Solution folder ou um arquivo Readme.md.

Clique o botão direito sobre a Solution e em seguida clique em Commit…

Escreva uma descrição para o commit inicial, e clique em Commit All and Push.

Clique em Publish Git Repo

Clique em Advanced e selecione o projeto em Team project e digite o nome da solução em Repository name, e por fim clique em Publish repository.

Repita o processo para outros repositórios.

Exclua o repositório padrão

O TFS cria um repositório padrão como o mesmo nome do projeto, mas não é possível excluí-lo sem criar um novo repositório, portanto, após criar todos os repositórios necessários, ou menos um extra, é possível deletá-lo.

Na página principal do projeto, clique em Code e em seguida em Manage repositories.

 

Clique em … ao lado do repositório que deseja excluir, e clique em Delete repository.

Digite o nome do repositório e clique em Delete.