DRBP Internal

Internal Workflow

In order to correctly use Openbravo, it is important to understand and follow the standard workflows.

By doing so, the development and maintenance processes will become more efficient.

By not following or not correctly understanding the workflow, mistakes will be made that will result in inefficiencies, performance and maintenance problems and lengthier development times.

Common mistakes

This is the more generic workflow, the one that should be apply for every development, no matter the size. It does not matter if it is a small bug fix or a big project, both must follow the same steps.

First of all, it is important to notice the actions that should not be done ever.

1. Different instances must never share information directly. When a development is done, the code must not be copied from one instance to another one ever. The change should be updated in another instance using the repository.
2. Everything development must go to test first. Never push to Production a development, no matter how small it is, before having it verified in the Testing environment. This is key to have a stable Production environment. If an Issue is noticed in Test, the problem can be fixed or reverted. If the same Issue is raised in Production, it can become very critical very fast.
3. Test and Production Environments are not Development Environments. Never change code in Test or Production environments. That is why a push from one of those environments should never be pushed to the Repository. Even when a bug is critical in Production, doing a fix directly there instead of doing it in a Development environment may have side effects, like creating a worse Issue in Production itself.
4. There must be one person responsible of allowing the Production Updates. And nothing must be changed in Production without the authorization of this person. This is the best way to keep Production stable.

From Development To Production

Having explained the actions that should never be done, let's explain the basic workflow from development to Production:

1. Update the Development Environment with the latest changes from the Repository. This task is more extensively explained in the section below.
2. Perform the development.
3. Push the development to the Repository. Once the development is finished and tested locally, it can be pushed to the Repository.
4. Update the Test Environment with the latest changes from the Repository. It is a good idea to have a person responsible of the pushes to the Test environment, someone who knows what changes are pushed there. Otherwise it would become too unstable if any developer does a push without control. If there is some development broken in Test environment, nothing should be pushed until it is fixed.
5. Verify the latest changes in the Test environment. Before updating Production, all the latest developments must be stable in the test environment, if they are not, nothing can be pushed to Production. If Test environment is unstable, nothing can be pushed until it is fixed.
6. Update the Production Environment with the same changes as the Test Environment. When Test environment is stable, then the Production environment can be updated. But only with the same changes that the Test environment has, nothing more, nothing else, it should be exactly the same.

Development Environment

This are the recommended steps to follow in the development environment to correctly update it before doing a development and correctly push all the changes when it is done.

1. Prepare before pull. Make sure that there are no changes pending to be commited in the environment:
   • ant export.database (Just in case there are changes in the local database)
   • hg st (To verify that there are no changes pending to be commited)
   • hg out (To verify that there are no commits pending to be sent)
2. Pull changes from Repository.
   • hg pull -u (To update the environment with the latest code)
3. Update the environment.
   • ant smartbuild -Dlocal=no (To update both the database and the needed files)
4. Develop.
5. Export Changes.
   • ant export.database (Retrieve the changes from the Local Database into the Xml files)
6. Commit and push changes.
   • hg commit (Commit the latest changes)
   • hg push (Push the latest commits into the Repository)