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?

  • bahmanmEnglish
    8·
    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
      2·
      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.

      • bahmanmEnglish
        1·
        1 year ago

        I’ve been using sdkman for about a decade now and am totally pleased w/ it. It does a very good job of managing JDK versions for you and much more, eg SBT, Gradle, Scala, Groovy, Leiningen, SpringBoot, …

        Now, technically you could use sdkman in your CI/CD pipeline too but I’d find it a strong smell. I’ve always used dedicated images pre-configured for a particular JDK version in the pipeline.