Is there any "standards" way to set up environment variables during development? Like database connect string as environment variable, package manager proxies and the like.
Sure I know of .bashrc, .profile, Windows Gui, launch.json of VSCode, tool-specific settings-files.
But isn't there any more standard? BTW I do not develop within Docker containers.
Related
I'm trying to change the environment config in VS for Mac. In Windows, beside the project, you get a configuration drop down that specifies which environment you want to connect to (connected to launchsettings.json). This isn't available in VS for Mac, and I can't seem to figure out how to set it up.
I've added an ASPNETCORE_ENVIRONMENT variable, but this doesn't seem to change anything. My app is still running against production, even though I'd like it to run against my local database:
Due to a hardware issue, I had to change my work station to another Mac for a few weeks.
It took me a couple of hours to setup everything: Android Studio, git, Apache, MySql, etc...
Could I use a docker image to bundle all my development tools ?
(My goal is to have a "backup" of my development environment that I could start running right away on another machine)
Could I use a docker image to bundle all my development tools ?
That means all your dev tools would be Linux tools working in Linux container, on a Linux host.
You would need to provide that Linux host (on your Mac) through a boot2docker Virtual Machine.
But that also mean you could not directly type "git" from a Mac shell, you would need to connect to your VM first in order to launch your 'git' container and run dome docker run --name=git commands.
So no, this doesn't seem to be a good fit for your backup plan on Mac.
Not necessarily. It kinda depends what you are looking for in a development environment.
I do use it for part of my dev env though.
Vagrant + Docker
My personal approach is to rely on Vagrant to fire up a bunch of environments, some of which being full-fledged VMs and others being lightweight containers.
This is a rather controversial approach though, many people would not agree with it, as the tools overlap, both in terms of platform capability and provisioning.
Docker Containers for 3rd Party Services
My personal approach for this is to use Vagrant to fire up a bunch of different VMs, where one is my main dev VM with tools I use for development (IDEs, editors, SCM tools, etc...), and the rest are Docker containers for 3rd party apps that relate to my daily activities (IRC client, database servers like MySQL or MongoDB, etc...).
This fits my cycle decently as these types of tools (like databases) are not something you generally interact with directly through a tty, but something I'd rather connect to with another tool via an API. So I don't need direct access to them, and I do want them to be isolated and easy to jumpstart and dispose of when I jump between projects.
So, docker containers fit part of my idea of a dev environment, but not necessarily all of it.
Just my use case though. Hope it helps.
Shameless plug: Docker Shell
This tool lets you set up a uniform cross platform development environment inside a docker container.
http://dockershell.io/
I read some articles stating that application configs/parameters should be kept out of version control and be set as environment variables in the production environment.
My question is: How do you manage these environment variables?
Using a configuration management tool like Puppet? What if you are deploying a new version of your app and need to add some new configuration variables?
Your deploy scripts will probably also be in version control so if you set any production variable in there everyone with deploy access can see it. (and tools like Capistrano stores the deploy scripts together with application source code.)
What are the common practice for this?
Thank you for your help.
let's say that RoR development environment is set up and working
does the developer need shell access to develop the RoR application?
would ftp be good enough?
why? I don't want to give my future developers ssh access to my linux box. Or can I set up their file permission so they can read only their project directory?
UPDATE
the whole idea is to have below running on my VPS linux hosting
code repository
production environment
test environment
maybe development environment
for
few projects
that are looked after by different people
so I want the developers to be able to do their job and only be able to access their project files and maybe only I would be able do to deployment into production from test environment
As Tom mentioned, it makes life a lot easier on Rails developers if they have ssh access to the machine so they can migrate the database, run bundle install, check the logs, or just jump into console.
There are ways to segregate users though, through file/directory permissions, chroot, or but making your linux machine a bunch of virtual machines and giving them their own
You can take a look at how Heroku's client works for possible ideas, since Rails developers are able to deploy, migrate, check logs, and even get into the console without direct shell access. Deployment is all done via git hooks and then their client gives access to particular commands. This is not trivial to set up/get working, though.
Well it does not REQUIRE shell access, but it sure makes it easier.
Without it how can you migrate a db? You would have to manually create controllers, models, etc.
Short answer, you CAN develop without shell access, it is just awkward and more tedious.
This is a common situation - for instance, Network Solutions allows you to do the basic RoR install but only gives ssh access if you step up and pay extra for a VM hosting package. My suggestion is to create the app on a local machine, of course using shell commands, then FTP mirror the files up, then use mysqldump to export the local database. NSI allows you a database console whereby you can then import your database dump file. You will probably have to edit config/database.yml since the host database server is unlikely to be localhost. If the necessary gems aren't present, you will have to plead with your hosting customer service.
A server was upgraded from Windows 2000 to Windows 2003 and now I can't access environment variables from Ant build scripts.
I can still access them fine from a command line, but ${env.JAVA_HOME} for instance fails.
How can I fix this without rewriting ~100 build scripts that work on all other servers to be customized for this server?
Unfortunately I don't think you should have been using that environment variable. To get around such problems there's the builtin ${java.home} you could have been using, which isn't dependent on the operating system and/or user's environment being setup properly. (See the Ant manual discussion of built-in properties in Ant.)
You may be able to get around rewriting all your build scripts by either (1) setting the JAVA_HOME environment variable manually, or (2) modifying the ant.bat file to assign it manually. Both options are brittle because they'll break when Java gets upgraded, but at least they'll likely fail fast.