Why is .env uploaded instead of linked from shared?

[giacmir]

Usually in Capistrano database config and similar are stored in shared and then symlinked using the linked_files directive.
Why in capistrano-laravel .env is uploaded? In this way every developer that access deploys must have a copy of the production .env file.

[ikari7789]

The reason for this is that the environment file could change or be updated between releases. There is no way to guarantee 0-downtime if the .env file is shared between releases.

[giacmir]

I see, but I'm still not convinced that this is the "capistrano way" to handle that file. It works until you are working alone, but for a team having to share a file not in version control between all those that are authorized to deploy is more likely to cause problems than having to be careful when doing a release.

Moreover the .env file won't usually change often, so the problem of "env may change" doesn't seem to me a such critical problem that justifies this "strange" workflow.

Are there some other frameworks that use a similar approach here in the capistrano namespace?

[ikari7789]

In any case, I don't think that symlinking the .env file is a good idea for any application, regardless if other applications do as such. Especially in the case of a rollback, you are then needing to re-upload any old settings you may have had previously.

You also need to consider that Capistrano was originally developed for use mainly with Ruby and Rails projects, which don't necessarily have the same flow as a PHP application.

I will agree though that the .env file doesn't change often, but it does change, and since it is the master configuration, to make it common between every release is just poor management.

I think a middle-road solution could be to copy the .env file from the current deploy into the release directory if .env is not found on the local machine?

[HogeBlekker]

At our company, we were debating the best strategy to achieve the above. We finally ended up creating an env (or whatever you want to name it) folder in the root of our laravel installation and put this in version control. In this env directory, we have different environment configuration files (e.g. server-01, server-02) that are symlinked to .env on every release.

Task Snippet:

namespace :laravel do
    desc "Ensure the proper dotenv is in place"
    task :symlink_dotenv_file do
        if fetch(:laravel_version) >= 5
            on roles fetch(:laravel_roles) do |server|
                # Set current_release variable
                release_path = fetch(:release_path)
                # Create a symlink
                # See http://capistranorb.com/documentation/advanced-features/properties/#accessing-properties
                execute :ln, "-s", "#{release_path}/env/#{server.properties.laravel_env_file}", "#{release_path}/.env"
            end
        end
    end
end

And in our production.rb for example:

server 'server-01.domain.com', roles: [:web, :app, :db], user: 'www-data', laravel_env_file: 'server-01'

server 'server-02.domain.com', roles: [:app], user: 'www-data', laravel_env_file: 'server-02'

[ikari7789]

My team does similar. We create a .env.{environment} file for each environment in the root of our project, copy it to .env when releasing based on the deploy stage, and then we're injecting the secret values into the .env file with Jenkins before running the deploy.

[ikari7789]

Though @HogeBlekker I hope you are not committing the secret values as well into the repository.

[giacmir]

@ikari7789 Yes, capistrano was deployed with RoR in mind, but all web frameworks have a similar approach: a file with secrets that is not under version control and in capistrano is symlinked. When you need to change it you do this by hand (and usually keeping a backup).

Upload .env only when it exists locally can be an idea, but what if me and a collegue have different local versions? since it is not under version control this can cause troubles. Delete local copy after upload? maybe, but what if deploy fails after? I will need to redownload env. I don't see any optimal workflow of automatic management unless you add an external layer (in fact you have jenkins to do this). I was thinking something similar with ansible.

But I think that this gem should not be aware of this external layer and provide a "capistrany" workflow with symlinked env.

As a compromise: add a config flag to disable env upload and let manual management.

[miks]

This is very strange decision to upload local .env to staging/production/whatever when .env can contain secret information like passwords/tokens/etc.
There must be at least option to disable this behaviour.
Before bd066bf commit there was option to bypass upload by simply setting laravel_dotenv_file to "".

[chungth]

@ikari7789 Is there anyway to set .env value when deploy instead of uploading .env file from local ?

Because my team has staging and production server separately and the config information in each server is not the same.

[ammezie]

It will be nice for an option to disable upload local .env file when deploying.

[ikari7789]

Added a switch to disable upload. Please use the :laravel_upload_dotenv_file_on_deploy property.