Thanks for this post!
How would you suggest handling one-off tasks. For example, database migrations that would need to be run before the Deploy phase in CodePipeline? Another example would be running tasks like rails console at any point of time.
Hi Tejas, sorry late reply, been swamped with work lately.
For database migrations, you can include it in your build process but you must have a process in doing so. Like forbidding "destructive" migrations (delete table / delete column) from being run inside the CI/CD. We just implemented this but only "additive" migrations is allowed (add column / add table).
Also, best to run a point-in-time snapshot of the RDS database every time you run this.
For rails console tasks, we just enter the container via docker exec. We have fargate containers for prod, but we left out 1 ECS container running on EC2 for this exact purpose.
No worries and I appreciate you taking out time to reply. Here's what I ended up doing:
For the database migrations - I did include it in the build process but I separated the migrations into another stage in the pipeline and implemented something similar to what the aws-rails-provisioner gem does (Basically uses another buildspec for the release stage).
For one-off tasks - I ended up writing a shell script which runs a task, waits for it to be placed in a container, runs docker exec -ti to open the console and kills the task when the console is closed. The script could be run by something like: bash rails-console.sh --cluster "cluster_name" --task-definition "task_def_name" --profile "cli_profile_name"
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for this post!
How would you suggest handling one-off tasks. For example, database migrations that would need to be run before the Deploy phase in CodePipeline? Another example would be running tasks like rails console at any point of time.
Hi Tejas, sorry late reply, been swamped with work lately.
For database migrations, you can include it in your build process but you must have a process in doing so. Like forbidding "destructive" migrations (delete table / delete column) from being run inside the CI/CD. We just implemented this but only "additive" migrations is allowed (add column / add table).
Also, best to run a point-in-time snapshot of the RDS database every time you run this.
For rails console tasks, we just enter the container via
docker exec
. We have fargate containers for prod, but we left out 1 ECS container running on EC2 for this exact purpose.No worries and I appreciate you taking out time to reply. Here's what I ended up doing:
For the database migrations - I did include it in the build process but I separated the migrations into another stage in the pipeline and implemented something similar to what the aws-rails-provisioner gem does (Basically uses another buildspec for the release stage).
For one-off tasks - I ended up writing a shell script which runs a task, waits for it to be placed in a container, runs
docker exec -ti
to open the console and kills the task when the console is closed. The script could be run by something like:bash rails-console.sh --cluster "cluster_name" --task-definition "task_def_name" --profile "cli_profile_name"