Clayton can be seamlessly integrated into your Gearset pipeline to automatically review all of your team's work. But which features do you want Clayton to review? What do you want to happen if an issue is found? Should Clayton automatically approve work that has no issues? These are key decisions to make before deciding on how to configure Clayton.
Deciding how Clayton should behave
Which Pipeline
Should you use an existing Gearset Pipeline, or create a new one for the trial? In general, we recommend integrating Clayton into an existing Pipeline so you can see how it will review your real-life metadata.
To configure this: choose the repository you want Clayton working in.
What to scan for
Do you want Clayton to review if features introduce security issues, violate naming conventions, or just make the platform harder to maintain? You can choose from Clayton's 8 policies that scan for Security, Compliance, Reliability, Intentionality, Automation, Engagement, Resilience, and Composability.
To configure this: select the policies you want Clayton to scan for.
When to scan
Do you want Clayton to scan features targeting each environment, or only those awaiting deployment to Integration, for example? Overall, it is best practice to ensure quality gates exist for each environment, but for the purpose of a trial, reviewing all work at the start of the Pipeline can be sufficient.
To configure this: use the "More Options" when setting up a protection mode.
When to view the results
Do you want to see the results of each feature's scan directly in the Pipeline, or simply review it on the PR? To increase deployment speed, we recommend including Clayton's results under the "Reviewers and other checks" section in the Pipeline.
To configure this: choose "Protect what's new" or higher when setting your protection mode.
When to block
Do you want Clayton to block features from being deployed if issues are found in the new work, or simply to leave suggestions? For a trial, and especially if using a real Pipeline, we strongly recommend not blocking the deployment of any features.
To configure this: create branch protections in your respective version control provider. These are compatible with the "Protect what's new" protection mode or higher.
Clayton approvals
Should Clayton automatically approve PRs if no issues are found, or do you want human involvement? Clayton will automatically approve PRs with no violations if using "Protect what's new" or higher, which will affect your workflow if you have existing approvals configured in your version control provider. For a trial, we recommend not configuring approvers for your PRs if these are not already set up.
To configure this: if you already have required approvers set as branch protections, you can choose to either not have Clayton approve PRs (use the "Make suggestions" protection mode), or require additional human approvers (increase the number of required approvers by 1, or assign the codebase to specific individuals using something like a CODEOWNERs file).
Deciding who should access Clayton
Configuring rules
Who should be able to decide which rules are important for the team to adhere to, and which policies should be enabled? For a trial, we strongly recommend at least two "team owners" to ensure uninterrupted access.
To configure this: add these individuals as admins.
Using autofixes
Who should be able to use Clayton's Fixbot feature to automate resolving certain unequivocal fixes? For a trial, we recommend all users to have access to this feature.
To configure this: add these individuals to your Clayton account.
Getting individual insights
Do you want to see the quality of work each individual in your team is producing? Clayton can analyse the quality and quantity of work being committed to your Git repository, and showcase these insights to admins.
To configure this: each individual must add their Git email address to their Clayton account.