You’re offline. This is a read only version of the page.
20
Currently in C/AL, we have a Dev DB, sometimes a Testing DB, and a Live DB. Developers code and test in Dev. Multiple developers lock objects, communicate with each other, and are usually working in different areas of the software. Testers will either test in Dev or the objects are moved to a Testing DB and they test there. Once satisfied, the objects are moved to Live. Yes, I know there are dangers but if careful, developers can be working on different areas of the code that can be developed, tested, and deployed independently of each other.
I understand that the way to do that with GIT would be something like this. Each developer would create a branch, and develop and test in that branch. Testers may develop and test that branch as well. Once satisfied, developers will do a Pull Request back into the Main branch and then when it’s time either create a Release Branch and deploy to live from that or deploy to live right from the main branch.
So my question is with AL, how do you test with the databases. When coding a client specific modification, Dev DB and Testing DB is usually a version of the client’s data. When coding for our ISV, the data in these databases are setup and maintained basically by all the developers and testers. A lot of work is put into that. What I’m saying is, we can’t just test with Cronus data. If a developer creates a branch, and then publishes to the Dev or Test DB. And then another developer creates a branch and publishes to the same DB, they will be overwriting the other developers changes in that DB. That won’t work for many reasons but especially if there are breaking changes, like the second extension removes a new field in the first extension when it overwrites it. You can’t simply change the name of the extension so it appears as another extension in the DB because all of the object and field numbers and names will be the same. So it would appear that each developer would need their own DB to test with. And if a single developer were working on multiple features in that extension that may be tested and deployed independently, then each of those features would need their own DB as well. Of course creating and maintaining different DBs when needed would be a huge time and space issue. Testers would have to keep track of which DB to test in and more importantly, manage data in multiple DB’s. Although, testers might be able to simply test off of the main branch which would only need one Testing DB and the releases to Live would be in a Release Branch.
Anyway, it seems that the “need to test in a database with good data” element to AL really complicates how you would normally test a feature or bug fix with Git, before merging it back to the main branch to be deployed. Am I missing something? Is there a better way of doing this?
