Proper Database Migrations with Copilot Pipeline #3628
Replies: 1 comment 4 replies
-
Never got a suggestion here, but I figured it was worth sharing our solution in case anyone else comes across this. Since we wanted a shared repo for our scheduled jobs (see discussions/3598), we ended up building that image in the buildspec.yml
We also needed to point our scheduled jobs' manifest.yml files to the image in AWS ECR, rather than having the build described there
Since we now have the job image built and available in our buildspec, we can add migrations to our post build phase in the buildspec file:
This isn't ideal, as we need to specify arguments in both the manifest and the buildspec files, and the environmental variables we have access to are different between the two files (eg: $AWS_ACCOUNT_ID only available in the buildspec file, and $COPILOT_APPLICATION_NAME only available in the buildspec. It also breaks the pattern of having every container's build defined in the manifests, which was nice for a clean and clear infrastructure as code. That said, as it solves both the issue of sharing one repo for all scheduled jobs and allows us to run migrations at the appropriate place in the build/deploy process, it's what we landed on. Again, this is what we pieced together, what made sense given our setup, and is by no means a perfect solution. That said, I felt it was worth sharing in case it's helpful to anyone else trying to figure this out. Any other suggestions, thoughts, or critiques are welcome. *Notes:
|
Beta Was this translation helpful? Give feedback.
-
We're looking to integrate migrations into our Copilot Pipeline deploy process, but having some trouble figuring it out. Our migrations run through PHP Doctrine with Symfony, and they need to be run from a running container with our built codebase. The solution that we're thinking about is having a service or job that is built alongside our web and worker images, which would run our migration when deployed. We would then specify the web and worker containers to be dependent on the migration container (https://aws.github.io/copilot-cli/docs/manifest/pipeline/#stages-deployments-dependson). The main issue with this solution is that the web and worker containers would be dependent on the start of the migration job/service, whereas we need it to be dependent on the completion and success of the service. Is there any way to have the depends_on rely on the success rather than the start of the migration? Also, what type of job or service would you recommend using (jobs seem always run on a schedule, rather than an immediate one time execution, and services seem to be geared towards ongoing operations, rather than a finite task)? Lastly, are we totally off base, and is there a more standard solution to running migrations during a Copilot Pipeline deploy?
Beta Was this translation helpful? Give feedback.
All reactions