Improve upgrading to newer Versions

[t-book]

During a recent conversation on the osgeo-list, the development community reached a consensus on the necessity to simplify the process of maintaining and upgrading installations built on the Geonode project framework. The aim is to enhance user experience and reduce complexities.

The discussion thread, available here, highlights several key considerations that are being explored:

Considered points are:

1. Streamlining .env File Upgrades: Developers are examining methods to detect changes and seamlessly upgrade the .env configuration file, ensuring that changes to environment variables are effectively implemented.

2. Efficiently Upgrading settings.py: The discussion also involves strategies to detect and manage changes in the settings.py file, and possibly even in the local_settings.py file. The goal is to minimize the need for modifications to the settings.py file unless absolutely necessary.

3. Other Considerations: Further points are also under consideration, with the intention of making the overall process smoother and more user-friendly.

Proposed Steps:

To move forward ...

• The first step involves cataloging areas within the upgrade process that require enhancement

• The next phase involves brainstorming solutions to address the identified issues.

Potential Funding Support:

On a related note, @gannebamm has expressed interest in potentially organizing funding to support these improvement efforts.

[t-book]

regarding 1:

quoted from @giohappy

1. when a new project is created the commit for the geonode-project
   template is written to the .env file by the create_env.py utility
2. the upgrade utility retrieves the commit
3. it compares the .env.sample commit with the target branch to which
   you want to upgrade the project
4. it tries to extend the current .env file with any new env var, and
   marks them with a specific comment (similar to the fuzzy translation
   strings)
5. any var in the existing .env file that doesn't match the new
   .env.sample will be marked with a specific comment

a foundation for a script that updates .env can be found here: https://gist.github.com/t-book/bfeaaa3b550558797b3c16567f8a5c88

[ridoo]

For the record: #471

[nicokant]

Is there a documentation on how to upgrade a geonode project (with docker) from a version to another (or even to apply updates from the same branch)?

In my experience, I've used mainly two approaches to do version updates to geonode-projects:

• create a new one from scratch. This is rather drastic, but with breaking changes on projects that have heavy customizations I usually end up rewriting everything from scratch. The data migration is also a problem with this approach.
• Before writing anything create a "Initial commit" with all the code generated by the template. Later when I need to update I generate a new project with the same name and try to rebase my commits on top of the new "Initial commit". These usually works well with minor version upgrades and a few customization commits.

I think that part of the problem is that geonode-project is not a template, but multiple templates (you need to choose the correct branch) with no supported strategy to move from one (branch) to another. The fact that a branch is used instead of a tag makes it even harder to know if your project is currently aligned with the remote branch, since there is no way to know from which commit your project was generated from.

I would rather prefer a strategy that forces me to update my code if I want security patches and that provides a clear support on how to upgrade the template code, rather than having to jump from a branch to another.

I would suggest using a template rendering tool like copier, which is stable, maintained and supports template updates after cloning.