Customization-tracking tools and patch impact management

What are the tools you use to manage your various customizations (Mongoose Forms, IDOs, Reports; SSRS; SQL SPs, Tables, UETs, etc.)?

And how do you use them to assess patch impact?

I need to find a better way to manage all this and need your recommendations.

So far, I've been describing my customizations in an Excel (Google Sheets) file, in which each tab is a Form (at first) or a Customization (when several Forms/IDOs/SPs/etc. are involved).
This system is becoming messy, being live with CSI for one year already; it's not enough now, since:

  • there are too many tabs
  • the same Form may appear in several tabs
  • there's a second admin/developer now
  • I have a growing list of patches awaiting impact assessment and testing (too time-consuming and messy)
  • we're starting Phase 2, adding Factory Track, Multi-Site, QCS, probably Service, etc.; so new modules, new DBs...new problems!

We're using CSI 9.01.01 on-premise.

I've heard of Form Control; I've seen that Source Control tool can be linked to a User, and that Form Scripts can be automatically opened in Visual Studio (2013/2015).

What are the best options:

  • VisualStudio+GitHub for tracking?
  • FormSync, log-only mode for patches and any diff tool to assess patch impact?
  • Anything else? Where does Form Control come into play in all this?
  • I'm definitely going to be looking at this. Just loaded it up & already look promising!

  • Great discussion, if you have a chance look at Visual Studio Code. It's replaced notepad++ as my go-to editor and has a bunch of plugins, including support for GIT/SVN, built in compare/merge capabilities are good too. 

  • If you use custom assembly code it can be handy to have some CI/CD infrastructure to take the compiled dll/pbd and turn it into XML metadata for import.

    routines like this can help when you have built a library of re-usable functions and want them built from source to take them from dev environments to prod. 

  • Yeah, except it broke as of the May update. It won't let you import the zip file it creates anymore. Plus it also doesn't capture UETs, Events, Background Task Definitions, DataViews, and a lot of other stuff that developers and power users create as part of an overall enhancement to CSI.

  • The reference to the limit of access to the FormSync form - while true if you only access from the application - is not taking into account the ability to access FormSync from the Utility server if you are on-prem.

    I have, also, supported changes by keeping a folder with change per type (forms, IDOs, SPs, etc.) and a log of changes - sometimes with details for a standard form that has had more personalizations than any of us would have wished.  For potentially tricky installations of personalizations I also recommend a specific document for that project so that changes moved into production in the right order/allowing for dependencies.  Yes, it's manual, but it works for companies with 1 - 3 developers.  More people than that would likely fail and increases the chance of unknown overlap.