HACKER Q&A
📣 shtubi

What challenges did you face once you gave devs access to Jenkins jobs?


Hey, I am a DevOps engineer at a medium-sized company.

Our team is super busy and we have a lot on our plate. Recently we decided to see where we can improve our productivity. One of our main responsibilities is to provide dev teams with different services they require (usually they open a ticket, sending a slack msg, etc…). As part of our efforts to improve productivity, we recently decided to assemble the most common popular “services” provided to devs and automate them using Jenkins. In addition, we allow devs to access Jenkin’s UI to spin up all kinds of jobs.

On one hand, it does allow devs to act on their own, on the other hand, I get a lot of backfires from different personas...

Devs

* Why did this job fail?

* Devs send me messages on slack that they got lost between all the Jenkins jobs, and they don't know which Jenkins Job is relevant for them. "I forgot the identifier of the machine I created"

* Devs make mistakes and deploy to the wrong environment.

* Why did my dev environment get terminated?

* "Update me if you modify parameters"

* etc...

Team lead

* Let’s add a manual approval for these jobs

* Make sure we have an audit log for every dev operation

* Make sure we devs are not spinning to many machines

* The developer team leader asked BI about these Jenkins Jobs because it became critical for developers' day-to-day.

* etc…

Jenkins seems pretty limited to allow these capabilities and I am afraid to create a tech debt and put too much pressure on Jenkins :)

Do you have any suggestions? How do you manage it within your company?

Thanks!


  👤 iwwr Accepted Answer ✓
It looks like the challenge is tracking cloud resources created as part of a CI infrastructure and not Jenkins itself. Jenkins can be nothing but a scheduling and execution engine, not quite a self-service platform for business workflows.

It may help more to define more precisely a few scenarios where you experience problems, so people can be more specific with suggestions.

Lacking more specific information, you might consider putting automatic self destruct / deprovisioning for created cloud resources, e.g. 7 days, so you don't worry as much about what is created. What also helps is idempotency in these scripts, to just tell developers to retry things if there are transient errors.


👤 boguyona
We also were in this phase. So first, we searched for some other tool to expose scripts, and we even tried Rundeck, but then we just built a custom "DevOps Portal" that made sense for our requirements.