Seamless integration between Tuleap and Jenkins

Jenkins and Tuleap for CI-CD and DevOps

Continuous Integration & Continuous Delivery (CI/CD) is a software engineering practice that aims to reduce the lead time to produce software. It’s a core practice of DevOps approach whose objective is to transform business ideas into working software, test the idea and iterate as efficiently as possible.

Jenkins is the de facto standard for CI/CD. Most of the organizations have several Jenkins servers deployed in the wild, with various level of control over those servers.

Nowadays, most if not all Jenkins “stuff” (of course jobs with pipelines but even configurations with Jenkins Configuration As Code) should be under Source Server control. This is where Tuleap shows up.

The level of intimacy between the tool that hosts the sources, and the tool that does the automation is very high. In an ideal world it should be mostly transparent for the users, and the tools to navigate back and forth. That’s the goal of the new, deeper and seamless integration between Tuleap and Jenkins.

It’s built around following 3 pillars:

• Unified authentication and permission management
• Automation of triggers (Tuleap ➡️ Jenkins)
• Transparent feedback (Jenkins ➡️ Tuleap)

Unified authentication and permission management between Jenkins and Tuleap

Thanks to its powerful and fine-grained permission system Tuleap shines in constrained environments. Such environments are most of the time closed by default and open upon requests/needs. That implies a controlled management of users and groups. It’s even more a thing in environments where people come and leave at a rapid pace (re-organisations, sub-contractors, new hires, etc).

As Tuleap centralizes a large bunch of project’s data and knowledge, it’s the place of choice to define and manage groups of people and grants of permissions. Ideally, when it comes to Jenkins, these consolidated lists of people should be re-used.

That’s the whole point of the combination of Tuleap OAuth2 Server and Jenkins Tuleap OAuth Plugin.

Thanks to those two plugins, Jenkins can completely delegate the management of its user base to Tuleap, creating a Single-Sign-On for people that navigate between the two softwares. In addition to that, user groups defined by projects at Tuleap side, can also be re-used in Jenkins permission system:

In this screenshot, you can see that the Jenkins instance defines default permissions according to Tuleap groups in a specific project. As soon as an administrator adds someone as member of “mozilla” project on this Tuleap instance, the new comer will be granted Jenkins ability to create and run jobs.

Of course this can be tailored to:

• Identify a group of CI maintainers that would be responsible for managing Jenkins. This group would also be granted Git administration access on Tuleap side,
• Identify a group of Product Owner and Support Team. Those groups would only have read-only access to the jobs to keep informed about the status of the builds,
• you name it…

Benefits for the team

• No more time lost when people join the team : add new members in the Tuleap project and they have access to all the resources they need.
• Painless improved security: as soon as the people leave the project at Tuleap side (either removed from project members or account suspended/deleted), they can no longer access the resources.

These benefits are even more important when it comes to Jenkins. As said in introduction, in most companies there are ten’s of Jenkins servers (if not hundreds). Most of the time, those Jenkins are under teams responsibility, unlike Tuleap instance that is often under global or R&D IT team watch.

Development teams that apply sane user management principles belong to fairy tales (:-), especially when it requires monitoring on day-to-day activity (developers are just too lazy for that). That why, Tuleap provides a convenient alternative with a one-shot configuration at Jenkins setup. This ensures safety access during project lifetime.

Automation of Jenkins triggers

Tuleap supports trigger of Jenkins job since ages (it was already possible with CVS & Hudson #OkBoomer). With Tuleap 12.0, we bring it to a new level for Git with a full automation of Jenkins job management, from creation to trigger, completely managed by Tuleap.

This time, it’s with Tuleap Git/Jenkins management and Jenkins Tuleap Git Branch Source help.

Once your Jenkins server is declared at Tuleap side, and your Tuleap project is declared at Jenkins side, you can only care about valuable development tasks:

• When a developer creates a new branch or even a whole new Git repository, the plugins will created corresponding Jenkins Jobs. All you need is a Jenkinsfile to describe how to build your project.
• As soon as a commit occurs, Tuleap triggers a build. No longer need to manually configure each Git repository to associate with Jenkins server.

Benefits for the team

• Less configuration,
• Less manual interventions and maintenance,
• Just focus on the product to deliver.

Transparent feedback

Finally, at the end of build, it’s likely information should goes back to Tuleap. So far, it was possible to do that using the REST API. Tuleap 12 improves Jenkins pipelines with new directives to ease this feedback.

Jenkins Tuleap API plugin provides:

• tuleapSendTTMResults to fully automate transfer of test automation results
• tuleapNotifyCommitStatus reports build status (passed/failed) so Pull Request reviewers know if the code they are reading was vetted by the CI or not.

Benefits for the team

• Efficient and easy to write pipelines lower the DevOps entry bar for beginners,
• Keep experts happy with a simplified maintenance.

Wrap up

With 12.0 release, Tuleap is a major leap forward for IT organization as well as DevOps teams. The former can ship Jenkins servers with sane and safe configurations. The later can focus on their business needs while be compliant with Enterprise requirements, at no costs.

---