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.org
    link
    fedilink
    English
    arrow-up
    15
    arrow-down
    1
    ·
    edit-2
    1 year ago

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

      • __init__@programming.dev
        link
        fedilink
        arrow-up
        5
        ·
        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.

  • abhibeckert@lemmy.world
    link
    fedilink
    arrow-up
    7
    arrow-down
    1
    ·
    edit-2
    1 year ago

    I use “Dev Containers” in Visual Studio Code.

    • Step 1 - open the root directory of your project in Visual Studio Code
    • Step 2 - say yes when prompted to launch the dev container
    • Step 3 - there is no Step 3.

    You do need to create various config files/etc, but it’s pretty straight forward and only needs to be done once for each project. Those config files are all kept in version control.

    The dev container setup generally matches the production system pretty closely. Depending on the project that ranges from dead simple to exceedingly complex with several servers all of which are built, configured and launched automatically when you open the project. If you need to change a container you just edit the config file and run a command to rebuild all of them. It’s surprisingly fast - thanks to caching at every step to avoid rebuilding the entire environment.

  • bahmanm@lemmy.ml
    link
    fedilink
    English
    arrow-up
    6
    ·
    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!

  • tuto@lemmy.world
    link
    fedilink
    brezhoneg
    arrow-up
    5
    ·
    1 year ago

    Which programming language(s) do you have in mind? Many already have built-in support for this (Go, Rust, Nim), while others have external tools you could use (Python->Poetry). Otherwise, if you want a “fast” (easy to understand) solution, a shell-script might be a fine solution.

    If you want some real power, you could use the nix package manager (as already stated by other comments). It’s easy to install, but you need to learn how to use it, and with that you can easily share dev environments.

  • kicksystem@lemmy.world
    link
    fedilink
    arrow-up
    5
    arrow-down
    1
    ·
    1 year ago

    Nix! And then you can also auto-create your CI/CD environment from Nix. They share a common source, which eliminates whole classes of problems. It’s supsr fast and very awesome when it works, but it has a learning curve. Worth the effort though.

  • Michal@programming.dev
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

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

  • radau@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    1
    ·
    1 year ago

    Typically using Lando which is a frontend for docker-compose which makes it easier for the users unfamiliar with docker to use it to spin up their environments.

  • karlhungus@lemmy.ca
    link
    fedilink
    arrow-up
    1
    arrow-down
    1
    ·
    edit-2
    1 year ago

    For my local team: Generally a container (docker) for local dev. My team uses go so sometimes a Makefile without docker is enough. For other teams i’ve mostly i see docker.

    for multiple apps this can get more complicated, docker compose, or skaffold is what i generally reach for (my team is responsible for k8s clusters so skaffold is pretty natural). I’ve seen other teams use garden.

    hashicorp makes something called waypoint which i’ve never used. Nix people seem to be well liked as well.