[DiscordArchive] Hey folks, I posted this in <#284406375495368704> the other day but I figured I'd try in here too si
[DiscordArchive] Hey folks, I posted this in <#284406375495368704> the other day but I figured I'd try in here too si
Original source
Hey folks, I posted this in <#284406375495368704> the other day but I figured I'd try in here too since my setup is pretty docker specific.
I'm new to AzerothCore, but I wanted to play around with setting up a development / deployment pipeline that follows best practices and leans heavily on automation and CI/CD. I've read through the Wiki, forked the main repo, reconfigured the GitHub actions files to build and push images to my own Docker Hub account, and then stood up these images in a compose file based on https://github.com/azerothcore/acore-docker. I assume I'm on the right track so far.
I have a few questions about where I go next:
• If I wanted multiple environments (e.g. production, public-test, private-test), should this be accomplished by designating git branches for these, having separate CI pipelines, and building these branches to their own Docker image tags?
• Currently when I push new docker images, I think I just need to run `docker-compose pull`, `docker-compose up ac-db-import`, `docker-compose up -d` on the environment I want to update. Is there an established pattern for automating this process?
• If I want to add custom behaviour, it seems I should use modules if at all possible. Is it preferred to commit the module code in to the modules directory of the core project, rather than using git submodules? (Assuming I'm not publishing these modules, if I were I would make a separate repo and add them as submodules?)
• If making changes to core outside of a module, should I be following the same process as when contributing to upstream? i.e. add change scripts to `pending_db_world` and let CI process these, running the import-pending workflow on PRs to the test branches? And then just PR the changes committed by the bot to master when I'm ready to release to production?
rektbyfaith
05-11-2022, 11:03 AM #1Archived author: Jim • Posted: 2022-05-11T11:03:26.760000+00:00
Original source
Hey folks, I posted this in <#284406375495368704> the other day but I figured I'd try in here too since my setup is pretty docker specific.
I'm new to AzerothCore, but I wanted to play around with setting up a development / deployment pipeline that follows best practices and leans heavily on automation and CI/CD. I've read through the Wiki, forked the main repo, reconfigured the GitHub actions files to build and push images to my own Docker Hub account, and then stood up these images in a compose file based on https://github.com/azerothcore/acore-docker. I assume I'm on the right track so far.
I have a few questions about where I go next:
• If I wanted multiple environments (e.g. production, public-test, private-test), should this be accomplished by designating git branches for these, having separate CI pipelines, and building these branches to their own Docker image tags?
• Currently when I push new docker images, I think I just need to run `docker-compose pull`, `docker-compose up ac-db-import`, `docker-compose up -d` on the environment I want to update. Is there an established pattern for automating this process?
• If I want to add custom behaviour, it seems I should use modules if at all possible. Is it preferred to commit the module code in to the modules directory of the core project, rather than using git submodules? (Assuming I'm not publishing these modules, if I were I would make a separate repo and add them as submodules?)
• If making changes to core outside of a module, should I be following the same process as when contributing to upstream? i.e. add change scripts to `pending_db_world` and let CI process these, running the import-pending workflow on PRs to the test branches? And then just PR the changes committed by the bot to master when I'm ready to release to production?
1 Guest(s)
1 Guest(s)