Splitting Development and Production

[to-sta]

Terms

• I have searched open and closed issues
• I agree to follow activist's Code of Conduct

Issue

I opened this issue for a general discussion on splitting Development and Production.

What needs to be done?

1. Seperate docker-compose file for prod
2. We need to keep migrations files in sync with prod
3. Splitting backend settings.py into prod and dev settings
   ...

What else do we need to work on?

[andrewtavis]

Ping @momanyisamuel, @wkyoshida 🙃

[wkyoshida]

Should there be a distinction between local and development? By this I mean:

• local would be what contributors work on in their machines
• development would be a live environment apart from production

With this, we could:

• have an environment where changes are vetted and tested before reaching production
• have all credentials, settings, setup, etc. with dummy variables for local so folks can setup their dev environments, but we still have some control over the same in development, i.e. they can be secret

[to-sta]

Yeah @wkyoshida that makes a lot of sense. I think this could be done with a multi-stage deployment. That way we can utilize github secrets for the env. variables and do not need to expose any sensitive data.

Environments:

• Development
• Staging
• Production

Where Staging (staging.activist.org) and Production (activist.org) are deployed and we have an approval step in between Staging and Production.

Do we need to make seperate branches?

Aside from that I think we also need to add a new env. variable for api_root for fetching data from the backend. As soon as we connect the frontend and backend.

[wkyoshida]

Agreed on the above @to-sta 🚀

Do we need to make seperate branches?

We could do a deployment based on branches or one based on GitHub releases. I have found that a GH release = production seems to be a good breakpoint logically - that's been my experience though. Regardless of which strategy however, I'm thinking that keeping the main branch reflecting the staging environment likely makes most sense, since that environment would contain the latest changes - and the version folks would likely want to keep their local development environment updated with. Would that make sense?

If we were to do a GH-release deployment, we also already clear the project board every 2 weeks after every dev sync - so there's an existing cadence we can already follow. After a sync, we could:

• do final validations
• do final tweaks of the release notes
• create a GH release (and we could have a GH Action that does an automatic deployment for us)
• clear the project board

Some concerns worth noting (for completion):

• 2 weeks may be somewhat frequent to have releases for an open-source project. However, we do seem to have pretty consistent contributors (and growing population 🎉), so maybe not an issue in the future 🤷
• Releasing and deploying patches for fixes, security patches, etc. Concerning this, we could always have an off-cycle release if there is something critical

[to-sta]

I am all for the GH-release deployment @wkyoshida. Thanks for bringing this up 💯 (keep's everything simple and lean).

We could start with the 2 week cycle and adjust it in the future. There is still a lot work to be done before we can start with a release cycle.

[andrewtavis]

GitHub releases sound good on my end as well! Thanks so much for the conversation here! 🙏

[andrewtavis]

Ping @anthonyshibitov for an issue that you could pick up :)