5 years ago, no replies. I am thinking no one anywhere in the Esri universe uses CI/CD.
Last Friday I updated some services and a cascade of widgets and maps stopped working. I really really want to avoid doing that again. I spent this week cleaning up. First I patched up the broken things then spent a couple days getting back to making the actual improvements.
We don't have a tester on our staff (ha ha ha I'm on a county budget but it would be sweet) and no, I don't have a rigorous check list. I used to work in software shops where we separated build, test, release into separate units and I pine for those days. I am willing to code up a test process but have no time or skill to develop and execute extensive test plans manually.
It is hard to stage releases with Esri. Please send me blog postings or (gag) youtubes or helpful links.
Often OVERWRITE is the only path forward Esri provides to us. And it's hard to do OVERWRITE and then OOPS UNDO that!! For me UNDO would be "restore from a backup wiping out all other work for the day". How does that work when data are scattered across several servers and databases? Neither of these options is satisfactory for me.
I guess we can call what we have the "No turning back" strategy.
So... there are actually several problems to solve here.
1) a process for a test build
2) comprehensive automated test before release
3) systematic automated release process
4) roll back without destroying other work (backup tapes are not the answer)
I guess the 1% of Esri customers who have the money have dedicated staff. Only the other 99% suffer. Not going to change here.
I really want to put "Web App Builder, Dev Edition" behind me and move on the Exp. Builder. Yesterday I found out they used the same stupid deployment process - ZIP as output => Copy -> UNZIP. HELLO ESRI let me introduce you to git! BUT let's leave that out for now. What else do I need to think about? I am erasing my whiteboard now so I can think about all this.
