Today want to share with you some ideas on how to organize your team development with Acumatica. In the Asia region we are getting more and more big implementation project where customization is involved. In the same time we have a lot of new ISVs with own development.
With that I’m getting more and more a question on how to organize continues team development with Acumatica. So here I want to answer
* on this image you see Git as a source control. This is only an example and you may use other source controls like SVN, TFS, Mercury and others. Acumatica does not have preferences in source control but internally we use Git.
Here I have few essential organization points for the best result:
- You should have a centralized Source Control, where all developers can push there work when done. And automation scripts can get it.
- All developers should have local version of Visual Studio, Database and Repository. This will ensure independent development and debugging all the time. So if one developer accidentally commit a code with bug, other developers won’t be affected immediately and can continue their work with local version. This also applicable to shared database – during debug you may need to open transaction and go thought your code. In that case other developers will be affected as your transaction will prevent them from committing something to DB (like a lock on numbering sequence).
- Every developer should have Acumatica instance in the same directory and the same name, so this will help to maintain the same references form extension library project (DLL) to Acumatica Site bin folder.
- You can store all the changes and Acumatica related development in the source control.
- Code should be done as part of Visual Studio project.
- UI, database, data changes should be included into customization project and also stored in source control
- Developers may work in separate feature branches and merge work to the main branch only when they are fully ready with development and tests.
- Parts of continues integration (like build, test) can be done locally when needed and automatically on build server from centralized repository.
With that, if I’m a new developer, I can join development with following stes:
- Setup Local Environment
- Install Visual Studio
- Install SQL Server
- Install Source Control
- Install Acumatica into the Predefined place with predefined name. Database can have any name (in is not important here).
- Use Acumatica ERP Installer.
- Open Acumatica and go to Customization Projects
- Create empty Customization project in Acumatica with predefined name. This is needed because we can load customization project files from source control only in scope of the project. Basically to click the button you need to open project first (more info about Acumatica and Source Control you can read here). But this is one time action and as soon as you load your sources once, you won’t need to create project on this instance anymore.
- Restore Development Locally
- Download project from Source Control
- Open and Compile local extension library project (DLL) project in Visual Studio
- Open Customization Project
- Open project and than load customization project from course control folder. You can read more about Acumatica and Source Control here.
- Do Development
- Commit Development
- Save Customization Project changes back to sources folder.
- Commit in local Source Control
- Push changes to centralized repository
If I’m not a a new guy, I can skip the setup part and just straight to point 2.
Hope it will help you to organize you team work better.
Have a nice development!