修改Capfile,在正式环境不再使用migration修改数据库

原因是这样的,运维不开放正式环境数据库的alter权限,所以每次都要给他们把sql语句发过去,

由他们来操作。

参考的是https://github.com/capistrano/rvm/issues/49

Using the task pattern described before, capistrano/rvm gets required after capistrano/bundler. This makes capistrano use the command bundle exec ruby --version. This command would fail on the server when it is run inside a directory without a Gemfile.

There are two ways to make this work:

1) Avoid using bundle exec for all ruby commands:

Capfile

task :require_rvm do
  require ‘capistrano/rvm‘
end
task ‘staging‘ => [:require_rvm]

require ‘capistrano/bundler‘
config/deploy/staging.rb

set :bundle_bins, %w(gem rake rails)
2) Require bundler the same way we require rvm:

Capfile

task :require_rvm do
  require ‘capistrano/rvm‘end

task :require_bundler do
  require ‘capistrano/bundler‘
end

task ‘staging‘ => [:require_rvm, :require_bundler]
task ‘production‘ => [:require_bundler]

以下是最终修改后的Capfile

task :require_rails do
  require ‘capistrano/rails‘
end
# require ‘capistrano/rvm‘
require ‘capistrano/rbenv‘
# require ‘capistrano/chruby‘
task :require_rails_without_migrations do
  require ‘capistrano/bundler‘
  require ‘capistrano/rails/assets‘
end
# require ‘capistrano/rails/migrations‘
# require ‘capistrano/passenger‘

task :staging => [:require_rails]
task :production => [:require_rails_without_migrations]
时间: 2024-09-28 21:43:35

修改Capfile,在正式环境不再使用migration修改数据库的相关文章

模块化之后的项目在正式环境中的数据迁移(含代码生成器)

先说下背景,项目以前一直使用EntityFramework中的自动迁移功能,虽然一开始就知道存在一些不妥的地方,但由于时间原因一直没有更改这个方式,而这一次由于协同开发的人越来越多不得不进行改造. 为什么不再使用EntityFramework的自动迁移功能 1.迁移过程不可控 EntityFramework自动迁移所生成的脚本我们不可见,并不知道执行了什么内容,这对正式运行的项目是一个很危险的因素. 2.可能存在表丢失的情况 因为项目是模块化的,所以当一些模块在特定的情况下(我们当然希望是100

正式环境数据迁移到测试环境及测试环境LAMP搭建

参照正式环境扩展模块来搭建测试环境,否则访问不了 PHP 代码 PDO.PDO_MYSQL.OPENSSL.SSL.CURL等扩展模块 正式环境 Windows Server 2008 R2 X64 Apache+MySQL+PHP+FTP服务 备份MySQL.PHP.APP数据 通过anv软件连接MySQL数据库备份 将 goshop数据库备份,格式为goshop.sql 通过Filezilla软件连接FTP服务,备份PHP及APP数据 正式环境数据备份好后,开始搭建测试环境,将数据上传至测试

ODI开发环境往正式环境迁移问题

      正式环境安装的模式为运行时,因此只需要把主资料库的相关信息和场景导入到正式环境 同步数据库表结构 资料档案库的同步(只需要一次,以后就不需要了,除非修改了拓扑结构) 在开发环境将ODI的接口都测试通过后,生成场景 再将开发环境的场景导入正式的工作资料库,第一次导入方式采用同义词插入的方式,如此做的原因为以后如果开发环境的数据发生修改后,可以用同义词更新的方式导入正式环境,只有这样,才能保证下次导入的时候是更新的形式. 正式环境配置调度 下面的来自 ODI开发环境往正式环境迁移问题,没

Apache htaccess Minify 正式环境不访问的重写规则

Google Project Minfiy 放到网站根目录 /min/ 下. 如果是正式环境(判断条件,域名HTTP_HOST中存在 . 点号就判断为正式上线环境),那么 不将网站中的CSS JS重写到min/index.php 如果是测试环境(判断条件,域名HTTP_HOST中不存在.,或者192.168. 开头或者其他特例,存在.的特例),那么网站中的CSS/JS 的真实文件全部重写. 且限定重写的CSS JS 仅仅是/public /Public /css /js 文件夹中的CSS/JS!

spring boot使用profile来区分正式环境配置文件与测试环境配置文件

转载请在页首注明作者与出处 一:前言 经常在开发的时候,项目中的配置文件,在个人开发的时候有一套配置文件,在测试环境有一套配置文件,在正式环境有一套配置文件,这个时候如果配置文件复杂,需要改的东西就特别多,而且由于迭代过程中,需要经常切换,难免发生问题. 二:SpringBoot的解决方式 其实准备的说应该说是spring的解决方式,因为spring boot中的这些也都是基于spring中的功能,当然spring boot肯定是要简单的多的. 2.1:准备多份配置文件 先准备两个文件放在src

Chrome扩展修改页面代码执行环境的方法

Chrome的扩展程序可以通过content scripts向页面中注入js代码,所注入的js代码能够对页面中所有的DOM对象进行操作.由于Chrome在js执行环境上对页面代码和content scripts代码进行了隔离,所以,在content scripts中,无法直接修改页面代码执行环境.不过我们还是可以通过一些技巧向页面代码执行环境中插入想要执行的js代码段,从而能够修改页面代码的执行环境. 第一种方法,通过在DOM对象上添加一个event handler,然后派发对应的event给该

Linux系统添加、修改、删除PATH环境变量

一.   添加环境变量 (Bash shell中用export,C shell中用setenv) 1.直接在终端修改: export PATH=$PATH:software_installation_path/bin 改修改只对本次进程有效 2.修改用户级 在home/用户/.profile中添加: export PATH=$PATH:software_installation_path/bin 保存文件,重启即可(有的系统执行./.profile即可,不需重启:有的系统必须重启) 3.修改系统

Maven -- 在进行war打包时用正式环境的配置覆盖开发环境的配置

我们的配置文件一般都放在  src/main/resource 目录下. 假定我们的正式环境配置放在 src/main/online-resource 目录下. 那么打成war包时,我们希望用online-resource下的配置文件取代resource 下的配置文件. pom.xml 插件配置: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin

Maven实战之正式环境和测试环境配置分离

最近一直在研究前公司的架构,发现原公司的架构还是很不错的,对于生产环境以及测试环境这一点,虽然没有配置中心,但也是一定程度实现了正式环境以及测试环境的分离. 闲话不多说,现在直接上代码: 首先需要在pom文件中确定filter和要filter的资源,这是通过在build节点中添加filter和resource来实现的,示例如下: <build> <filters> <filter>${env}.properties</filter> </filters