0

Problem description
I have a spring-boot based application that creates entities on a 3rd party environment.
The application is deployed on prod.
I've discovered a bug whose fix required changes on the already created entities on the 3rd party prod entities.
Expected solution
The the 3rd party prod environment entities are fix running a java based script.
I want that script to be run in prod only the first time the application version with the fix is deployed.
I'm looking for the same functionality Flyway provided for database entities. I could use Flayway but since my application does not uses a database, I don't want to use a database versioning control tool on a non database application, in order to do not couple the database versioning concept to a non database application.
Question
Is there a library/tool that provides the functionality I'm looking for?

Pablo Cavalieri
  • 81
  • 2
  • 7
  • Why not use a feature flag kinda of thing with `@EventListener(ApplicationReadyEvent.class)` and/or `@Conditional` that checks the feature flag. – Yogesh_D Feb 03 '22 at 10:39
  • I do not know any framework like Flyway for doing what you want. One way is to use something like this: https://stackoverflow.com/questions/30347233/spring-scheduling-task-run-only-once – pringi Feb 03 '22 at 11:44

1 Answers1

1

There are many ways to execute code upon startup in a spring application. Take a look here for some of them. The code would be run every single time the application starts, so in order to apply the fix only once you could:

Just let it run once

The simplest solution would be to deploy the version with the fix, let the code run automatically and then deploy the next version with the fix removed. Though not very elegant and not recommended it would only execute once in a simple setup. Depending on the deployment and runtime setup there might be some risks to that though, or even impossible.

You seem to be looking for some protection against multiple execution of that fix. For instance because the application is started again after being deployed, which essentially boils done to either making multiple executions possible or prevent them by remembering state:

Make the changes idempotent

You won't need any tool if you're able to make the fix operation idempotent, changing the entities in question only on its initial application. Say you created users with a faulty email address, you'd check for a faulty email address and only apply the fix if you found your fix not already applied. That way the fix can run multiple times without causing any harm. Not all operations can be made idempotent though.

Preserve state between runs

The idea behind this is to remember the successfull execution of your fix. Flyway does this for database migrations. Again it depends on the execution environment to determine what kind of storage is sufficient here.

  • Use a file on the filesystem to mark the completion. Only execute the fix if the file's missing and create it afterwards. This solution might fail in a containerized enviroment when the container is recreated or in a cluster setup.
  • Use a database to mark the completition. You can create f.i. a H2 database, create an empty table with flyway and check for the empty table before executing your fix, then insert a row into the table afterwards. Using a h2 database safes you from having another service running, but is subject to the same limitations the file solution is.
  • Use an external service like redis to protect against multiple execution of your script. You could also protect the fix against multiple concurrent executions using this one.
gl1tor
  • 76
  • 2