It is common in traditional scripting environments to use version control software (Git/Github, SVN, TFS, etc.). This software provides many benefits, the least of which include the ability to track different iterations of code and the ability to tell what changed between versions. Knowing what has changed since the last deployment is helpful for conducting code reviews and ensuring that no code makes it to production that is not expected.
From what I can tell, there is no Boomi equivalent that allows you to know what has changed to any given process since the last time it was modified. It does let you see when the last date/time a change was made to any given component, but it does not show you what was changed.
As the Lead Integration Architect in our company, I need to be able to review code that has been changed by our developers and not require them to keep detailed notes on every change they’ve made. I need to know what components have been modified and are about to be introduced into production.
We have done our best to make components that are re-usable. It is important to know when preparing to deploy a new version of process “A” that a shared component used by process “B” has changed by another developer. It is possible that they have not completed their changes and that shared process is not yet ready for production. If the changes to process “A” are part of an emergency bug-fix it may not be practical to wait for the “B” changes to be completed.
That’s another area where version control software is helpful. In that traditional scripting environment, you would only compile or deploy code that was “checked in” and ready. Mid-stream updates would never be checked in until ready, so emergency hot-fixes or other updates would never be held up. I don’t see any way to replicate that behavior in Boomi.
Has anyone else had similar concerns? How did you address them?