Content
View differences
Updated by Dominic Bräunlein 9 months ago
**As** a developer
**I want to** to have a local Kubernetes setup with Helm charts charts**
**so that** that I can develop and test OpenProject locally in the same way I did with Docker, but closer to production setup. setup.**
#### **Acceptance Criteria**
* The OpenProject version must run from a local branch:
* Code changes in the local repo should be mounted into the container/pod.
* Assets must reload automatically (hot-reload where possible).
* Support for asset compilation in the container (JS/webpack + Rails assets).
* Running RSpec tests inside a dedicated container must be possible.
* Extra containers with browsers (e.g., Chromium) for system/feature specs.
* Developer experience should match the current Docker setup:
* Local port forwarding works (e.g., [https://openproject.local](https://openproject.local/) → .test).
* Rails console is accessible (kubectl exec equivalents).
* Database migrations can be run easily (kubectl run / make task).
* Local volume mounts for gems/bundler cache and node\_modules to speed up iteration.
* Ability to reset the environment from scratch (DB + Redis flush).
* Configuration should allow switching between local dev mode and image-based setup (similar to prod).
* Setup should be compatible with integration scenarios (Nextcloud, Keycloak, OAuth2, SSO) but allow running OpenProject standalone for day-to-day development.
####
####
#### **💡 Idea for DX**
To simplify workflows, we could introduce some high-level Make targets:
* make dev → start OpenProject from the local branch with mounted code, asset reload, and developer consoles.
* make test → start test container + browsers and access with a console to run the specs.
* make deploy → start a QA-like setup using Docker images (release candidates or published versions).
This would allow developers and testers to use the same tooling but with different modes of operation.
[Docker local setup documentation](https://www.openproject.org/docs/development/development-environment/docker/).
**I want to**
**so that**
#### **Acceptance Criteria**
* The OpenProject version must run from a local branch:
* Code changes in the local repo should be mounted into the container/pod.
* Assets must reload automatically (hot-reload where possible).
* Support for asset compilation in the container (JS/webpack + Rails assets).
* Running RSpec tests inside a dedicated container must be possible.
* Extra containers with browsers (e.g., Chromium) for system/feature specs.
* Developer experience should match the current Docker setup:
* Local port forwarding works (e.g., [https://openproject.local](https://openproject.local/) → .test).
* Rails console is accessible (kubectl exec equivalents).
* Database migrations can be run easily (kubectl run / make task).
* Local volume mounts for gems/bundler cache and node\_modules to speed up iteration.
* Ability to reset the environment from scratch (DB + Redis flush).
* Configuration should allow switching between local dev mode and image-based setup (similar to prod).
* Setup should be compatible with integration scenarios (Nextcloud, Keycloak, OAuth2, SSO) but allow running OpenProject standalone for day-to-day development.
####
####
#### **💡 Idea for DX**
To simplify workflows, we could introduce some high-level Make targets:
* make dev → start OpenProject from the local branch with mounted code, asset reload, and developer consoles.
* make test → start test container + browsers and access with a console to run the specs.
* make deploy → start a QA-like setup using Docker images (release candidates or published versions).
This would allow developers and testers to use the same tooling but with different modes of operation.
[Docker local setup documentation](https://www.openproject.org/docs/development/development-environment/docker/).