I'd say it would depend on how you're deploying to the production environment. Basically, you can use your `secrets.yml` file to store all of the keys and values. Within each of the values, reference an environment variable. So, within the file, you may have something like this: ``` production: database_password: ``` At least, in this way, you're not storing sensitive information in the codebase. From here, you can set your Environment Variables how you see fit. On a production deployment, it could be through ansible/chef/capistrano that is setting the ENV Vars or something similar.

Have a look at this forum https://forums.mysql.com/read.php?73,170617,185695

It is just a different way to parse the JSON. If you wanted to reference the object, you could do it with something like `version.object['first_name']` but I think that something like `version.changed_object.first_name` appears nicer. It is really just a preference.

You can check the docs for additional tags https://docs.gitlab.com/ce/ci/yaml/README.html#validate-the-gitlab-ciyml Which also includes a validator at /ci/lint. Alternatively, you can make a post request to the ApI https://docs.gitlab.com/ee/api/lint.html

You could try to change the controller endpoint so it's not going to devise, but rather a user controller. So you wouldn't use the `edit_user_registration_path` in the view, but rather something like edit_user. With Devise, you may need to add something like `bypass_sign_in(current_user)` as it will sometimes log a user out on changes. So the edit action of the UsersController may look like this. ``` def update if current_user.update_attributes(user_params) bypass_sign_in(current_user) if params[:user][:avatar].present? render :crop else redirect_to edit_user_path(current_user), notice: "Successfully updated user." end else render :edit end end ```