I didn't have a chance to check this out at the end of the holiday weekend while I was spending time with family, but I'm looking forward to looking at this tonight. Thanks for your work, @EarthSchlange!

@jaredbeck:

Do we anticipate any situations where dev or troubleshooting will be harder because of the extra layer?

Since this is entirely configured to use Docker, there may be some issues with the initial configuration of Docker and Docker Compose. Especially, if one is not familiar with Docker or containers.

Does it take longer to start the app, or to run a single test?

No. Well once the app has go through the build steps everything gets cached unless the --build flag is applied. Unlike Github Actions, Docker Compose must be explicit. Though, because of the attached volume you don't need to rebuild and reload on general file changes. You do need to rebuild if there is a change within one of your gems.

Can we still use traditional troubleshooting tools, like grepping the postgres logs, or using our chosen ruby debugger, byebug?

I added a PostgresSQL configuration to the docker-compose.yml which will redirect the log_destination of PostgresSQL to stderr. This means that you can run docker logs [postgres_container_id] | grep [search_query].

There is a caveat with running byebug and docker-compose up. That is it cannot be run this way directly; the container will hang (see: docker/compose#3106 (comment)). I have not found a solution other than you need to run your container in detached mode with docker-compose up -d app and docker attach [container_id]. This will provide a tty which you can use byebug when debugging certain parts of the rails app. Note: you may not see anything in your terminal until a byebug break is hit.

2. Our current dev setup is well documented and we've had a dozen people contribute code over the years. That's pretty good for a small org like us! Have we heard anyone say that they'd like to contribute but the setup was too difficult, even with help?

I think @neagle would know more about this. I just saw #172, and I took a shot a resolving it because often a container development setup can help encapsulate some of the steps and eliminate the need to install other software and configure a database and run the server. Thus, making getting started a little easier. New developers would then be able to get started by installing Docker and running docker-compose up app -d. By the way, I already partially using docker for the setup of my local PostgresSQL instance because I can configure everything without having to run any Postgres commands.

3. Certain changes, like removing `database.yml` from `.gitignore` will make it difficult to do development without Docker. Do you think it's possible to support both development models going forward?

Probably, but in my opinion this goes against any benefit we get from encapsulating things with Docker Compose. For example, hiding the build commands i.e., bundler install or the ruby installation or rails server or database configuration.

I'm glad this discussion is happening. When I created #172, I was the only one doing any of current development on the Go Congress website. I created the issue mostly as a placeholder—you may note that I didn't even put in any description text. From my perspective, the goal was to simplify the setup for developers and to reduce the number of external dependencies that must be individually installed on one's system.

When there are external dependencies, my biggest concern is conflicts between projects. Ruby has rbenv, which is an individual solution to that problem so that different projects can use different ruby versions, but what if projects require different versions of postgresql? Or ImageMagick?

On the other hand, we recently removed our main project at work from Docker containers for development, because it was annoyingly slow. We kept mongo itself in a Docker image, but now run the node processes for the back end and front end on their own. There's an equivalent to rbenv, and it's faster to run node natively.

Certain changes, like removing database.yml from .gitignore will make it difficult to do development without Docker. Do you think it's possible to support both development models going forward?

I'd certainly prefer to have as thorough a discussion as we can about the pros and cons of the two approaches, and then stick with one development model.

Right now we have the very, very welcome problem of two other highly knowledgeable and motivated people involved in the project and I definitely want to do our best to coordinate things so we all can have the best experience possible.

Certain changes, like removing database.yml from .gitignore will make it difficult to do development without Docker. Do you think it's possible to support both development models going forward?

I'd certainly prefer to have as thorough a discussion as we can about the pros and cons of the two approaches, and then stick with one development model.

The benefit of using Docker is that we have the ability to essentially hide several of the build layers, installation processes and complexity of getting started. We will be keeping our development environment cleaner and more understandable by using Docker. That is to say, we are defining the our expected environments from within docker-compose.yml and/or a Dockerfile for our Database / Application. This definition means we our developers would have a standardized development / test environment to work form. Any changes to our environment would be reflected in these files.

I don't think keeping two environments (Native Ruby and Docker) is a good idea because could potentially introduce different issues do only to the environment we are running. We would lose some of the benefit of having an development / test environment defined in code, and we are introducing an extra step for incoming developers (copying database.example.yml to database.yml) which can introduce human error.

The downside of doing this is we cannot skip in between layers easily if there is a problem. For example, we cannot simply run $ bundle install to install our dependencies. We would need to rebuild a docker image on each dependency change which may be a good thing. We could have a problem with a learning curve or people not familiar with Docker running into issues getting started, so some of our developers may spend time figuring out Docker vs developing a feature for the Go Congress application. Like @neagle says, we could have an issue with our development workflow being slowed due to changes in how Docker would work and structure our environments.

Thanks Michael for the explanations.

.. we cannot simply run $ bundle install to install our dependencies.

My technique, when updating gems, is to update one at a time, ie. one bundle update per commit. (I wrote a little tool called bunup that does just that) This way, if there's a problem later, I can trace it back to a single commit. So, I work in a quick little loop.

1. Update one gem
2. Run tests
3. Repeat until all gems are up-to-date

Not counting time running tests, each iteration of this loop takes about 15s for most gems.

What would a similar procedure look like in Docker? Would it be as fast (15s/gem+commit)? Would we have to rebuild the container each time?

There is a caveat with running byebug .. you need to run your container in detached mode with docker-compose up -d app and docker attach [container_id].

It's great that you found a way to use byebug, but this sounds less convenient that what we currently have. Are there different ruby debuggers that are easier to use with Docker?