We are currently an on-premise Syteline 10 user. I would appreciate hearing what others are using for Source Control and Form Control and why. Thank you
I looked at FormControl (in CSI 9) and it's not worth it. Especially if you're developing in a large group. I'm doing all of my control outside of CSI using Subversion. I export each component as needed and check in/check out on my desktop.
We use Azure Devops with their native source control, although it also supports GIT repositories, task management, test suites/test cases, review tasks, code pull requests (with GIT), customizable queries and dashboards, kanban boards, etc. Mongoose works with Azure Devops natively as well, just select it in the config setup and provide your repo details.
The task management feature works for our team and is customizable, i.e. custom data, process customization, etc. Integrates with visual studio seamlessly and can be used to manage tasks and run queries instead of going to the web UI. Checkin/commit comments fully supported. These features may be limited in community versions of VS, but I don't know for certain.
I believe you get up to 5 basic users for free after signing up and additional users are relatively cheap. If you or any of your devs have visual studio subscriptions they will already be licensed to use Azure Devops. If anyone has a visual studio Enterprise subscription they will also be able to manage test suites. Otherwise test suite management is a monthly fee. Several free and commercial extensions help customize the system for your needs. There is an online and on-prem version. If you use the online version there are some pre-canned integration services that can do things like integrate to your support ticketing system and the like... probably available for the on-prem version as well, but I'm not certain.
We obviously use it for code source control and we also use it for form control. Form control does have some minor issues, but in general, its a great local backup for your work as it utilizes a master db in your server. Plus, forms and global objects can be checked out so devs don't stomp on each other. Accidentally deleted a form? No problem, get it back with form control. Went too far in modifying that validator? No problem, restore it through form control. Plus, when you utilize form control all form and global object changes are committed to your source code repository, separate from your source code, if desired. This can be used in dev project reviews to compare work with previous versions, generate hotfixes or releases, etc. Form control does have some potential issues with getting out of sync, but its easily resolved, if needed. In my experience, its more about your devs following process protocol than the tools themselves.... generally speaking.
Its not perfect and I'm sure there are other suggestions out there, but it works pretty well for us. We have a team of several developers and support people, project managers and design staff that all use the system daily.
Good luck.
Did you have to pay for your licenses to use Form Control with all your developers, or are you doing all your work as 'sa'?
Very interesting, that's the first time I heard someone actually used this and was happy about it. I'd be interested to see a demo someday (maybe something that could be arranged through Infor, to benefit both of you?).
Yes we have licensed dev configs for this purpose so we can see user names in form control.
That's the problem we have. It's too cost prohibitive to get the licenses we need. Plus, Infor seems to give us the side-eye when we want to purchase the licenses.
Exactly what issues are you experiencing? To be fair we stay fairly current on Mongoose. There were some form control issues in v9 but since early v10 things in form control are pretty good.
In v10 the ability to have a single db was introduced and this made using form control a bit easier.
To be clear, form control does not work for IDOs and the like. However if you use source control within Mongoose you can check IDOs in and out just like forms and global objects. This is the part that is the thing that gets us into some trouble and its where it comes down to people following protocol and having a defined review process in place.
If you're not reviewing the dev work going into source control, its just potential for GIGO.
We use Azure Devops as well, however we do not use built in CSI source control. We use formsync or Application Metadata Transport to export everything out to SQL or XML files and then use the GIT system to push this to DevOps. This allows us to develop using SA only but still have the code pushes display individual users. We then create a batch script that will load all the changes into our production system based on these files.
Hi Bradley – you seem super knowledgeable about source control with infor – I was wondering if I could bounce this off you. I am an infrastructure person and not a developer – but we have a TFS server (TFS 2015) our security team came to us and told us we need to eliminate sharepoint 2013 from the environment, and our TFS server that integrates into infor is the only box we have. According to our research, TFS 2017 also requires SP 2013 – so upgrading is going to get us nowhere. - and then it seems TFS stops at 2017 and switches to devops
A co-worker and I were researching and landed with Dev-ops as a possible option – we are still an on-prem Syteline 9 shop –
Is devops an option for us as well - and if not, are there any other routes –
We've used Azure Devops (online) since 2014. At that time we were using early version 9 of Mongoose and we were able to integrate with devops without an issue, that I remember. Your dev systems will require version 11 of the Microsoft.TeamFoundation.Client library to be installed.
You could standup a temporary configuration to test the devops integration with.
We have recently investigated on-prem Devops 2022. Looks like it would work with Mongoose without an issue.. full discloser, I've not installed nor tested it so take that for what its worth.
