|
|
8 vuotta sitten | |
|---|---|---|
| api | 8 vuotta sitten | |
| assets | 8 vuotta sitten | |
| build | 8 vuotta sitten | |
| cmd/_your_app_ | 8 vuotta sitten | |
| configs | 8 vuotta sitten | |
| deployments | 8 vuotta sitten | |
| docs | 8 vuotta sitten | |
| examples | 8 vuotta sitten | |
| githooks | 8 vuotta sitten | |
| init | 8 vuotta sitten | |
| internal | 8 vuotta sitten | |
| pkg/_your_public_lib_ | 8 vuotta sitten | |
| scripts | 8 vuotta sitten | |
| test | 8 vuotta sitten | |
| third_party | 8 vuotta sitten | |
| tools | 8 vuotta sitten | |
| vendor | 8 vuotta sitten | |
| web | 8 vuotta sitten | |
| .gitignore | 8 vuotta sitten | |
| LICENSE.md | 8 vuotta sitten | |
| Makefile | 8 vuotta sitten | |
| README.md | 8 vuotta sitten | |
This is a basic layout for Go application projects. It represents the most common directory structure with a number of small enhancements along with several supporting directories common to any real world application.
Clone the repository, keep what you need and delete everything else!
/cmdMain applications for this project.
The directory name for each application should match the name of the executable you want to have (e.g., /cmd/myapp).
Don’t put a lot of code in the application directory unless you think that code can be imported and used in other projects. If this is the case then the code should live in the /pkg directory.
It’s common to have a small main function that imports and invokes the code from the /internal and /pkg directories.
/internalPrivate application and library code.
Put your actual application code in the /internal/app directory (e.g., /internal/app/myapp) and the code shared by those apps in the /internal/pkg directory (e.g., /internal/pkg/myprivlib).
/pkgLibrary code that’s safe to use by external applications (e.g., /pkg/mypubliclib).
Other projects will import these libraries expecting them to work, so think twice before you put something here :-)
/vendorApplication dependencies (managed manually or by your favorite dependency management tool).
Don’t commit your application dependencies if you are building a library.
/apiOpenAPI/Swagger specs, JSON schema files, protocol definition files.
/webWeb application specific components: static web assets, server side templates and SPAs.
/configsConfiguration file templates or default configs.
Put your confd or consule-template template files here.
/initSystem init (systemd, upstart, sysv) and process manager/supervisor (runit, supervisord) configs.
/scriptsScripts to perform various build, install, analysis, etc operations.
These scripts keep the root level Makefile small and simple.
/buildPackaging and Continous Integration.
Put your cloud (AMI), container (Docker), OS (deb, rpm, pkg) package configurations and scripts in the /build/package directory.
Put your CI (travis, circle, drone) configurations and scripts in the /build/ci directory.
/deploymentsIaaS, PaaS, system and container orchestration deployment configurations and templates (docker-compose, kubernetes/helm, mesos, terraform).
/testAdditional external test apps and test data.
/docsDesign and user documents.
/toolsSupporting tools for this project. Note that these tools can import code from the /pkg and /internal directories.
/examplesExamples for your applications and/or public libraries.
/third_partyExternal helper tools, forked code and other 3rd party utilities (e.g., Swagger UI).
/githooksGit hooks.
/assetsOther assets to go along with your repository.