Local

Local Development

Local Development

Assistance treats local development as a facilitated operating model, not only a developer-laptop checklist. The goal is to make source control, CI runners, collaboration, test dependencies, configuration, and environment parity understandable to the people who choose the workflow, approve changes, and request support.

Use this page to decide what Assistance can operate, what the customer owns, how onboarding works, and what next steps to take.

Facilitated local-development concept#

Facilitated local development can combine several operated components under one support boundary:

ComponentReader choiceAssistance operatesCustomer owns
Managed Git ServerGitLab, Gerrit, Gitea, Forgejo, customer cloud, Assistance-managed, physical server, or hybrid hostingPlatform setup, upgrades, backups, monitoring, runner integration, and runbooks inside scopeRepository policy, user approvals, release decisions, data classification, and legal conclusions
Managed runnersGitHub Actions, GitLab runners, Gitea Actions, Forgejo Actions, isolation model, labels/tags, and capacityRunner fleet design, registration plan, images, monitoring, patch workflow, and queue/failure triageWorkflow logic, protected branches, secrets approval, release priority, and risk acceptance
Managed MattermostCustomer-controlled Mattermost, Slack, or a hybrid communication modelMattermost runtime, approved integrations, backups, monitoring, upgrades, and support handoff when selectedCommunication policy, retention, membership approvals, channel content, and migration decisions
Developer parityLocal containers, test data, config templates, database restore, and commandsBaselines, runbooks, validation checks, support intake, and change recordsWorkstation use, acceptance criteria, product behavior, and internal training

When to use this#

Use this when developers need repeatable local workflows that match CI and production without turning local machines into unsupported snowflakes.

Good fits include:

  • teams choosing where source control, runners, collaboration, and local services should live;
  • teams running developer dependencies, CI services, or internal VMs on Managed Proxmox or Local Private Cloud;
  • development or CI dependencies that need private-network access, predictable capacity, or physical-server economics;
  • retained DevOps, SRE, DevSecOps, or platform support where day-2 ownership must be explicit;
  • audit, release, migration, incident, or onboarding work where decisions and evidence need to be traceable.

This is not a generic vendor manual. Vendor-specific commands belong in the customer runbook only when they are part of the agreed workflow.

What Assistance operates#

Within the agreed engagement boundary, Assistance can operate or support:

  • managed git server setup, backups, upgrades, monitoring, and runner integration;
  • managed runner fleet architecture, labels/tags, image baseline, queue/failure triage, and hardening guidance;
  • Managed Mattermost runtime, approved integrations, support path, and Mattermost-vs-Slack migration notes when selected;
  • toolchain standards, fixture data guidance, migration workflow, test commands, environment parity checks, and onboarding docs;
  • onboarding checklists, implementation plans, production-readiness reviews, support templates, and handoff documentation;
  • planned change requests, maintenance-window preparation, rollback notes, incident triage, and runbook updates.

What the customer owns#

The customer remains responsible for:

  • business priorities, launch timing, acceptance criteria, and internal approvals;
  • cloud, SaaS, identity, repository, communication, and billing accounts unless a different ownership model is contracted;
  • application code, CI workflow intent, data classification, user access approvals, communication policy, and product communications;
  • legal, regulatory, procurement, retention, risk, and compliance decisions based on Assistance-provided evidence.

Engagement models#

ModelBest forTypical Assistance role
Assessment or auditTeams that need a short, evidence-backed planReview current state, identify risks, and provide prioritized recommendations
Implementation projectTeams making a defined git, runner, collaboration, platform, security, or docs changeDesign, build, migrate, validate, and hand over the workflow
Retained operationsTeams that need ongoing DevOps, SRE, DevSecOps, or platform supportOperate agreed components, manage changes, and drive continuous improvement
Emergency responseTeams facing an outage, blocked release, security event, or urgent migrationStabilize, coordinate escalation, document recovery, and produce follow-up actions

Onboarding workflow#

  1. Intake — confirm systems, owners, environments, repositories, providers, communication tools, risk level, and success criteria.
  2. Assessment — review current runbooks, access, alerts, deployment flow, runner behavior, collaboration channels, security controls, and known incidents.
  3. Operating boundary — agree what Assistance operates, what the customer owns, support hours, severity definitions, data boundaries, and approval paths.
  4. Implementation — apply the agreed changes with reviewable pull requests, change records, migration notes, and rollback plans.
  5. Go-live or handoff — validate the workflow, publish runbooks, confirm escalation contacts, and schedule the first review.
  6. Operate and improve — use incidents, failed changes, support tickets, audits, and onboarding feedback to maintain an improvement backlog.

Support and change requests#

Route requests through the agreed support channel with environment, affected service, business impact, urgency, recent changes, and relevant logs or screenshots.

Request typeExamplesExpected workflow
Standard changeconfiguration update, runner label, git project setting, Mattermost integration, access review, docs updateTriage, scope, approve, schedule, implement, and record outcome
Urgent changeblocked release, failing production pipeline, unavailable git server, missing incident notifications, capacity exhaustionClassify severity, stabilize, communicate cadence, implement safest recovery path
Advisory requestarchitecture question, Mattermost vs Slack decision, compliance evidence, migration optionClarify decision, provide recommendation, document assumptions and trade-offs
Incidentoutage, suspected compromise, severe data, communication, or delivery impactOpen incident channel, assign roles, preserve evidence, recover service, publish follow-up notes

Not included by default#

Assistance does not support arbitrary personal workstation customization outside the agreed toolchain baseline. Assistance also does not own customer communication policy, repository policy, CI workflow intent, legal retention choices, or provider-account commitments unless explicitly contracted.

Any stronger SLA, regulated compliance claim, 24/7 coverage, legal responsibility, or provider-account ownership must be written into the statement of work or support agreement.

Managed Git Server

Managed runners overview

Managed Mattermost

Local Private Cloud

Managed Proxmox

Getting started#

Open a support or onboarding request with the service area, current environment, desired outcome, deadline, known risks, and the customer owners for repository policy, runner approvals, communication policy, and access decisions. Assistance will confirm the operating boundary before making production-impacting changes.