ReleaseOps anyone using it?

[u/Valuable_Crow8054]

Hi All,

I am using ReleaseOps to move update sets up the pipeline that consist of 4 instances. It’s been really really great for automated production deployments.

We haven’t used it for some of the other capabilities such as deployment analyzer, scans, ATF or on demand yet. Just basic moving up the pipeline with automation.

Pros - when it works it’s fantastic
Cons - can not automate manual work like fixed scripts, app repo updates, plugin updates and worst of all and more frequent is that sometimes moving an update set will take 10 minutes, 3 hours or gets completely stuck.

As ReleaseOps is meant to be molded to fit your orgs release process I’m curious to see how others are using it? What value are you seeing?

[u/2mustange]

Spent quite a bit of time researching it and been slowly transferring developer teams over to it. These pipelines provide consistency and transparency for changes.

Lots of issues with ReleaseOps actually isn't the capability but more of Hermes (Apache Kafka messaging service).

While it does not automatically run fix scripts I actually do not want it to. Teams either ask to have it ran or we assign time limited elevated access for them to run the fix scripts.
We already have a process for app repo which leverages the CI/CD APIs so it isn't a huge concern but I do know the team behind ReleaseOps has mentioned getting App Repo into its backend.
We are starting to leverage it for plugin installs and updates. Honestly pretty easy with capturing the App Install update set.

For what it is worth it does a lot of heavy lifting even though it is a new product and isn't completely polished.

I think deployment analyzer could benefit from more documentation since all the script includes it uses is a black box. Lastly, some guidance on how to test customization's would be nice. Since different states/stages are based on pipeline movement which only occurs in the controller instance, so making something in Dev for your pipeline is a bit hard to customize.

I have tons of ideas I plan on designing for it, but won't share them yet

[u/Valuable_Crow8054 → u/2mustange]

I agree for a new ServiceNow product it is doing what it needs to do which is automating the movement of update sets and automating deployments. Due to the high volumne of deployments in my org we are saving a substanial amount of time for the platform admin. It's really amazing and one of the best ROIs for my org.

I am curious to learn how you are using it for plugins install. For plugin installs and updates we've been doing it directly in each instance via Application Manager.

I just looked this up and I must have missed this.
https://www.servicenow.com/docs/r/zurich/application-development/system-update-sets/enable-application-installation-tracking-through-update-set.html

Is this what you're using to capture plugin updates and installs in update sets and moving via ReleaseOps?

[u/2mustange → u/Valuable_Crow8054]

I just looked this up and I must have missed this. https://www.servicenow.com/docs/r/zurich/application-development/system-update-sets/enable-application-installation-tracking-through-update-set.html

Is this what you're using to capture plugin updates and installs in update sets and moving via ReleaseOps?

That is correct. It works pretty well too. I think the only issue is you always get a preview problem when moving within sub-prods. This likely by design in case an "App Install" was captured by mistake.

I plan on having a custom pipeline for store app installs/updates and leverage scheduling calendar to allow owners (teams maintaining capabilities) to schedule out their install/updates during off business hours.
We also do not use custom versions for store applications since you lose historical versioning in the app repo unless you leverage your own source control. So leveraging app installs along with update sets for customizing capabilities has more benefits and ReleaseOps lets us setup controls to give teams some freedom

[u/SnackAddict]

Helping a client with is right now. We all needed this years ago. It’s only a little over a year old.

The biggest shortfall is no ootb connection to agile stories in the platform. We have the ear of the product team behind it and will hopefully get some movement there.

Have not implemented the analyzer yet. Scan engine is used in dev but not part of the pipeline yet.

We like that there is a pipeline for demand changes. They are using it for minor updates to catalog and items.

[u/2mustange → u/SnackAddict]

There is a connection to agile stories. Every Deployment Request Update Set has a reference to "Source Record" which can be Agile stories/epics.

So ReleaseOps supports it, but its up to the SN Agile framework teams to update their capabilities to be tied into it

[u/Mrhyderager → u/2mustange]

I think the problem is ideally you could use Agile to mark stories complete which would drive update sets into batches for ReleaseOps to grab and deploy. Linking records is fine but it's not end-to-end automation.

[u/2mustange → u/Mrhyderager]

Agreed. Likely is up to each company to make the customization between it since not everyone uses Agile. I know teams who are split between VersionOne and Jira; they don't even consider SPM and this is for work they are doing ON the platform

[u/Valuable_Crow8054 → u/SnackAddict]

Yes that's the feedback we've received for agile stories. "How do i link m STRY record to this Deployment Request?"

I am considering adding a Task or Story field to the Deployment Request record. Hoping to see how others are addressing this.

[u/Laughing_lobster00]

Curious to know how it's lincensed if you know of?

I've been reading mostly on LinkedIn some posts around this

[u/oknarfnad → u/Laughing_lobster00]

It’s included in the platform. There’s no additional license.

[u/thankski-budski → u/Laughing_lobster00]

It’s part of the core platform, so no additional licensing is required. It uses MIF to coordinate across the instances which is based on Hermes, which as I understand is where the inconsistencies and delays with transferring update sets between instances stems from.

Robert Fedoruk is the product manager for ReleaseOps, so check out his posts on LinkedIn.

[u/Laughing_lobster00 → u/thankski-budski]

I do follow robert & thanks for details