In a lot of projects, this is usually done via README. It tells you what running dependencies to install and how to run certain commands.

This can get harder to maintain as things change, the project grows, and complexity increases.

I see two parts to automate here: actually setting up the environment, and running the application or orchestrating multiple apps.

How do you address this?

  • Dr. Wesker@lemmy.sdf.orgEnglish
    3·
    1 year ago

    My life changed once I discovered dev containers in VS Code. Basically developing within a bootstrapped Docker container.

      • __init__@programming.dev
        1·
        1 year ago

        Dev containers are the shit. We did the readme instructions style at my last job and it took new hires like a full day to set up, propagating changes was a nightmare and shit was always going wrong. We use dev containers now. Everyone gets the exact same version of everything with almost zero opportunity to screw it up. If anything gets messed up, it’s fixed by a rebuild almost every time.

    • r1veRRR@feddit.de
      0·
      1 year ago

      How’s the filesystem performance? Whenever I’ve mounted something into a Docker Container, the performance has suffered. For example, things like NPM/MVN suddenly take way longer.

      • __init__@programming.dev
        1·
        1 year ago

        It depends on how you set it up. You’re going to take a performance hit using a bind mount. The docs recommend putting your workspace into an actual docker volume for better performance, but I haven’t tried that myself cause so far the bind mount has performed “good enough” for me.

  • bahmanm@lemmy.mlEnglish
    2·
    1 year ago

    I work primarily on the JVM & the projects (personal/corporate) I work w/ can be summarised as below:

    1. Building & running the repo is done on the host using an SCM (software configuration management tool) such as Gradle or SBT.
    2. The external dependencies of the repo, such as Redis, are managed via adocker-compose.yml.
    3. The README contains a short series of commands to do different tasks RE (1)

    However one approach that I’ve always been fond of (& apply/advocate wherever I can) is to replace (3) w/ a Makefile containing a bunch of standard targets shared across all repos, eg test, integration-test. Then Makefiles are thinly customised to fit the repo’s particular repo.

    This has proven to be very helpful wrt congnitive load (and also CI/CD pipelines): ALL projects, regardless of the toolchain, use the same set of commands, namely

    • make test
    • make integration-test
    • make compose-up
    • make run

    In short (quoting myself here):

    Don’t repeat yourself. Make Make make things happen for you!

    • r1veRRR@feddit.de
      1·
      1 year ago

      How do you manage JVM versions? We have many older projects that use 8, and some newer ones using 17, for example.

  • Michal@programming.dev
    1·
    1 year ago

    Docker compose to get started quickly. Although docker can be slow on windows so other methods are also documented.