1. Dance

    Dance Well-Known Member

    Dance_Dog
    MVP+
    LimboFish
    Guild Master
    Messages:
    4,974
    EDIT: Numbered questions for readability & ease of response

    Hello. I have a few questions about planning out and setting up a development pipeline for a Spigot Minecraft network linked using BungeeCord.

    Testing

    Firstly,

    1. Is there a recommended practice for testing Spigot and BungeeCord plugins?
    2. Would unit testing be ideal, or having a physical testing environment? A mix of both?
    3. If it involves unit testing, how would I go about programmatically testing events, etc?

    Planning and Implementing CI/CD

    I’m not awfully sure where to start here as I have no experience with this. If anyone has a resource that they recommend for learning CI/CD first, that would be lovely.

    1. It looks like GitLab is able to take care of unit testing and building plugins as jar files, but what comes after that?
    2. Is there a simple way to deploy that jar file to a bunch of docker containers, for example?

    Storing Passwords in Prod/Dev Environments

    I hear that a lot of networks have a separate dev network and database (in addition to their main network and database) that they somehow put into their pipeline.

    1. Where would a dev network fit into a pipeline?
    2. Where in this sort of development pipeline would you store sensitive information such as database credentials, API tokens, etc? Should you write them into a config file in the repository itself, or should they be kept out of git? What about a script that copies a .env file from somewhere? If that works, where would that .env be stored?
    3. How could you go about giving the servers different database credentials depending on the environment? It makes a .env file seem like the better option, but how would I copy that into the actual running server?

    ———————

    These may be stupid questions, and I know that there are resources out there that can help me with this, but the number of results online is a bit overwhelming, as are the number of tools that they recommends. I’m having some trouble figuring out where to start.

    If you’d rather not answer these questions, I’d absolutely be grateful if you could point me towards any resources that helped you learn.

    Dance
     
    #1
    Last edited: Nov 30, 2019
    • Hype Train Hype Train x 3
  2. Dance

    Dance Well-Known Member

    Dance_Dog
    MVP+
    LimboFish
    Guild Master
    Messages:
    4,974
    Awfully sorry about that. Fixed :)
     
    #2
  3. Testing
    Testing the plugins on a real server is really a necessary thing to do. There can be many things unit tests simply cannot judge. Of course it may be still good to have them for simple to medium cases, but for any features involving server events, UIs,... , it's always better to launch a server and have a human/some humans to test it.

    Planning and implementing continuous integration/delivery
    There are many CI/CD environments available out there, whose steps to use may differ dramatically. Browse through them, read what features they have to offer and decide which clicks for you. Many of those provide the capability to run commands/scripts on the server, which means after you push your code, it can build the JAR, then push it to the server and restart it automatically.

    Storing passwords in production/development environments
    The "dev" environment is for testing, and the "prod" one is where things actually serve their purposes. You only need to push to production when the current code is ready. There are some approaches, one is to have a branch "prod" where the current production code stays with its own delivery process, pushing to there makes the process build the code, push to the production environment and do whatever it needs to update the prod; and another branch "dev" with a process to push code to the test environment.
     
    #3
    • Like Like x 2
  4. Dance

    Dance Well-Known Member

    Dance_Dog
    MVP+
    LimboFish
    Guild Master
    Messages:
    4,974
    That makes sense, thank you very much. Where do you think it would be ideal to place the test environment in the pipeline? Whenever there’s a merge request so that it can be approved when testing is complete?

    I’ll definitely keep looking into options in terms of CD. Is that something that is typically done in-house?

    I understand that, but thank you still. I was more wondering about where database credentials, API key, auth tokens and things of that nature are stored along the pipeline. They have to be somewhere, after all. Hardcoding is an obvious no, so I was thinking about a config file, or possible a .env file. I just don’t know where to store those in the first place. A lot of big servers have a bunch of server configurations that they can spawn an instance from on command. Should passwords and tokens be stored in those configurations, or...? I’m quite unsure about how to handle sensitive information in a pipeline.
     
    #4

Share This Page