A few days ago we releasedv0.4.1 of Atlas. Along witha multitude of improvements and fixes, I'm happy to announce the release of a feature that we've been planning for a while:Project Files.

Project files provide a way to describe and interact with multiple environments while working with Atlas. A project file is a file namedatlas.hcl that contains one or moreenv blocks, each describing an environment. Each environment has a reference to where the schema definition file resides, a database URL and an array of the schemas in the database that are managed by Atlas:

// Define an environment named "local".env"local"{// Declare where the schema definition file resides.src="./schema/project.hcl"// Define the URL of the database which is managed in// this environment.url="mysql://localhost:3306"// Define the URL of the Dev Database for this environment.// See: https://atlasgo.io/dev-databasedev="mysql://localhost:3307"// The schemas in the database that are managed by Atlas.schemas=["users","admin"]}env"dev"{// ... a different env}

Project files arose from the need to provide a better experience for developers using the CLI. For example, consider you are using Atlas to plan migrations for your database schema. In this case, you will be running a command similar to this to plan a migration:

atlas migrate diff --dev-url mysql://root:password@localhost:3306 --to file://schema.hcl --dir file://migrations --format atlas

With project files, you can define an environment namedlocal:

env"local"{url="mysql://root:password@localhost:3306"dev="mysql://root:password@localhost:3307"src="./schema.hcl"migration_dir{url="file://migrations"format=atlas}}

Then run themigrate diff command against this environment using the--env flag:

atlas migrate diff --env local

Alternatively, suppose you want to use Atlas to apply the schema on your staging environment. Without project files, you would use:

atlas schema apply -u mysql://root:password@db.ariga.dev:3306 --dev-url mysql://root:password@localhost:3307 -f schema.hcl

To do the same using a project file, define another env namedstaging:

env"staging"{url="mysql://root:password@db.ariga.dev:3306"dev="mysql://root:password@localhost:3307"src="./schema.hcl"}

Then run:

atlas schema apply --env staging

Passing credentials as input values

Similar toschema definition files, project files also supportInput Variables. This means that we can definevariable blocks on the project file to declare which values should be provided when the file is evaluated. This mechanism can (and should) be used to avoid committing to source control database credentials. To do this, first define a variable nameddb_password:

variable"db_password"{type=string}

Next, replace the database password in all connection strings with a reference to this variable, for example:

env"staging"{url="mysql://root:${var.db_password}@db.ariga.dev:3306"dev="mysql://root:${var.db_password}@localhost:3307"src="./schema.hcl"}

If we runschema apply without providing the password input variable, we will receive an error message:

Error: missing value for required variable "db_password"

To provide the input variable run:

atlas schema apply --env staging --var db_password=pass

Input variables can be used for many other use cases by passing them asinput values to schema files.

What's next

In this post, I presentedProject Files, a new feature recently added to Atlas to help developers create more fluent workflows for managing changes to their database schemas. In the coming weeks we will be adding a few more improvements to the dev flow, such as support for marking a specific environment as the default one (alleviating the need to specify--env in many cases) andmulti-file schema definitions.

Have questions? Feedback? Find our teamon our Discord server.