mirror of
https://github.com/ent/ent.git
synced 2026-05-03 16:10:59 +03:00
143 lines
4.6 KiB
Plaintext
143 lines
4.6 KiB
Plaintext
---
|
|
id: upgrade-prod
|
|
title: Upgrading Production
|
|
---
|
|
|
|
import Tabs from '@theme/Tabs';
|
|
import TabItem from '@theme/TabItem';
|
|
|
|
## Supporting repository
|
|
|
|
The change described in this section can be found in
|
|
[PR #5](https://github.com/rotemtam/ent-versioned-migrations-demo/pull/5/files)
|
|
in the supporting repository.
|
|
|
|
## Upgrading our production database to use versioned migrations
|
|
|
|
If you have been following our tutorial to this point, you may be asking yourself how do we
|
|
upgrade the production instance of our database to be managed by the versioned migraions workflow?
|
|
With local development, we can just delete the database and start over, but that is not an option
|
|
for production for obvious reasons.
|
|
|
|
In this tutorial, we use the [Atlas CLI](https://atlasgo.io/docs/cli) to manage our production database.
|
|
If you haven't already, now is a good time to install it locally:
|
|
|
|
<Tabs
|
|
defaultValue="apple-intel-brew"
|
|
values={[
|
|
{label: 'macOS (Homebrew)', value: 'apple-intel-brew'},
|
|
{label: 'macOS (Plain)', value: 'apple-intel-plain'},
|
|
{label: 'Linux', value: 'linux'},
|
|
{label: 'Windows', value: 'windows'},
|
|
]}>
|
|
<TabItem value="apple-intel-brew">
|
|
|
|
Get the latest release with [Homebrew](https://brew.sh/):
|
|
|
|
```shell
|
|
brew install ariga/tap/atlas
|
|
```
|
|
|
|
</TabItem>
|
|
<TabItem value="apple-intel-plain">
|
|
|
|
Download latest release.
|
|
```shell
|
|
curl -LO https://release.ariga.io/atlas/atlas-darwin-amd64-latest
|
|
```
|
|
|
|
Make the Atlas binary executable.
|
|
```shell
|
|
chmod +x ./atlas-darwin-amd64-latest
|
|
```
|
|
|
|
Move the Atlas binary to a file location on your system PATH.
|
|
```shell
|
|
sudo mv ./atlas-darwin-amd64-latest /usr/local/bin/atlas
|
|
```
|
|
```shell
|
|
sudo chown root: /usr/local/bin/atlas
|
|
```
|
|
|
|
</TabItem>
|
|
<TabItem value="linux">
|
|
|
|
Download latest release.
|
|
```shell
|
|
curl -LO https://release.ariga.io/atlas/atlas-linux-amd64-latest
|
|
```
|
|
|
|
Move the Atlas binary to a file location on your system PATH.
|
|
```shell
|
|
sudo install -o root -g root -m 0755 ./atlas-linux-amd64-latest /usr/local/bin/atlas
|
|
```
|
|
|
|
</TabItem>
|
|
<TabItem value="windows">
|
|
|
|
Download the [latest release](https://release.ariga.io/atlas/atlas-windows-amd64-latest.exe) and
|
|
move the Atlas binary to a file location on your system PATH.
|
|
|
|
|
|
</TabItem>
|
|
</Tabs>
|
|
|
|
The binaries distributed in official releases are released under the [Apache 2 License](https://github.com/ariga/atlas/blob/master/LICENSE).
|
|
If you would like to build Atlas from source follow the instructions [here](https://atlasgo.io/cli-reference#building-from-source).
|
|
|
|
Like many other database schema management tools, [Atlas](https://atlasgo.io) uses a metadata table
|
|
on the target database to keep track of which migrations were already applied.
|
|
In the case where we start using Atlas on an existing database, we must somehow
|
|
inform Atlas that all migrations up to a certain version were already applied.
|
|
|
|
To illustrate this, let's try to run Atlas's `migrate apply` command on a database
|
|
that is currently managed by an auto-migration workflow using the migration directory that we just
|
|
created. Notice that we use a connection string to a database that _already has_ the application schema
|
|
instantiated (we use the `/db` suffix to indicate that we want to connect to the `db` database).
|
|
|
|
```text
|
|
atlas migrate apply --dir file://ent/migrate/migrations --url mysql://root:pass@localhost:3306/db
|
|
```
|
|
|
|
Atlas returns an error:
|
|
|
|
```text
|
|
Error: sql/migrate: connected database is not clean: found table "atlas_schema_revisions" in schema "db". baseline version or allow-dirty is required
|
|
```
|
|
|
|
This error is expected, as this is the first time we are running Atlas on this database, but as the error said
|
|
we need to "baseline" the database. This means that we tell Atlas that the database is already at a certain state
|
|
that correlates with one of the versions in the migration directory.
|
|
|
|
To fix this, we use the `--baseline` flag to tell Atlas that the database is already at
|
|
a certain version:
|
|
|
|
```text
|
|
atlas migrate apply --dir file://ent/migrate/migrations --url mysql://root:pass@localhost:3306/db --baseline 20221114165732
|
|
```
|
|
|
|
Atlas reports that there's nothing new to run:
|
|
|
|
```text
|
|
No migration files to execute
|
|
```
|
|
|
|
That's better! Next, let's verify that Atlas is aware of what migrations
|
|
were already applied by using the `migrate status` command:
|
|
|
|
```text
|
|
atlas migrate status --dir file://ent/migrate/migrations --url mysql://root:pass@localhost:3306/db
|
|
```
|
|
Atlas reports:
|
|
```text
|
|
Migration Status: OK
|
|
-- Current Version: 20221114165732
|
|
-- Next Version: Already at latest version
|
|
-- Executed Files: 1
|
|
-- Pending Files: 0
|
|
|
|
```
|
|
Great! We have successfully upgraded our project to use versioned migrations with Atlas.
|
|
|
|
Next, let's see how we add a new migration to our project when we make a change to our
|
|
Ent schema. |