Creating a pipeline

[moxis]

As I am planning to open this project up to my fellow club members for them to gain more experience in opensource development. I need to make a good pipeline to make development easier for them. For example, they need to be able to easily run their own server to test their own branch.

Some noteworthy things that come to mind are auto-deployment, having a code review/PR procedure.

cc @ryzzaki since I am pretty inexperienced in this area.

[ryzzaki]

I suggest using https://travis-ci.org/ since this project is open source. Write some unit tests to get a good coverage first. We can set up a Travis pipeline to trigger these unit tests on every pushed commit to the feature branch (forbid direct pushing to master). Part of this pipeline could also be a deployment test using a docker container (write a bash script, ssh to your server, and trigger the bash script to try and deploy the docker image of your app).

So the jobs in the CI Pipeline could go like this:

1. Install
2. Build
3. Test
4. Deploy

Check out how the Travis pipeline is set up in this project: http://github.com/dXHeroes/dx-scanner

[moxis]

Forbidding direct pushing to master is definitely essential and it would be nice to require a review from a certain member with strong context on the repository. As I am planning to create a new repository for the frontend as we're migrating to React.js, do you think that this will affect Travis CI pipeline since they might be dependent on each other? Do you suggest that use mono-repo instead? With the new frontend, the backend will just be an internal API written in Flask.

[ryzzaki]

I would not use a mono-repo unless you have a good reason. It makes the management & the deployment of the project harder, especially when you are mixing frontend & backend (they might run independently on different servers if your React app will be server-side rendered - so when you clone the app, you are redundantly cloning either backend or frontend). Also, if the backend server crashes, it won't crash frontend (running independently), so the end user experience is slightly better in this sense. They should also have independent Travis pipelines - so that the jobs are not taking too long to complete for the devs.

As for code reviews, you can add certain members as code owners into the repository. These people will be responsible for the repository management (i.e. code reviews and merging PRs). Check this out: https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners

To do this, create a folder called .github on the root of the repo and add the CODEOWNERS file.