Profilleri, Takma Adları ve Ortamları Yönetme

You should not ship dev tooling to production. Profiles (Leiningen) and aliases (deps.edn) let one project produce different configurations on demand.

A profile in project.clj overlays extra config, such as dev-only dependencies, that merge into the base.

Use the with-profile task to run a command under a chosen profile.

The :dev profile activates automatically for local commands like lein repl, so test tooling is available without extra flags.

In tools.deps, an alias adds dependencies or options under a keyword you activate with the -M or -X flags.

Invoke an alias from the CLI; multiple aliases combine.

Read configuration from the environment so the same artifact behaves differently per deployment without recompiling.

Keep an config.edn read at startup. Choose the file via an env var so prod and dev load different settings.

Never commit credentials. Inject them through environment variables or a secrets manager, and reference them from profiles or aliases only by name.

Both profiles and aliases compose. Layer a base plus environment overlays rather than maintaining several near-identical full configs.

Pin versions and avoid implicit defaults so a build on CI matches a build on a laptop. Profiles and aliases make these differences explicit and intentional.

You learned Leiningen profiles, deps.edn aliases, activating them from the CLI, reading environment variables and per-environment config files, keeping secrets out of source, and composing layers for reproducible builds.