Our documentation is usually grouping 10-15 Epicor objects (BPM, Function, SSRS, etc.) into something bigger like “Web Integration Documentation”, etc., we almost never have individual object documentation apart from a comment header I put into most non-widget BPMs. That is the level I’d like to get to… a system with an entry for every custom Epicor object with deployment date/times and version history. It’s also a backup repository for our code. And then we could abstract most of the object names out of our “good/detailed” documentation so we don’t touch it every time to update V1 to V2…
We did just spend a lot of time and effort implementing SmartSheets for project and change management. It is working very well for us in terms of task management / approvals, keeping development flowing and everyone on the same page. But it’s not a Source Control system and while the last thing we need is yet another system, I’m hesitant to shoe-horn something into SmartSheets that it wasn’t built for…
If I understand correctly, I found this works until there’s an object shared between two different “solutions” like a BAQ. If that won’t happen to you, then you’re good. Otherwise, I found I was clobbering one artifact instead of merging the changes between the two solutions. Last one in, won.
Separately, I think this was a problem in Solution Workbench if we didn’t rebuild every solution that included a shared object.
I gave up. After all, I’m not modifying Epicor DLLs.
Instead, we focus on change management and project control. No matter how small a change is needed, we fork our entire environment for dev. We make a rollback CAB from prod before “merging”. We do UAT in dev, and for complex changes we first spin up a new fork and test the deployment there before UAT. The goal is to have a scalable fork/merge process that can be delegated to a theoretically infinite number of outside developers, without requiring enormous SOWs from consultants justifying ridiculous hourly rates.
I just want to stop people changing them unless they’re fully tested for functional objectives and existing processes, and unless those changes are part of controlled projects, but we’re only developing inside Epicor’s tools now. Aside from electronic interfaces, but they’re pretty rare.
I think that’s the intent of their “citizen developer” outlook, for better or worse. Knock on wood, I think it’s working for us.
For me at least, this is the whole point of DevOps. I cannot prove I have control over the production environment if anyone can make changes to the behavior of the system without some audit trail and a plan to roll back any changes if necessary.
At an EpiUsers’ Insights session, and to many boo’s in the crowd, @Bart_Elia said his goal was that developers and even admins could not change production (servers or code) directly. Full stop. There should be a test system to stage and check the changes, and then a build service or IaaS service that did the actual building and/or changing of the production system.
Why?
This allows IT people to take vacations. Each process is documented and logged. This goes to @timshuwyirreplaceability maxim. Being the only person to know how to do this makes me a liability to the company, not an asset. Here at PTI we had a deeply embedded consultant pass away, and we still don’t know how much of that code works since we lost the source code too.
In the unfortunate case that a system needs to be built from scratch (fire in the computer room, natural disaster, cyber incident, etc.), all of the instructions to rebuild the system are there and can be automated for a quicker recovery.
Test Systems can be built quickly, and if we’re really good, seeded with our own demo data instead of using production data for better information security.
Upgrades are easier if there is an automated way to compare before and after versions of objects (RDDs, Kinetic UI, SSRS reports, …). This includes comparing the current base version to next base version and then changes from the next base version with our changes.
In my personal opinion, worse. This is why I call these tools Pet Builders. They are great development tools, don’t get me wrong. But they encourage building systems that are difficult to upgrade and recover without some framework to do so. I don’t think it’s fair to blame customers for not upgrading when the tooling promotes development chaos.
Working in a structured and controlled way removes the entire need for this and all of the other threads about documenting changes because the documentation is built directly into the process. I have exceeded my DevOps ranting quota, and I yield the balance of my time to the other fine ladies and gentlemen of this forum.
I am as guilty as anyone else. It is always a matter of time, which is the ultimate constrained resource… but investing the time (using that particular verb advisedly) at the front end really does save money (and hair color).
But yes, fully agree. I want the same limits on me as on everyone else.
Unfortunately, while web hosts have this well automated, easy to use, and all but free (WordPress staging environments for example), enterprise software still acts like this is a big deal and very expensive.
The automation part is challenging, but the process part really isn’t.
I have been using SmartSheet for a ticketing system and also a log of changes made to the system.
By placing the URL on the menu - users can submit their own tickets.
When a row in Smart sheet changes, an email will be sent out the next morning with the changes.
Seems to be working with the 50+ customers that are using it.
I can’t tell you what a great system it’s been. I’ve never had a failed upgrade, and once installed it “just works”. It’s a relief. Not too much, not too little.
You have the choice of using a WYSIWYG editor, or (what we do) Markdown. There is a Markdown preview which updates as you work.
Anyway, do check out the features!
These other options are much better versions of Word (Discourse, Confluence, BookStack, SharePoint, and other ***) and Excel (SmartSheet). There are still extra manual steps to maintain them which require discipline. They do not detect changes to the system to stay up to date, don’t control who can update, etc. Again, better than Word or Excel but doesn’t get to source code comparisons, deployment, etc.
And yes, what I am suggesting is a lot of work. IF there was a common method that was Epicor-enabled, then we all wouldn’t have to come up with our own custom solutions and the work wouldn’t seem so daunting.
We use the customizations tracker spreadsheet and store that in our sharepoint site for our dev team. We instituted, early on, a naming standard where all of our dev objects start with a certain constant. We are also in the early stages of figuring out if GIT will work for us, it’s our standard code repository tool. Of course, the spreadsheet relies on developers remembering to update it each time we create something new…
I’ve also noticed in Pilot right now when making kinetic customizations you have to save then commit them before publishing. I have yet to find where I can look at past commits and review them, but it does store them with a comment somewhere.
My question is what happens to that commit history if you lose your database? Test and Pilot seem to most likely get clobbered in cloud environments, but it happens on prem as well.
Source code (and logging for that matter) are best kept externally IMHO.
LanSweeper is a fantastic, affordable ITAM/Ticketing system that is highly customizable. There are so many options creating the fields, attach documents, respond to the tickets, it integrates with AD, captures time, completely limitless. You can create an asset for Epicor and choose that each time, or create an asset for modules if you wanted. Put support information in the asset, who is allowed to do what (ACL), contact info for each person auto loads. Autoroute tickets. Send epicor alerts into it, paste screenshots, escalate I mean it’s a serious ticketing system and is easy to use when it’s setup. If you have any other compliance, I highly recommend, the onprem version will help out so much. Put your procedures, policies in it - has a home page for users and access controls.
