Skip to content

Latest commit

 

History

History
68 lines (53 loc) · 3.77 KB

RELEASE_PROCEDURE.md

File metadata and controls

68 lines (53 loc) · 3.77 KB
Raw

Release procedure

Here we will describe a process that takes place after a contributor has successfully integrated his changes to the codebase as well as extension to the documentation etc. into the "develop" branch (by merging pull-requests).

Definition of Release

Changes/extensions in the codebase, e.g. as new features or bugfixes, have a value for our application. We document all changes in a CHANGELOG. In the release procedure these changes are deployed on a webserver. Afterwards the user can use the newly released version online. For this we use two environments that are visible to the public for testing and production.

Release Cycle

We make a new release every first monday of a month. All features and bugfixes which are integrated in the develop branch until then will be released.

Release Content Management

We use projects on github to organize the release. Issues and pull requests can be assigned to a release-project on github by linking the project in the issue/pr. With the project feature of github, all tasks that are linked to the project are organized via a Kanban board.

The project can be linked in an issue or pull request via the menu "Projects"

Required accounts and admin privileges

Basic-Steps for deploy and release (publishing a new release)

Before see How to Contribute

git branching model

  1. Merge all feature and hotfix branches into develop
  2. Starting out in the develop branch, make a release candidate branch (e.g., release-vx.x.x)
  3. Update the oeplatform/versions/changelogs/ current.md (see the examples of previous releases)
    • Change filename to release version (x_x_x.md)
    • Copy template to current.md
    • Update version with bumpversion --allow-dirty [minor|patch]
    • Update the release date in CITATION.cff
  4. Deploy release branch on TOEP.
    • Test the changes
    • Create a hotfix and merge changes into the release branch
  5. merge release branch into master
    • make sure to pull before merge
    • merge master into develop
  6. Deploy the master branch on production OEP
  7. Tag the release number: git tag v<release version>, e.g., git tag v1.2.0
    • versioneer automatically updates the version number based on the tag
    • this is now the official tagged commit
    • Push the tag upstream: git push upstream --tags
    • Alternatively: tag on github platform while creating release
  8. Make a new release on Github
  9. Announce it on our mailing list: [email protected]
    • again, copy the rendered HTML from the Github release directly in the email
  10. Create a GitHub D´discussion to collect feedback

And that's it! Whew...

As stated in the django deployment documentation, every django app has to be served by an external web server. Please make sure to follow the security advise given in the deployment documentation, if you want to host your own version of the Open Energy Platform. Further Notes on how to deploy the OEP are documented here. We also try to make this procedure more userfriendly by introducing docker.