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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
|
$/ artifacts/ build/ core/ docs/ lib/ packages/ samples/ sql/ src/ tests/ tools/ .editorconfig .gitignore .gitattributes build.cmd build.sh LICENSE NuGet.Config README.md {solution}.sln |
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