Team Development with Acumatica

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

Acumatica Teamwork Development

* 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:

  1. You should have a centralized Source Control, where all developers can push there work when done. And automation scripts can get it.
  2. 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).
  3. 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.
  4. You can store all the changes and Acumatica related development in the source control.
    1. Code should be done as part of Visual Studio project.
    2. UI, database, data changes should be included into customization project and also stored in source control
  5. Developers may work in separate feature branches and merge work to the main branch only when they are fully ready with development and tests.
  6. 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:

  1. Setup Local Environment
    1. Install Visual Studio
    2. Install SQL Server
    3. Install Source Control
    4. Install Acumatica into the Predefined place with predefined name. Database can have any name (in is not important here).
      1. Use Acumatica ERP Installer.
    5. Open Acumatica and go to Customization Projects
    6. 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.
  2. Restore Development Locally
    1. Download project from Source Control
    2. Open and Compile local extension library project (DLL) project in Visual Studio
    3. Open Customization Project
    4. Open project and than load customization project from course control folder. You can read more about Acumatica and Source Control here.
  3. Do Development
  4. Commit Development
    1. Save Customization Project changes back to sources folder.
    2. Commit in local Source Control
    3. 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!

2 Replies to “Team Development with Acumatica”

  1. 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

  2. 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/

Leave a Reply

Please rate*

Your email address will not be published. Required fields are marked *