search

jpwahle / cs-insights-backend

API server of the cs-insights project. This is the main part of storing data and accessing an external data analysis endpoint. It uses a mongoDB instance to store everything and queries the cs-insights-prediction-endpoint to get machine learning results.
https://jpwahle.github.io/cs-insights-backend/
MIT License
7 stars 0 forks source link

Add release stage with semantic versioning, and deploys to server. #2

Closed jpwahle closed 2 years ago

jpwahle commented 2 years ago

Is your feature request related to a problem? Please describe. Every time new resolved issues get merged into master via pull-request, a new version should be released and a deployment to Heroku should be performed.

Describe the solution you'd like Use semantic-versioning package, and GitHub release action as well as Heroku to run the docker-compose.

Describe alternatives you've considered Deploy to DKE server.

Additional context Links:

jpwahle commented 2 years ago

Don't forget to update the README.md section on how the main and dev branch are used. Sample text from our NLPLand repo:

Deploys and naming conventions

Each feature request, bug, enhancement, etc. has to be related to an issue. We have templates for bugs and features requests when you create an issue on GitHub. An issue should be a closed component that can be implemented by one developer in 1 day. If the issue is larger than that, split it into smaller components. To identify the issue, we use labels such as bug or enhancement.

When you assign an issue to yourself, a branch is created automatically from the dev branch. When you are done developing, you can create a pull request to the dev branch. When multiple issues are merged, and Owner will merge the dev branch into the main branch which will trigger a release and deploy automatically.

We group issues using a task list in another issue that has the Epic label. These issues are larger components that need to be developed. Each issue with the Epic label has a task list with each element of the task list being a issue (e.g., this one in our related repository #47). Whenever a pull request with the above convention gets merged, the corresponding issue gets closed, and the task in the Epic gets checked.

To indicate whether a commit is a patch, minor, or major update, please use #patch, #minor, #major in the commit message. See here for more information what that means.

To build changelogs, each pull-request needs one of the labels "fix", "feature", or "test". See here for more information.

github-actions[bot] commented 2 years ago

Branch issue-2 created!

jpwahle commented 2 years ago

New Git and GitHub deploys, releases, as well as changelogs are automatically created and deployed when a pull request is merged from the dev into the main branch. Every time you want to develop a new feature, create an issue and assign yourself to that issue. This will trigger a GitHub action that creates a new issue from the dev branch. When you are done developing, create a commit with a message that includes "#patch", "#minor", or "#major" according to the semantic versioning specification. Next, create a pull request to the dev branch. Assign the pull request one of the labels "fix", "feature", or "test" so they appear correctly later in the changelogs.