Jump to content

Deploying Custom OpenMod Plugins


- Alex -

Recommended Posts

  • Community Leader

  • Member ID:  1
  • Group:  Community Leader
  • Followers:  11
  • Topic Count:  211
  • Topics Per Day:  0.06
  • Content Count:  508
  • Content Per Day:  0.15
  • Reputation:   36
  • Achievement Points:  4808
  • Solved Content:  0
  • Days Won:  36
  • Joined:  07/11/17
  • Status:  Online
  • Last Seen:  
  • Device:  Windows

Deploying Custom OpenMod Plugins
Release, Validation & Rollback
GGU Public Technical Knowledge Base

Public Knowledge Base:
This article is written for both GGU administrators and the wider server-hosting community. General instructions are platform-neutral where possible; GGU-specific practices are identified separately.

 

Applies To

  • Plugin developers
  • Production server operators

 

Prerequisites

  • A built plugin artifact
  • Access to the target server
  • A rollback copy

 

What You’ll Accomplish

Move a custom OpenMod plugin from development into production in a repeatable, auditable way.

 

Deployment Is More Than Copying a DLL

A production deployment should identify the artifact, configuration impact, dependencies, data changes, validation steps, and rollback point.

 

Recommended Release Contents

  • Versioned plugin artifact.
  • Release notes/changelog.
  • Configuration changes.
  • New permissions/commands.
  • Dependencies.
  • Migration notes.
  • Rollback compatibility.

 

Deployment Checklist

  1. Confirm the target server/environment.
  2. Back up current plugin/config/data as appropriate.
  3. Deploy the approved artifact.
  4. Apply required config changes.
  5. Reload/restart as required.
  6. Watch logs from plugin initialization through first use.
  7. Test representative commands and permission tiers.
  8. Record the deployed version.

 

Avoid

  • Building directly on production and leaving no artifact history.
  • Copying a DLL from a developer desktop with no version record.
  • Deploying configuration containing secrets to a public repository.
  • Changing code, configuration, and database schema simultaneously without a recovery plan.

 

GGU Implementation Notes

At GGU, Gitea is the source-control system. In-house plugin deployments should be traceable to a Gitea commit/tag or CI artifact. Pelican is the game-server control plane, but the public deployment principles in this guide also apply to other hosting panels.

 

Upstream References

 

Golden Gamers United — Public Technical Knowledge Base
General guidance first. GGU implementation details second.

Alex Thunderhunter

Alex — Founder & Systems Architect

Building the community, one server at a time.

Community Leader
Link to comment
Share on other sites


  • Replies 0
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.