What dev environment are people using with Jumpstart Pro?
For the life of me, I'm having a heck of a time trying to start a new app using Jumpstart Pro.
By way of background, I started writing Rails in 2007. Computer Science degree. I'm not an amateur. I run an agency that has multiple customers, and several apps in production on Rails both as HTML interfaces, and APIs connecting to IOS/Android apps that we've developed.
For every other app I maintain, I have a separate "environment" setup with docker/docker-compose.
But, I'm now 1+ day into trying to get the "Jumpstart shell" up and running. And so far, I've had very limited success.
I tried to use the Docker as described around here, it didn't work. So, I ported my own Ubuntu-based setup into Jumpstart. This works and the app can finally boot. But, the way the webpack-dev-server works in Jumpstart seems to not be compatible with the way all my other apps are configured--and in Jumpstart I have no CSS.
I already had two additional learning curves to tackle: Tailwind (vs Bootstrap) and Minitest (vs RSpec). It's beginning to feel like a bad decision to start with this.
But, before I abandon this, how are people's dev environments setup? Do you just mix your environments on a Mac, using local instances of databases for development? Am I missing something fundamental here?
By way of background, I started writing Rails in 2007. Computer Science degree. I'm not an amateur. I run an agency that has multiple customers, and several apps in production on Rails both as HTML interfaces, and APIs connecting to IOS/Android apps that we've developed.
For every other app I maintain, I have a separate "environment" setup with docker/docker-compose.
But, I'm now 1+ day into trying to get the "Jumpstart shell" up and running. And so far, I've had very limited success.
I tried to use the Docker as described around here, it didn't work. So, I ported my own Ubuntu-based setup into Jumpstart. This works and the app can finally boot. But, the way the webpack-dev-server works in Jumpstart seems to not be compatible with the way all my other apps are configured--and in Jumpstart I have no CSS.
I already had two additional learning curves to tackle: Tailwind (vs Bootstrap) and Minitest (vs RSpec). It's beginning to feel like a bad decision to start with this.
But, before I abandon this, how are people's dev environments setup? Do you just mix your environments on a Mac, using local instances of databases for development? Am I missing something fundamental here?
Why the separate environment? I would drop your requirement of using Docker. No need for another layer of indirection and to complicate the setup. Figure that step out later if you need it containerized for production.
Go through the setup outlined in the repo.
https://gitlab.com/gorails/jumpstart-pro#requirements
Just install to your local machine. For me, there are no concerns of mixing environments - Bundler will load only the gems that are required in the Gemfile.
Once you setup your dependencies, configured your database settings, reset your db, you can just issue `foreman start` and that will spin up the server, `webpack-dev-server`, all of the needed processes.
Go through the setup outlined in the repo.
https://gitlab.com/gorails/jumpstart-pro#requirements
Just install to your local machine. For me, there are no concerns of mixing environments - Bundler will load only the gems that are required in the Gemfile.
Once you setup your dependencies, configured your database settings, reset your db, you can just issue `foreman start` and that will spin up the server, `webpack-dev-server`, all of the needed processes.
Why a separate environment?
I have existing, legacy apps we support that run Rails 4 to Rails 6, Ruby 2.3 to (now) Ruby 2.7. Certain gems used in 1 app but not in another have different requirements for libraries that have to be loaded as well. If I don't have separate environments, one app might "conflict" with another one and cause problems where we are troubleshooting our setups--versus troubleshooting the apps themselves.
And, my maintenance efforts for my clients are fixed dollar and time amounts.. if I have to spend a day troubleshooting a setup, especially one that my own environment caused, I don't get paid for that.
So, this is why I'm asking. If you're just working on 1 app.. not in an agency context, maybe it makes sense to do that. But, at least in my case, I've found there to be problems with that approach.
You're right, it's probably easier to just do it all in the "root" that is my machine. But, then, when a conflict happens, the environment isn't isolated and it makes things harder to troubleshoot.
I have existing, legacy apps we support that run Rails 4 to Rails 6, Ruby 2.3 to (now) Ruby 2.7. Certain gems used in 1 app but not in another have different requirements for libraries that have to be loaded as well. If I don't have separate environments, one app might "conflict" with another one and cause problems where we are troubleshooting our setups--versus troubleshooting the apps themselves.
And, my maintenance efforts for my clients are fixed dollar and time amounts.. if I have to spend a day troubleshooting a setup, especially one that my own environment caused, I don't get paid for that.
So, this is why I'm asking. If you're just working on 1 app.. not in an agency context, maybe it makes sense to do that. But, at least in my case, I've found there to be problems with that approach.
You're right, it's probably easier to just do it all in the "root" that is my machine. But, then, when a conflict happens, the environment isn't isolated and it makes things harder to troubleshoot.
Totally understand your concern - I have many separate apps as well. The various package managers do a good job at compartmentalizing the dependencies. With OSX, brew segments binary dependencies by their version number.
With rvm, gemsets are segmented by Ruby version and their own respective versions. You can create a custom set if you desire. Bundler will only load those gems versioned in the Gemfile.lock.
Running multiple versions of Postgres requires each instance running on a different port.
With rvm, gemsets are segmented by Ruby version and their own respective versions. You can create a custom set if you desire. Bundler will only load those gems versioned in the Gemfile.lock.
Running multiple versions of Postgres requires each instance running on a different port.
So, as an example... of my case.. I have different versions of Postgres in production. I had to upgrade my database.. which made my Postgres a different version on my local server than the one running in production for my various apps.
But, I did take your advice and rebuilt and upgraded everything and have bypassed Docker and am now up and running.. so I can start working on developing this app.
I still feel like this is basically doing everything in "root", but chit has to get done.
But, I did take your advice and rebuilt and upgraded everything and have bypassed Docker and am now up and running.. so I can start working on developing this app.
I still feel like this is basically doing everything in "root", but chit has to get done.
If you are already on a mac or linux machine for your local development, you "mostly" don't need docker, to manage multiple versions of rails, python, node postgres etc. Of-course you need right tools. Here's a list of tools that are your friends to make version management through years or projects and computer switching easier:
1. Postgres.app It's a UI to manage local postgres server. It let's you switch the currently running server version in a click of a button
2. RVM Switching ruby versions and gemsets. You can have config files in each project, and tool with auto switch to correct version and gemset
3. NVM Similar to rvm but for node.js versions. node_modules are typically not a concern as they get installed locally to a project by default.
4. venv Similar to rvm but for Python. This may not the the case for most users here, but most of my rails projects are also heavy on data analysis, and python dependencies are almost always required.
5. Homebrew with Brewfiles Home brew being as convenient as it is, can be the cause of major grief through years if not handled correctly. Fortunately using Brewfiles, as described in the linked blog, one can "snapshot" the brew environment much like the rvm or nvm, and maintain a 'per project' brewfile to switch quickly.
That being said, there is a lot of merit in having Dockerized environment for your project. Production deployment apart, if you have multiple developers with varying degrees of expertise, then have the above mentioned setup can be a time consuming learning curve. Dockerized dev environment is a great way to on-boarding new developers quickly.
It's worth mentioning here that there are other options out there. I have personally tried Vagrant a few times, but ultimately keep falling back to docker when I need something like that.
Finally if you are using newer version of Windows 10, then with WSL2, you can do all the above with no issues. Don't even bother with WSL 1 :P
1. Postgres.app It's a UI to manage local postgres server. It let's you switch the currently running server version in a click of a button
2. RVM Switching ruby versions and gemsets. You can have config files in each project, and tool with auto switch to correct version and gemset
3. NVM Similar to rvm but for node.js versions. node_modules are typically not a concern as they get installed locally to a project by default.
4. venv Similar to rvm but for Python. This may not the the case for most users here, but most of my rails projects are also heavy on data analysis, and python dependencies are almost always required.
5. Homebrew with Brewfiles Home brew being as convenient as it is, can be the cause of major grief through years if not handled correctly. Fortunately using Brewfiles, as described in the linked blog, one can "snapshot" the brew environment much like the rvm or nvm, and maintain a 'per project' brewfile to switch quickly.
That being said, there is a lot of merit in having Dockerized environment for your project. Production deployment apart, if you have multiple developers with varying degrees of expertise, then have the above mentioned setup can be a time consuming learning curve. Dockerized dev environment is a great way to on-boarding new developers quickly.
It's worth mentioning here that there are other options out there. I have personally tried Vagrant a few times, but ultimately keep falling back to docker when I need something like that.
Finally if you are using newer version of Windows 10, then with WSL2, you can do all the above with no issues. Don't even bother with WSL 1 :P
Notifications
You’re not receiving notifications from this thread.