Roll it out to a team

Introduce Prism as a layer around the way your team already works with KiCad and Git, not as a replacement for both at once. This page lays out a rollout in five stages. Each stage has a clear finish line, and you can stop after any of them with something useful in place.

Before you start

Decide who will run the server and who will own the rollout. You need at least two administrators, so access and recovery never depend on one person.

Read What Prism does not do and Concepts. Two limits shape most rollout decisions:

• Every user has exactly one role, so one account cannot be both designer and QA.
• Prism holds review discussion, not the final approval of a change. Approval stays in your Git host’s pull requests or your change-management system.

Stage 1: read-only evaluation

Start with one representative project that isn’t sensitive.

1. Deploy Prism privately with single sign-on. See Deployment and Authentication.
2. Give most participants the viewer role.
3. Import the project and sync it.
4. Check the schematic, PCB, 3D, BOM and history views against what you know of the design.
5. Note how long the first design data build takes and how much disk it uses. Use your largest board for this.
6. Back up the server and restore the backup somewhere else. See Operations.

Done when engineers can find and review a known design without changing how they edit it, and you have restored a backup once.

Stage 2: design review

Choose one team and agree on:

• the branch and pull-request process the team already uses;
• how a review names the commit under review (use commit links, not branch links);
• which comparisons and outputs a review must include;
• where the final approval is recorded;
• who may import, sync, run jobs and resolve comments.

Give the project maintainers designer and keep everyone else as viewer. Run a real change through it: comments on the revision, a Design Comparison against the last accepted revision, and the approval in your usual system.

If your team tracks work in GitHub or GitLab issues, connect the tracker so comments can be published as issues. See Issue trackers.

Done when a written review checklist has been used on a real change. See Comments and Compare two revisions.

Stage 3: outputs and releases

Agree on one KiCad jobset and on where each kind of output lives:

• committed to Git with the design;
• generated by Prism on demand and kept in the Assets Portal;
• released through Release Studio to GitHub or GitLab Releases.

An output in the Assets Portal is a convenience, not a release. When a board goes to manufacture, use Release Studio, which ties the package to one commit and records the designer and QA sign-offs. Assign the qa role to the people who sign releases off. See Release Studio.

Done when one board has gone through a Release Studio release with both sign-offs.

Stage 4: component governance

Import a small, high-value library first, not your whole historical estate.

Responsibility	Role
author and fix catalog components	designer
independent QA	qa
release a component after QA	designer
policy, access and exceptional overrides	admin

Because roles don’t combine, keep authoring and QA with different people. Where one person must cover both, make them an admin, keep the number of such people small, and write down why.

Decide, before you open the catalog to everyone:

• the required fields and approved categories;
• the evidence a part needs: symbol, footprint, 3D model and datasheet;
• whether KiCad Library Convention checks warn or block a release;
• how duplicates, obsolete parts and withdrawals are handled, and who owns them.

See Library Manager.

Done when the first parts have been authored, checked by someone else and released.

Stage 5: placing parts in desktop KiCad

Start this only once the catalog’s release flow is understood.

1. Serve Prism over HTTPS with a certificate every KiCad workstation trusts. See HTTPS.
2. Connect one workstation’s KiCad to Prism and sign in.
3. Place a released test part into a throwaway project.
4. Check where the part’s library files land in that project.
5. Roll the connection out to the other workstations.
6. Decide who supports engineers when placement fails.

See Place parts in desktop KiCad.

Done when placement works on every kind of workstation your team uses.

Team conventions that work

• Edit in normal Git working copies. Prism never edits design files.
• Share commit links in reviews.
• Use Prism comments for technical discussion, but not as your only audit record.
• Require released catalog parts in new designs, with a written exception path.
• Review roles, personal access tokens and connected clients regularly.

Ready for the whole team

You are ready to roll out widely when:

• sign-in, roles, HTTPS and private Git access are tested;
• the largest project builds its design data within acceptable time and memory;
• the review checklist is in use;
• release and catalog roles are assigned;
• desktop placement works on your workstations, if you use it;
• the people who run the server have restored the database, the projects directory and the SSH directory from a backup;
• each limit listed in What Prism does not do that affects you has a written workaround.