Development with several developers

shoeffter

Hi,

at my company are 5 developers that work on the same database/customer and we try to find a solution how we can all develop together.

At the moment we have a dispute where we try to find the best solution.

First solution: All developers work on their own database.
Pro:
- Developers can work on the same object at the same time
- Faster deployment of finished objects
Contra:
- Effort to merge is very high
- Developers have to get the right basis for their development

Second solution: All developers work on a centralised database.
Pro:
- Don't have to merge the objects
- basis for development is clear from the start
Contra:
- Only one change at a time at the same object
- You only can deploy until all changes on overlapping objects are finished

It would be possible to buy/use the Object Manager Advanced or Ifacto Revision for our development.

Would be great to get some feedback how you have solved this in your company
and why one solution is better than the other.

Thanks in advance.

Kind regards,
Steve

mohana_cse06

We are 10 members developers team and we use Lock option available in standard NAV and if I have to change any locked object then I will contact the developer who locked it and ask him to unlock after his changes etc.

kriki

OMA or Ifacto Revision helps for the merging.

All working in the same DB is not a good idea. You need 1 DB for testing and repository. But you should develop on your own DB and when you have finished a block (those blocks NEED to be as small as possible).

Ex. if you work on only 1 DB:
Programmer A: I want to post an invoice, but it gives an error and I am blocked with my development where I need that posted invoice.
Programmer B: That is correct. I am working on the C80 codeunit and I have a lot to do and test, so I will finish it in 3 days.
Programmer A: That means I am blocked for 3 days?
Programmer B: That is correct. And if I need to do it like that, otherwise I can't work on C80.
Project leader: YOU CANNOT BE BLOCKED FOR 3 DAYS!

=> Solution : work on your own DB and then put the objects in or merge.
=> BTW: If you use PRS standards with hooks, merging afterwards should be very fast! Even if you are not using one of the above packets.

lvanvugt

I cannot but say: start using Team Foundation Server = centralized code repository + local development databases (and much more nice features)

Or systems alike like GIT (possibly combined with TFS).

You can read some TFS things on my blog: http://dynamicsuser.net/blogs/vanvugt/a ... fault.aspx

Mat

My team and I had the exact same meeting when we first got into NAV development a few years back. We came from primarily a C# background and were used to using tools like Subversion, Mercurial and so forth. We've got a team of 5 developers and wanted to avoid issues with everyone working in the same database and using the lock/modify functionality within NAV especially considering the size of the project we were about to start on.

We sat down as a team and came up with a solution that's been refined over the years but is really working smoothly now and allows us to handle both the maintenance of existing projects as well as starting new features/projects and keeping everything up to date along the way.

Here's what we've done:

1) We decided to use FogBugz/Kiln from FogCreek Software since this is what we already had in house for our other software development work.

2) We then built a graphical tool in C# using WPF that allows us to directly interface with TortoiseHg (Mercurial/Kiln) and also with NAV using finsql.exe and it's host of command line parameters for import/export/compile of objects *.

3) Developers each work locally on their own local databases. We make sure everyone starts with the same database and periodically update everyone's database when we are at a point where we've just done a major release for example. This is mainly due to setup information in the DB getting out of date if a particular developer forgets to import an XML port.

4) Which brings me to setup information: We do/share this using XML port objects created for each table of setup/configuration information that we want to store. The secondary benefit of this is that by exporting your setup data as XML and storing it in version control you've also got a running history of any changes made to setup information. This has been a lifesaver a number of times for us.

5) Our repository strategy is that of a single main line of development in the trunk for our next major feature release. We then have a separate repository for maintenance work on existing customer sites. When a particular developer starts working on a feature that may take weeks to complete, they make a local branch of the trunk repository and work inside of that. Every day, they simply pull changes from the trunk to keep their code up to date with what everyone else is doing. When it comes to merging, we use the built in tools within TortoiseHg (kdiff3) to handle this right now.

Hopefully that sort of helps? The toughest part at the beginning is just getting used to using the source control tools if you haven't had any previous exposure to it. Once you've got that down though it really becomes pretty painless. There is a good basic Distributed Version Control tutorial on Mercurial/Kiln and how it works posted here: http://hginit.com/

I plan to write a full article on this on my blog shortly. We are just finishing up a NAV 2013 R2 implementation right now so it's been a bit busy but it's at the top of my list after that.

* finsql.exe command line parameters: http://blogs.msdn.com/b/nav/archive/2013/01/28/new-finsql-exe-command-line.aspx

defiant701

I can also just recommend TFS. We have several teams using TFS for their projects. We integrate also our .net teams with their solutions & NAV add-ins. My NAV developers work in just one database using the lock function from standard. We changed also everything to agile development so the we have clear development sprints & releases. Of course then we move to other db's like localized versions. Each way is base version W1 - DEV/QAS/UAT/ISV then local version DE.... - DEV/QAS/UAT/SHC and finally to customer CUST - DEV/QAS/UAT/PRD each transport from one to another environment is done from central release manager. That's also equal to AX development. Except of the build process it's pretty easy to start with TFS.

Jut

Hi Mat,

I am really looking forward to reading your blog-post on that topic! I am especially interested to learn how (and when) you handle the "flow" of objects (text-files) from the local DEV-databases to your centralized dev-system und Test/Production-DB and back to your local databases.

Best regards,
Jut

Mat

Jut wrote:

Hi Mat,

I am really looking forward to reading your blog-post on that topic! I am especially interested to learn how (and when) you handle the "flow" of objects (text-files) from the local DEV-databases to your centralized dev-system und Test/Production-DB and back to your local databases.

Best regards,
Jut

Hi Jut,

I'll be sure to update this thread when I've got it posted! I've started it so hopefully shouldn't be too long. I might do multiple installments. We are going to TechDays (registering today) so I should have some time on the plane!

Mat

Jut wrote:

Hi Mat,

I am really looking forward to reading your blog-post on that topic! I am especially interested to learn how (and when) you handle the "flow" of objects (text-files) from the local DEV-databases to your centralized dev-system und Test/Production-DB and back to your local databases.

Best regards,
Jut

Hi Jut,

Long overdue but finally had a chance to start my blog series on distributed source code control with Dynamics NAV 2013 R2. Check it out if you get a chance.

http://www.nadrofsky.com/source-code-co ... r2-part-1/