aleksanderaleksic / tgmigrate Goto Github PK

The readme is missing content on how to install and use the tool.

Being able to apply migrations is a minimum requirement for this tool.

Writing unit tests and integration tests to give confidence that the cli is working as it should.

The tool should be able to plan migrations and output the changes.

The history file and folder are not deleted if you run a apply and when you get the No migrations will be applied message.

The config file can located in the same directory as the executable or the path can be added as a -config flag.
It would also be nice to look for a conif file in the parent directories, if flag is not specified and no config file is found in the same directory as the executable.

Sometimes more logic in the migration might be needed.
Then having support to trigger bash scripts would be a nice additon.
The nice thing with running it from tgmigrate is that you store the history so it is only applied once

migrate "script" "bash" {
  type = "bash"
  file = "./some_advanced_migration.sh"
  parameters = {
     param1 = "val1"
     param2 = "${VARIABLE}"
  }
}

When running terragrunt apply-all /plan-all multiple executions of tgmigrate meaning there is a migrationcheck for one module at the same time. This will cause race condition.

Suggestion is to add a flag like --max-concurrent-executions 1 where if it is applied the executions above execution nr.1 would be skipped. This "state" would be stored localy in a file, but it must be known where the file is located.

from readme:

create a new file and name it something that makes sense for you.

but this will only work if the filename starts with a capital V, then some numbers, followed by '__', all without spaces.

A revert command can be usefull when a migration have been applied but there was a issue or you need to work on something else where the migration can be blocking.

For aws s3 this requires us to track the e-tag of each state object that is uploaded after the change.
This means that the e-tag needs to be stored in the history file.
The approach is simple, when a user wants to revert, we can simply delete the objects where the e-tag maches the e-tag stored for that state file. If multiple migrations have been applied then we have to remove all changes for those versions.

In the migration block I am imagining a way to set conditionals for if a migration should run.

Some conditionals can be:

• don't run after a given date (this can be nice if you are setting up a new environment with your config and so you don't have to skip all the migrations for it)
• Variable conditions, to allow you to for instance only run a migration if it matches a variable in the config variables inputed.

Example of the block:

migration {
 condition {
   test = "OnlyBefore"
   Value = "2021-08-14T00:00"
 }
 condition {
  test = "MatchesEnvironment"
  value = [
     "dev",
     "prod"
   ]
 }
}

on the example given:

  commands = [
    "plan"
  ]
  execute = [
    "tgmigrate",
    "-d",
    "-y",
    "--cv=ACCOUNT_ID=${local.account_id};ASSUME_ROLE=${local.terraform_role_arn}",
    "apply",
    "prod"
  ]
  run_on_error = false
}

there is a reference to a non-existing parameter:
flag provided but not defined: -d

how (if possible) should the plan action be used?

There should be possible to import resources using data sources. This way we can import i.e route53 zone by name.

data "aws_route53_zone" "test_com" {
  name = "test.com"
}

migrate "import" test_com" {
   state = "dns"
   name = "module.test_com.aws_route53_zone.test_com"
   resource = data.aws_route53_zone.test_com.id
}