[Feedback Request] Professional server management and deployment.

Discussion in 'Bukkit Help' started by Aikar, Nov 17, 2012.

Thread Status:
Not open for further replies.
  1. Offline


    I'm looking for some advice and feedback on how to handle deployment of Bukkit to production.

    Currently this is our process (which before you criticize, note were trying to get off of this because we KNOW its bad to commit binaries to VCS):

    * Repo for plugin source
    - PluginA/pom.xml
    - PluginB/pom.xml
    - Library/craftbukkit.jar
    - Library/PluginA.jar
    - Library/PluginB.jar

    * Core Repo for the server itself & configuration
    - server/minecraft_server.jar
    - server/bukkit.yml
    - server/plugins/PluginA.jar

    On compile of a plugin, it copies binary to Library folder and too core folder where they are seperately commited.

    So core is mainly a binary only repo... but plugin src is also littered with binaries for plugins to reference.

    So my main goal is to get these binaries out of the repo.

    My gameplan is to setup Jenkins, merge plugins and core repo together, delete all binaries (got a script to rewrite all history to completely remove them from history and bring it to no binary files).

    then upon commit, the jenkins server will compile all files for every commit giving each a build.

    Then it will automatically deploy to a dev server and restart it.

    Then jenkins will have a task to promote a build to release, and then a build to deploy release to stage, then stage to production.

    This is the part I'm wanting feedback and suggestions on. Setting up a maven repo is obvious for the building steps, but im looking for ideas on how to best setup a maven repo that has seperate release and dev branches.

    One idea I can see is tag as Plugin-DEV-SNAPSHOT as version, and on promotion it is rebuilt as Plugin-RELEASE-SNAPSHOT

    Then the deploy process will always pull DEV snapshot for dev, and RELEASE for stage/production.
    Will this work? Feedback and suggestions please :)
  2. Offline


  3. Offline


    this has nothing to do with plugin development...

    this is managing a bukkit server question.

    I could be asking this even if I didnt write my own custom plugins.
  4. Offline


    If you say so.

    Maybe you should read the other 9000 posts in this forum and see that one of these things is not like the 9000 others...
  5. Offline


    Doesn't really matter when there isn't a "Server Administration" forum.

    This is still on topic. It's a help topic about managing my Bukkit server. Just because its more in depth than the normal questions posted here doesn't mean it doesn't belong.
  6. Offline


    You are asking about repositories and compiling... the plugin developers deal with this kind of thing.

    Only trying to help you get the help you are looking for...

    Like I said, read through the rest of the posts on THIS forum, and notice the nature of the problems they address.

    Then go to the dev forum and notice the nature of the problems THEY address... yours only falls into one of those categories.

    Stand by your opinion all you want, but it won't change the fact that you will get faster and better help asking it there instead.
  7. Offline


    I kinda misread that as porn.xml :|
    I tend to scan text xD
  8. Offline


    Now that is completely OFF Topic.
  9. Offline


    It looks like you are really looking to setup something for custom development of plugins, for fast deployment. What I normally do is allow plugin devs their own Jenkins, and use scripts to download that and restart my server when needed.

    I don't like the idea of fully automating the process, as developers (and server admins) can make mistakes, so its always a good idea to watch your server as it starts up.
  10. Offline


    I understand what your saying but I'm not really asking for help on the compiling side -- I got that down.

    I'm asking for help on processes and styles for pushing your files to your server to run them.

    While yeah the other forum is likely read by more people who is best to answer, it feels off-topic to that forum to me.

    I think I have a main idea on how to proceed:

    Start a git repo that is pretty much same as my core but minus binaries.
    This is the foundation of the server, all config files etc and src for our custom plugins

    Start a 2nd git repository that is ONLY .jar binaries of other plugins we use. This repo will have the expectation that history will be rewritten often and squash/delete old commits regularly to keep repo size small.

    On push of either repo, jenkins will start a new task that will compile all craftbukkit/plugins.
    At end of task, it takes all .jar files in the 3rd party repo and all jar files from the fresh compile, merges with the core files, creates a tarball and then stores on the build server.

    This build will represent the entire CB stack ready to go (minus some on deploy config changes since we push same stack to 10 servers)

    Then every commit auto deploys to the stage server and restarts it (testing on dev would be done before commit)

    Once passed from stage, can invoke a different jenkins build to push that package to the production servers.

    I think this is a pretty solid and smooth workflow -- looking for feedback on this workflow now.

    Well our team only consists of 2 of us.. and we manage the server too. We're always still there to look at the logs on deploy.

    Right now our deploy process just does a git pull, stop server, copy files into place, restart. But the process needs to change drastically to support binaries being outside of the main repo.

    Also -- Having jenkins look for things in logs on startup can signal errors on the build.

    IE: Seeing SEVERE in log can mark build plan as unstable and increase exposure of issues.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 29, 2016
  11. Offline


    Mer, just had to be said :3
  12. Offline


    Also I didn't mean to auto deploy to production on commit.

    I meant auto compile and deploy to stg, then we test it, once verified (examine logs and such too) then simply push a button to promote to production and deploy.

    its still same level of review, just automating some of the steps we do manually
Thread Status:
Not open for further replies.

Share This Page