Example Configurations

This section details some solutions to common configuration requirements. There are other ways to solve these configuration requirements, and there is no one “correct” solution for any of these, so it is better to think of these as examples of what can be done.

Instance owned by one cross-functional team

Background.

This example considers the case where there is one team of users owning the single instance. The team consists of multiple people with different roles. The most common roles in this case are:

  • Developer - will want to be able to kick off builds and modify job configuration
  • Tester - will want to be able to kick off builds, access build artifacts and create SCM tags
  • Manager - will want to be able to manage user roles in the team and create projects
  • Admin - will want to be able to administer the system
  • Read only - will require read access to the system but not be able to download build artifacts

Sample solution.

Create one role for each role of user: developer_role, tester_role, manager_role, admin_role, and reader_role. Additionally, create one group at the root level for each role of user, assigning the corresponding role to each group: developers, testers, managers, admins and readers. Finally add the members to each group as necessary.

Table 8.2. Sample roles for an instance owned by one cross-functional team

Role Permissions

developer_role

  • Job | Configure
  • Job | Build

tester_role

  • Job | Build
  • Job | Workspace
  • SCM | Tag

manager_role

  • Job | Create
  • Job | Delete
  • View | Create
  • View | Delete
  • View | Configure
  • Group | Manage

admin_role

  • Overall | Administer

reader_role

  • Overall | Read
  • Job | Read
  • Group | View
  • Role | View

Table 8.3. Sample groups for an instance owned by one cross-functional team

Context Group Role(s) Member(s)

ROOT

developers

  • developer_role

All the developers

ROOT

testers

  • tester_role

All the testers

ROOT

managers

  • manager_role

All the manager(s)

ROOT

admins

  • admin_role

All the administrator(s) of the instance

ROOT

readers

  • reader_role
  • Group: developers
  • Group: testers
  • Group: managers
  • Group: admins
  • All the people requiring read-only access not covered by the above groups

Instance shared by multiple cross-functional teams

Background.

This example considers the case where there are multiple teams of users sharing the single instance. Each team consists of multiple people with different roles. The most common roles in this case are:

  • Build Manager - will want to be create, modify and delete job configurations
  • Developer - will want to be able to kick off their builds
  • Tester - will want to be able to kick off their builds, access build artifacts and create SCM tags
  • Manager - will want to be able to manage user roles in their teams
  • Admin - will want to be able to administer the system
  • Read only - any authenticated user will require read access to the system but not be able to download build artifacts

Sample solution.

Create one role for each role of user: builder_role, developer_role, tester_role, manager_role, admin_role, and reader_role. Additionally, create two groups at the root level for the administrators and readers, assigning the corresponding role to each group: admins and readers respectively. Use the folders plugin to create folders for the two teams, and in each folder create groups for the builders, developers, testers and managers of the respective teams. Finally add the members to each group as necessary.

Table 8.4. Sample roles for an instance shared by multiple cross-functional teams

Role Permissions

builder_role

  • Job | Create
  • Job | Delete
  • Job | Configure
  • Job | Build
  • Job | Workspace

developer_role

  • Job | Build

tester_role

  • Job | Build
  • Job | Workspace
  • SCM | Tag

manager_role

  • Job | Create
  • Job | Delete
  • View | Create
  • View | Delete
  • View | Configure
  • Group | Manage

admin_role

  • Overall | Administer

reader_role

  • Overall | Read
  • Job | Read
  • Group | View
  • Role | View

Table 8.5. Sample groups for an instance shared by multiple cross-functional teams

Context Group Role(s) Member(s)

ROOT

admins

  • admin_role

All the administrator(s) of the instance

ROOT

readers

  • reader_role
  • System identity: authenticated

Team 1 Folder

builders

  • builder_role

All the build managers in team 1

Team 1 Folder

developers

  • developer_role

All the developers in team 1

Team 1 Folder

testers

  • tester_role

All the testers in team 1

Team 1 Folder

managers

  • manager_role

All the manager(s) of team 1

Team 2 Folder

builders

  • builder_role

All the build managers in team 2

Team 2 Folder

developers

  • developer_role

All the developers in team 2

Team 2 Folder

testers

  • tester_role

All the testers in team 2

Team 2 Folder

managers

  • manager_role

All the manager(s) of team 2


Instance shared by multiple single-function teams

Background.

This example considers the case where there are multiple teams of users sharing the single instance. Each team consists of multiple people with the same role. The most common teams in this case are:

  • Development - responsible for developing a single product
  • SQA - responsible for testing many products
  • DevOps - responsible for deploying many products into production

Sample solution.

Create one role for each role of user: developer_role, sqa_role, devops_role. Then create groups for the sqa and devops teams at the root level assigning the corresponding role to each group: sqa, devops. Use the folders plugin to create folders for each product and within each folder create a developers group assigned the developer_role. Complete the configuration by adding the members of each team as members of the corresponding groups.

Sample roles for an instance shared shared by multiple single-function. teams

Role Permissions

developer_role

  • Job | Create
  • Job | Delete
  • Job | Configure
  • Job | Build
  • Job | Workspace

tester_role

  • Job | Build
  • Job | Workspace
  • SCM | Tag

devops_role

  • Job | Configure
  • Job | Build
  • Job | Workspace
  • SCM | Tag

Sample groups for an instance shared shared by multiple single-function. teams

Context Group Role(s) Member(s)

ROOT

sqa

  • sqa_role

All the people in the SQA team

ROOT

devops

  • devops_role

All the people in the DevOps team

Product 1 Folder

developers

  • developer_role

All the developers of product 1

Product 2 Folder

developers

  • developer_role

All the developers of product 2

Secret projects on a shared instance

Background.

This example considers the case where you want to have a secret project on a shared instance. The project will be worked on by a small team who should be able to see the project, but everyone outside of that team will be unable to see the project.

Note

If somebody has access to the JENKINS_HOME directory, they will be able to see the secret project. Similarly, by creating an appropriate build script, a non-secret project could gain access to the secret project when building on a file system that the secret project has also built on. If it is absolutely critical that the project remain secret, then it may be best to use a dedicated instance for the project.

For most use cases, however, the project is being kept secret from people who both do not have direct access to the JENKINS_HOME directory, and do not have access to creating build jobs or modify the source code.

Sample solution.

Create a group in the project (or folder) for the team of people who will be working on the secret project. Add all the roles that the team will require. Add all the members of the team. Modify the role filters for the project (or folder) filtering out every role (or all but the administrator role if administrators are to be allowed to view the project).

Note

If you are configuring a secret project to which you will not have access, once you apply the role filters you will be locked out from the project, and it will appear as if there is no such project. See the section called “Finding hidden projects” for details on how to recover from accidental lock-outs of this type.

It may also be advisable to create a group for admins of the secret project before configuring the role filters if only a subset of those with the overall administrator role are to be able to see the secret project.