Make staging deployment more flexible with a `staging` branch? #81

New issue

Open

opened 2025-12-10 09:22:33 +00:00 by kparal · 4 comments

kparal commented

2025-12-10 09:22:33 +00:00

Owner

Currently we deploy the develop branch to https://testdays.stg.fedoraproject.org . That's not super flexible, it makes testing a feature branch difficult, because it needs to be committed to develop first.

I think we could introduce a staging branch, which we would either point to the same commit as develop, or we could point it to any other commit, e.g. some feature branch. The staging instance would then be configured to use this staging branch, so any changes wouldn't need infra changes, just updating the branch tip in git.

The downside is that for the most common workflow, we'd need to commit to develop and also update staging branch to make it appear in staging. Is it worth it? What do you think?

Currently we deploy the `develop` branch to https://testdays.stg.fedoraproject.org . That's not super flexible, it makes testing a feature branch difficult, because it needs to be committed to `develop` first. I think we could introduce a `staging` branch, which we would either point to the same commit as `develop`, or we could point it to any other commit, e.g. some feature branch. The staging instance would then be configured to use this `staging` branch, so any changes wouldn't need infra changes, just updating the branch tip in git. The downside is that for the most common workflow, we'd need to commit to `develop` and also update `staging` branch to make it appear in staging. Is it worth it? What do you think?

kparal commented

2025-12-10 09:24:45 +00:00

Author

Owner

Please note that we currently have no deployment automation, so openshift re-deployes still need to be triggered manually through openshift tooling. That could be another improvement (a different ticket), at least for staging.

kparal commented

2025-12-10 09:24:58 +00:00

Author

Owner

Metadata Update from @kparal:

Custom field story_points adjusted to 2

**Metadata Update from @kparal**: - Custom field story_points adjusted to 2

jgroman commented

2025-12-11 11:51:51 +00:00

Owner

Not sure if it is even possible to do with our current tools but maybe another solution could be having CI watch pull requests and deploy new app test instance every time pull request gets created or updated. This test instance could have URL like https://.testdays.stg.fp.o for example.
The branch would just get pulled from pull request dynamically and this would eliminate need for managing extra staging branch.

Not sure if it is even possible to do with our current tools but maybe another solution could be having CI watch pull requests and deploy new app test instance every time pull request gets created or updated. This test instance could have URL like https://<PR-NUMBER>.testdays.stg.fp.o for example. The branch would just get pulled from pull request dynamically and this would eliminate need for managing extra `staging` branch.

kparal commented

2025-12-12 09:39:12 +00:00

Author

Owner

That's an interesting idea. I don't know how difficult that would be. And it probably would need to use separate databases, because some PRs will do DB migrations.