Hi Everyone,
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!
What should a developer do when the “live” version of our Acumatica instance is hosted by a third party? When I try “Source Control > Save Project to Folder…” or “Source Control > Open Project from Folder…” the file browser is pointed at that third party hosting location, not my actual local machine. This seems to make steps 2 and 4 very cumbersome or impossible without getting access. Am I missing something that makes this more user-friendly?
Even if the live Acumatica instance was hosted on an in-house machine, how does the “Save Projects to Folder” get the customization on a developers machine? I’m trying to get version/source control set up for myself and another developer on our team, but I’m having issues figuring out how to get this working with git (or whichever version control solution).
Hi Case,
As I have mentioned in point #2 “All developers should have local version of Acumatica, Visual Studio, Database and Repository.”.
So that means you shouldn’t do any development on the shared environment. Please use local one.
So the steps are the following:
– You download the project as a zip file from the shared hosting
– You import and publish it on your local machine
– You use “Save Project to Folder”
Hope it helps!
Hi Angelo,
Acumatica Extensibility Framework supports multiple levels of Extensions.
1)Base: public class BLC : PXGraph {}
2)1st Level (Vertical): public class BLCExtension : PXGraphExtension
2)2nd Level (Customization) : public class BLCExtensionOnExtension :
PXGraphExtension
So on Second level you can access and Acumatica and Vertical ISV objects, that will give you control on both. Also with second level extensions you can customize ISVs Graphs and DACs the same way how you do it with Acuamtica's
Second levels of extensions are available for Graphs and DACs.
Read more about it here: https://help.acumatica.com/Main?ScreenId=ShowWiki&pageid=c86fdae8-fef9-4490-aa57-3528d0fa172e
Hope it helps/
Great Article, thanks.
Just one comment, can you expand a little more on instances where a development needs to extend a function which is already customized by a Vertical.
Example 1: A vertical solution has extended the DAC for let's say Customer Screen to add new fields. A local developer needs to extend it further to add new fields. What's the best practice in this scenario?
Example 2: Same situation as above but this time a modified procedure / function needs to be extended. Once again, what is the best practice to do so?
Thanks
Angelo