Vraja Development, Testing and Deployment Process

After gathering the requirements, our functional and technical teams analyse the requested changes.

The analysis includes reviewing the standard Odoo functionality, identifying whether customization is required, checking possible impacts on existing modules, and evaluating dependencies with third-party systems.

We also review important considerations such as:

• ✓ Existing customer customizations
• ✓ Odoo version and hosting environment
• ✓ User access and security rules
• ✓ Accounting and inventory impact
• ✓ Third-party API limitations
• ✓ Performance requirements
• ✓ Data migration requirements
• ✓ Upgrade compatibility
• ✓ Possible risks and technical dependencies

Whenever possible, we recommend using standard Odoo functionality before developing custom features. This helps reduce unnecessary customization and makes future upgrades easier to manage.

For larger projects, the requirements may be divided into multiple phases so that the customer can review and approve the implementation step by step.

All new features, integrations, fixes, and customizations are first developed in a separate development environment.

We do not use the customer’s live production system as the primary development environment. This protects active business operations and prevents incomplete changes from affecting real users or live transactions.

During the development stage, our team builds the requested functionality and performs internal testing. Developers review the technical behaviour of the solution, including validations, workflows, permissions, calculations, API communication, error handling, and compatibility with existing modules.

For integration projects, we normally use sandbox credentials, test endpoints, sample files, or development accounts whenever they are available.

The development environment allows our team to safely identify and resolve technical issues before the changes are provided to the customer for testing.

Vraja uses Git for source code management, version control, and controlled deployments.

Every code change is maintained in a repository so that the development history can be tracked. Git allows our team to identify what was changed, when it was changed, and which developer worked on the update.

Using Git also helps us:

• ✓ Maintain separate development, staging, and production branches
• ✓ Review changes before deployment
• ✓ Track code versions
• ✓ Revert changes when necessary
• ✓ Manage multiple developers working on the same project
• ✓ Maintain a clear deployment history
• ✓ Reduce the risk of manually copying incorrect files

Where possible, production deployments are performed from an approved Git branch instead of making direct code changes on the production server.

This approach provides better control, transparency, and accountability throughout the development lifecycle.

Before any customization is moved to staging, the Vraja team performs internal testing.

The testing process depends on the type and complexity of the project. It may include functional testing, technical testing, integration testing, access-right testing, calculation validation, workflow testing, and negative testing.

For example, if we develop a shipping integration, we may test rate requests, shipment creation, label generation, tracking, cancellation, package information, error responses, and multi-company behaviour.

For an EDI integration, testing may include file generation, file imports, field mapping, duplicate prevention, validation errors, acknowledgements, and document status updates.

We also run basic automated tests where applicable. Automated tests help confirm that important workflows continue to work correctly after code changes.

Internal testing is completed before the customer receives the functionality for review.

Once the development and internal testing are completed, the changes are deployed to a staging environment.

The staging environment is normally a copy of the customer’s live production system. It allows the customer to test the new functionality using realistic configurations and workflows without affecting live operations.

The staging environment is used to verify how the changes work with the customer’s actual products, customers, users, warehouses, companies, accounting settings, and existing customizations.

During staging testing, the customer can review:

• ✓ The complete business workflow
• ✓ User access and permissions
• ✓ Reports and printed documents
• ✓ Calculations and validations
• ✓ Third-party integrations
• ✓ Inventory and accounting impact
• ✓ Existing functionality affected by the change
• ✓ User experience and operational steps

Where sensitive information is involved, staging access is restricted to authorised users. Test transactions are clearly separated from live business transactions.

Any issues identified during staging testing are documented, reviewed, corrected, and redeployed to staging for further validation.

Customer testing is an important part of our deployment process.

Although Vraja performs internal testing, the customer understands their daily business operations, internal rules, and real-life scenarios better than anyone else. Customer testing helps confirm that the solution works correctly for the intended business process.

We encourage the customer to test normal scenarios as well as unusual or exception cases. The customer should involve the relevant business users, such as sales, warehouse, accounting, purchasing, management, or customer service teams.

Before moving the changes to production, we request written approval from the customer. Approval may be provided through email, project management software, a signed user acceptance document, or another agreed communication channel.

The approval confirms that the customer has tested the functionality in staging and agrees that it is ready for production deployment.

Production deployment is not normally performed without customer approval, except for urgent fixes that are necessary to restore critical system functionality.

After customer approval, the deployment is scheduled for the production environment.

The production deployment is performed using the approved and tested code version. Our team follows a controlled deployment checklist to reduce the possibility of missing files, incorrect configurations, or incomplete updates.

For changes that may affect active users, we coordinate the deployment time with the customer. Where possible, major deployments are scheduled outside peak business hours.

After deployment, our team performs basic production validation to confirm that the system is accessible and that the main functionality is working correctly.

Direct development on the production environment is avoided.

Any code-level change should first be developed and tested in a separate environment. This helps prevent unfinished or untested code from affecting live users.

Production access is restricted to authorised team members. Access is provided only when required for deployment, investigation, configuration, or support.

Where an urgent production issue requires immediate action, the change is carefully reviewed, documented, and later added to the appropriate Git repository so that the development, staging, and production code remain aligned.

This ensures that emergency fixes are not lost during future deployments or upgrades.

For major deployments, Vraja prepares a rollback plan before moving the changes to production.

A rollback plan explains how the system can be restored if a serious issue occurs after deployment.

The rollback method depends on the nature of the release. It may include reverting the code to the previous Git version, restoring the previous database backup, disabling a new integration, removing a configuration change, or temporarily deactivating a new feature.

Before deployment, we identify changes that may be difficult to reverse, especially database structure changes, data migration scripts, accounting entries, inventory movements, and external API transactions.

Where a complete rollback is not practical, we define an alternative recovery plan to reduce the operational impact.

The purpose of the rollback plan is not only to restore the system but also to reduce uncertainty during critical deployments.

Our objective is to complete deployments with the minimum possible disruption to the customer’s business.

Many code changes can be deployed with little or no downtime. However, some activities may require a short maintenance period, particularly database upgrades, large data migrations, major module installations, server configuration changes, or Odoo version upgrades.

When downtime is expected, we inform the customer in advance and agree on a suitable deployment window.

The customer is provided with information about the expected impact, affected users, activities that should be paused, and any actions required after the deployment.

Where possible, production deployments are scheduled during evenings, weekends, or periods of low system activity.

Odoo upgrades require careful planning because they may affect standard modules, custom modules, third-party applications, integrations, database structures, reports, and business workflows.

Before starting an upgrade, we review the existing database and prepare an upgrade assessment.

The assessment may include:

• ✓ Current Odoo version
• ✓ Target Odoo version
• ✓ Standard installed applications
• ✓ Custom modules
• ✓ Third-party applications
• ✓ Studio customizations
• ✓ External integrations
• ✓ Automated actions
• ✓ Scheduled jobs
• ✓ Reports and print formats
• ✓ Data volume
• ✓ Deprecated technical features
• ✓ Changes in standard Odoo functionality

Custom modules are reviewed and updated to make them compatible with the target Odoo version.

The database upgrade is first performed in a test environment. Our team then installs the upgraded custom modules and resolves technical errors.

After technical migration, functional testing is performed to confirm that important business workflows continue to work correctly.

The upgraded system is then shared with the customer for user acceptance testing before planning the final production upgrade.

The customer should test all important workflows in the upgraded staging environment.

This normally includes sales, purchasing, inventory, accounting, manufacturing, website, eCommerce, shipping, EDI, reports, user permissions, and third-party integrations.

During the final upgrade, the production database may need to be temporarily stopped or placed under maintenance to prevent users from creating new data while the database is being migrated.

A final production backup is taken before the upgrade begins.

Once the database and custom modules are upgraded, our team performs production validation. The customer then confirms that the main business operations are working correctly.

We recommend avoiding major business process changes at the same time as an Odoo version upgrade unless they are necessary. Keeping the upgrade and new feature development separate can reduce testing complexity and deployment risk.

Successful delivery requires clear communication between Vraja and the customer.

Vraja is responsible for developing the agreed functionality, performing internal testing, deploying the changes to staging, resolving confirmed development issues, and supporting the production deployment.

The customer is responsible for providing accurate requirements, required access, sample data, third-party credentials, timely feedback, business-user testing, and final approval.

For third-party integrations, the customer may also need to coordinate with the external service provider for account activation, API access, certification, or production approval.

Any delay in receiving required information, access, credentials, or approval may affect the planned delivery and deployment schedule.

In the event of a critical production issue, an emergency deployment process may be followed.

Critical issues may include system unavailability, blocked business operations, serious integration failures, incorrect financial impact, or major data-processing problems.

Our team first assesses the issue, identifies the business impact, and determines the safest available solution.

Where possible, the fix is reproduced and tested in a separate environment before being applied to production.

When immediate action is required, the fix may be applied under controlled emergency procedures. The change is then documented, added to Git, and tested again in the standard development and staging environments.

Emergency access and direct production changes are limited to situations where waiting for the full standard deployment cycle would create greater business risk.

Vraja Technologies is committed to delivering reliable Odoo solutions through a disciplined and transparent implementation process.

Our development, staging, approval, backup, rollback, and deployment practices are designed to protect the customer’s live system and reduce operational risk.

By following a structured process, we ensure that changes are:

• ✓ Clearly understood before development
• ✓ Built in a controlled environment
• ✓ Maintained through Git version control
• ✓ Tested internally by our team
• ✓ Validated by the customer in staging
• ✓ Approved before production release
• ✓ Backed up before major deployment
• ✓ Supported by a rollback or recovery plan
• ✓ Documented for future maintenance and upgrades

This delivery approach allows Vraja and the customer to work together with confidence while protecting business continuity, system stability, and long-term Odoo maintainability.