CI/CD Tooling and dependency management

Hi - I’m not an IIQ developer, I am part of a DevSecOps team that supports all of our developers in setting up CI/CD pipelines. I’ve looked through some of the discussions and other posts on CI/CD and it looks like most of the dependency management is done in ANT, have there been discussions to moving to Maven or Gradle - has anyone in the community done that and if so, what kinds of issues has that caused, and what about SailPoint support for that?

Secondly, from a tooling standpoint, I’m wondering if anyone is using an Artifact repository like JFrog’s Artifactory or anything else. There are a lot of nice security tools to do things like composition analysis that we like to use those tools for and I’d like to take advantage of those tools with the developers working on this platform.

Mainly, we are looking to use the tools that the team and other developers in our company are familiar with. The idea is that it would make support and troubleshooting easier when things go wrong.

Thank you for your consideration.

1 Like

Hey Christian! In the pipelines we’ve set up for various clients, we generally try to leverage the SSB framework and build custom tooling around it to provide more advance pre and post deployment functionality all contained within a service container. Using service containers, we were able to make a cross-platform drop in DevOps solution. In regards to SailPoint support on recommended DevOps practices, they will usually refer you to a partner. When going with a service container push model you can use whatever artifact repo you’d like and have had no issues using JFrog so far for storing both artifacts from the IIQ build process or your service container. We currently are working on a blog post series, “In Sync & Secure” on the forum, but if you’d like more info immediately, feel free to PM me and we can walk you through how we built our solution.

1 Like

Hi Zac,
We aren’t planning on using Containers for the final deployment. We are just creating jar and war files and then deploying those to VMs. More importantly, I guess the question is about the build process, the code repository has a lot of binaries in it, those were the items that I was trying to specifically reference. Can we move those to something like an artifact repository and then reference them in the ANT or IVY build scripts?

Oh no the application isn’t in a container, only the build process takes place in a container and the war produced during that process is exported to JFrog/whatever artifact storage you want using the service container paradigm that’s becoming more popular. You can but you would have to make quite a few modifications to the paths on the out-of-the-box SSB ANT scripts that do the build for you. If you build a service container image containing the SSB project structure and just inject the IIQ repo during pipeline runs, that would work well and keep you from changing the OOB logic. I just posted a blog draft talking about this last week in the blog drafts section if you have access to that.

Looks like I have access to Blog posts and Blog ideas, but not drafts. Any idea when you plan to move that from draft to an official post? I can probably wait a couple of days.

Meanwhile, if you will indulge another question. You spoke above about creating a service container image and injecting that during the pipeline run. I assume that service container is the container that you earlier said is where the build takes place? That sounds like it should be a binary that we should be able to download, why would each sailpoint customer build a unique service container image? Again, forgive these questions if they are super basic, as I said, my role is more of a DevOps person, not a sailpoint developer.

That I am not sure of, the forum team needs to review the posts first, and I think they want to wait for the series to finish and release all of them at once.

And totally fine! I’m a DevOps/SRE guy first then SailPoint dev second :slight_smile: Service containers I think are a bit of a new term but if you go watch DockerCon from this year they have more examples. Microsoft docs has a good explanation of what it is though:

If your pipeline requires the support of one or more services, in many cases you’ll want to create, connect to, and clean up each service on a per-job basis. For instance, a pipeline may run integration tests that require access to a database and a memory cache. The database and memory cache need to be freshly created for each job in the pipeline.

As to why SailPoint doesn’t provide something like this, they defer to partners in matters pertaining to DevOps/automated pipeline standup. They do provide the SSB framework, which stands for Services Standard Build and includes everything needed to perform basic pre-deployment, build, and deployment functionality, as well as provide the structure needed to store an IIQ project in source control. However, every client I’ve worked with has pretty different environments, so you have to tweak and change things accordingly, but overall, you can create a single service container image that works for multiple clients if you’ve worked with the product long enough (this is something my company Instrumental Identity provides) you can encapsulate all the great SSB OOB tools and custom tooling to meet those niche needs in an easy to use drop-in solution being a service container!

In the meantime, I’ll add the blog post to my company site so you can view it sooner or want to just see a demo of what it looks like. The solution we’ve built has some years of maturity, so there are a lot of custom tools and functions in it that may seem strange to non-IIQ folks if you used ours. If you wanted to build your own from scratch the simplest place to start would be to familiarize yourself with SSB and figure out how to put it in a container.

Here you go @iamcbriggs!

Hope this gives you an idea of what we are working with. Let me know if you have any questions!

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.