Project Team Member Roles in VersionVault Express

This article will explain the various roles that team members can assume on projects managed by VersionVault Express. A VersionVault Express instance may manage a few projects, and you may find yourself belonging to more than one project team. The role you play on those different teams may vary.

Anyone who has joined any project on a VersionVault Express instance will have access to the “My projects” area. It’s usually the first screen you see when you log in, and you can always navigate there by clicking on the Home icon in the navigation bar.

Any projects you have joined will be shown as tiles on the “My projects” page, but you’ll also see a button inviting you to create a project. When you create a new project, you automatically get the “Project Owner” role for that project.

Project Owner

The “Project Owner” is responsible for managing the project itself and managing the project team members. Managing the project is easy. After it’s been created and it’s up and running, the only tasks left to do are deleting and archiving the project.

Users can either be invited to join the project or simply added to the project. If a user already exists then a Project Owner can add them by simply typing part of their name and then selecting the right user. If a user does not exist yet, and if your VersionVault Express instance has been configured to use an SMTP mail server, a Project Owner can type their email address and send them an invitation to join the project. The Project owner should contact the VersionVault Express system administrator to create a user if SMTP hasn’t been configured; more on that later.

In either case, the Project Owner must select the role or roles for the new project team member. You can select one or more roles and assign them to any new user. A Project Owner can update any team member’s roles at any time, so don’t worry about typecasting team members.

Projects can have co-owners – a Project Owner need only assign another team member the Project Owner role to make them a co-owner. Some Project Owners like to code and/or build, some don’t. If you’re a Project Owner and you want to also do things that other team members can to, simply assign yourself another role in addition to your Project Owner role.

Developer

Most project team members will have the “Developer” role. Developers are responsible for writing and delivering code.

Developers work in streams. A project can, and probably will, have lots of streams. Team members with the “Developer” role can see them by navigating to the “View all streams” screen. A Developer can work in any stream, and can create child streams of any other stream. The two most important streams are the one you’re working on – your ‘development’ stream, and the one you’re delivering to – the ‘integration’ or perhaps a ‘feature’ stream.

When a Developer opens a stream, the first thing they will see is their code. If there’s a README in the project root, it will display below the list of elements (files and directories). If you change to another directory the same rules apply. Developers can add code, view code, download code, edit code and check in changes or save them locally. If your stream has a “Request build” webhook in it Developers can trigger builds on demand.

All users of a VersionVault Express instance can download and install the client – there’s a link on the top right of every screen – but only Developers get to open a client with a simple click from within any stream.

Whenever Developers do any work, they must do so in the context of an Activity. An activity represents a story, a task, a bug, or any other unit of work. Developers can create activities at will, and set or unset them on any stream they’re working on. Developers can also list activities and look at their change sets to keep track of which elements (files and directories) have changed and what changes have been made. When they’re ready, Developers can deliver code in specific activities to their parent (integration or feature) stream.

Although developers don’t have permission to create or recommend baselines, they can look at baselines on any stream. This is essential when choosing to rebase a stream to a particular baseline (which means get the specific versions of the code in that baseline).

Builder

Builders have the responsibility for building and running the CI/CD pipeline. This involves connecting all of the systems, including the source control system, together with the ultimate goal of getting the code built, tested and published.

VersionVault Express defines a specific “Builder” role for this, which means you get to decide if this is a specific role on your team or an additional role for one of your developers (or perhaps even for your Project Owner).

Integration is accomplished with REST APIs – so that external systems can invoke VersionVault Express functions, and webhooks – so that VersionVault Express can invoke functions on other systems. Most of VersionVault Express’s REST APIs are protected by the same credentials with the same permissions as the user interface. (So only a ‘Project Owner’ can delete a project, only a ‘Developer’ can check in a file, and so on).

Outbound webhooks don’t really have any permissions. They just post information to an endpoint that wants it. Configuring and managing webhooks is the Builder’s responsibility. There’s a set of webhooks that belong to the project and a set that belong to a stream on a project. A team member who has the Builder role on a project can create and manage webhooks on that project or on any of the streams within that project. Builders can create new webhooks, configure existing webhooks, look at the delivery history for any webhook and retry any failed webhooks.

Builders only have one other responsibility in VersionVault Express – creating and managing Baselines. A team member who has the Builder role can create baselines on any stream and recommend any baseline. The acts of making and recommending baselines may trigger webhooks, which cause downstream systems in the CI/CD pipeline to spring into action.

System Admin

There’s one more role in VersionVault Express. You won’t see it when you try and assign roles to project team members. That’s because this role, the System Administrator, is not expected to work on development projects.

The System Administrator is responsible for managing the VersionVault Express instance itself. They may configure and launch the underlying virtual machine instance and configure the VersionVault Express instance itself (set its host name, port, SSL certificates, SSH keys, License server, time zone,  SMTP, LDAP and NTP servers).

The System Administrator has access to their own user interface and set of REST APIs running on port 8443 of the virtual machine. Your id and password for this interface will not work with the main VersionVault Express APIs and user interface, so if your System Administrator is also a developer (or a builder, or a project owner) then they will need a second set of credentials.

The System Administrator can SSH into to the underlying virtual machine and perform administrative tasks against the operating system and the VersionVault Express instance, using ‘sudo’ privileges where necessary.

A System Administrator may choose to configure a VersionVault Express instance to use an external LDAP directory. In that case, every user in the configured groups in that directory is automatically a VersionVault Express user – but they still have to create or be invited to join projects and they’ll be given specific roles on specific projects.

Alternatively, a System Administrator may choose to configure a VersionVault Express instance to manage its own uses. In that case the System Administrator assumes responsibility for managing the users. At one extreme the System Administrator may create a single user and instruct that user to create a project and invite more users. As users join the project in any role, they gain the ability to become owners of their own projects and invite more users. At the other extreme, a System Administrator may disable VersionVault Express’s SMTP functionality and take on full responsibility for adding and deleting users. It is likely that your System Administrator will do a little of both and split user management responsibilities with the Project Owners.

Summary

You’ve learned that VersionVault Express users can have different roles on different projects, and that you can mix and match the roles. What other roles should a source control system have? Let me know in the comments.