Only Modules
All feature requests are implemented as modules.
This includes:
- View modifications.
- New functionality.
- Website/E-Commerce UI changes.
Before Coding
You receive a functional requirement from a Business Process Consultant.
- Check if an OCA module exists to partially or fully satisfy the requirement.
- Check the same on O-Appstore.
- If you determine that you to code a new module, write a readme.md with following sections. You can use writers like ChatGPT.
-
- What is the problem that this module solves?
- Solution description, including if necessary with Figma UI/UX.
- Pre-requisites
- Usage
- Known Issues
Coding
When coding a solution, your module follow following versions:
- Alpha – It's feature complete and you can demonstrate on your local.
- Beta – Minimal testing is successful and it is deployed on the online demo server.
- Minimum Viable Product (MVP) is achieved by further bugfixes and enhancements. Module is released on production.
- Based on customer feedback, Minimum Remarkable Product (MRP) is defined and released.
Submitting Features
Merged by Maintainer
If you are new to our team and setup, someone will review, merge and deploy your code. Follow these steps to submit your features:
- Fork the repo.
- Code your module on any environment of your choice, preferably Linux or MacOS.
- Submit Pull Request (PR) to demo branch.
- A Reviewer/Maintainer reviews (r) your code.
-
- If it's good, it will be merged (m) into demo branch.
- Else changes are requested by Maintainer on Github/repo/pulls.
- Maintainer pulls (p) code on a demo server. More testing on demo.
- If tests are successful, PR is created for main branch.
- Feature is deployed on production.
Self Merging
If you have written a substantial amount of code of Simplify-ERP™ and/or PowerOn™ setups, you can merge and deploy your own code.
- Follow above steps.
- Merge (m) your code.
- Deploy (git pull) your code.
- Post an update on the original Issue on Github carrying following details.
- If tests are successful, PR is created for main branch.
- Feature is deployed on production.
Transferring to Customer/Owner
Following have to be submitted no matter if you self-merge or your code is merged by a Maintainer.
URL for testing:
https://myproject.simplify-erp.de/test-case/..
How to test:
Link to README file in code-base.
Link to code:
https://github.com/euroblaze/myproject/tree/main/odoo-code.
Programmers must be mindful that we aim zero-quality-rejections from customer on
- Scope-completion
-
Code-quality
Test Processes
We employ 3 levels of testing for features and fixes.
Developer Testing
Done by developer who wrote the code himself, possibly using low data volumes, in non-contextual use-cases. This is the lowest level of testing, by nature unreliable.
Owner Testing
Done by the "Owner" that originally requested the coding-task, in broader contextual use-cases, potentially still with limited data-sets.
Customer + PM Testing
PM and customer together test the feature, to ensure full use-case coverage, potentially on live database.
GitHub Issues
GH Issues are used for defining enhancements, bug-reports and new modules.
Issue Description
If you describe an Issue on Github for a new features, ensure structure it into these 3 sections:
- Business Requirement
- Logical Solution
- Odoo Technical Solution
RFQ & RFC
- When an Issue is prefixed RFQ, it means an effort-estimation is expected before coding.
- When an Issue is prefixed RFC, it means further discussion/ideation is necessary.
Submodules
If the functionality of a repo builds on top of a different module, include the base module as a GitHub submodule.
Implementation Schedule
Implementation dates (1, 2), effort estimation (4) and project association (3) are maintained on the GitHub-Issue itself.
Git Cheatsheet from GitHub
Billing & Bonuses
No matter if you are an internal developer or supporting externally, some rules apply.
Estimations
- Estimate the time you need to implement the issue.
- Estimate the day you aim to deliver the issue.
- The start_date is the day you are requested to estimate.
- Commit maximum to your weekly available time-budget.
Billing
- Issues can be passed on to billing/bonus when deployed on prod and it is submitted to customer by email. This is marked by the status "Done" on the GH-Issue.
Types of Work
As an experienced Odoo developer, you will work on following types of work:
- Version upgrades (currently v16, v18). Upgrade modules and use OpenUpgrade for database upgrades.
- Production support / go-live support.
- New module conception, documentation and programming.
- Refactoring existing modules.
- Enhancements to existing modules.
Tool Fluency
As an Odoo developer, you will demonstrate 2+ years of fluency in the following tools:
- GitHub
- Linux – NGINX webserver
- Docker
- Odoo Technical Framework
Documentation
“Code is more often read than written.”
We write inline code documentation. Guidelines for writing documentation are:
- Explain WHY the class/method. (What the it does is then easy to understand by reading the code).
“Code tells you how; Comments tell you why.” – Jeff Atwood
- Mention references to UI where this code impacts.
- Mention to-dos for future developers to fix or enhance the code if necessary.
People & Pods
There are normally only 4 people involved in the execution of an Issue/Task.
We call our execution units “pods”.
- 1 Dev of task – programs the task, tests it locally, merges & deploys to staging and provides to the rest of the pod for feedback.
- 1 Maintainer of project – performs end-to-end contextual testing and deploys to prod server.
- 1 BA/project-manager – Active at the beginning of the project (for definition) and end (for UAT).
- 1 Customer – Finally UAT, driven by budgets, delivery dates and business outcomes.