Typically, I am used to a: local, local-test, dev(dev.site.com), and prod(site.com).
With rails local being 'development' it messes up all of my lingo of what's what. What do you guys typically call each environment in rails and what are each one's responsibilities?
I am aware that I can change development to be local and will probably do that in the near future, as the rails default.
Default environments include development, test, and production.
Development: Typically used on your local machine, where you do all of your coding. Contains more verbose error messages than production, doesn't compress or precompile assets, and doesn't cache classes or controllers (so you can reload your browser and see changes immediately)
Test: A special environment for running tests in without affecting your development database (db is wiped clean between tests).
Production: Final destination. Used for your production/deployment server, where you want maximum performance and minimum verbosity. Debug information is hidden from the user, assets are compressed and precompiled, and caching is enabled -- because code isn't expected to change much between executions.
As Dave mentioned, some people add a staging environment as a sort of middle ground between development and production, to test their app on their remote server. It's often just a matter of copying config/environments/production.rb to config/environments/staging.rb and adding an entry to database.yml so your staging changes don't affect the production database.
Related
I have a CakePHP 2.3 app with a MySQL database.
I'm building a new app (in a different language and framework).
The plan is to completely replace the CakePHP app with the new one. The code is almost ready, so I've just attempted to run it in production for the first time.
User login seems to have crashed in production because the field hash in the users table was changed to old_hash. I did this because the new framework can't have fields with the name hash.
Testing in development, this was not a problem at all.
In production it became a problem.
Development:
App in Vagrant VM and database in my machine's local MySQL
(MySQL 5.7)
Production:
App in AWS EC2 and database in AWS RDS
(MySQL 5.6)
Because all users have the hash column blank, I assumed it didn't matter.
The fact that it worked locally after changing it to old_hash led me to worry even less about it.
I've searched for documentation on this specifically, but did not find anything detailed enough.
What does CakePHP use the hash field/column in the users table for?
Is there a place in the code where I can explicitly tell it to look for something named old_hash instead?
What could be influencing the difference in behaviors between development and production?
Figuring all of this out would be awesome, because then my 2 apps would be able to briefly coexist in production, making the transition smoother.
Currently I am using ms-deploy to build and deploy on several machines using team-city. In my current scenario, I need to build, package and deploy on Dev. After this I need to deploy this package on test and Live servers (which are on different domain. I understand how we do it but problem is Web transformation only occurs for test and live configs if we build a package. It means if I want to use the same package that is created for Dev cannot be used, as web transformation only occurred for Dev web config. Also know that we can change web config when un-packaging but that parameters are very limited. We have a lot of changes not just the connection string or db changes.
Another solution is to add another step to build packages for test and live as part of Dev deployment but then it means a lot of copying on remote servers, once for test and once for live which is a lot of time consuming due to different domains.
Can you please guide what is the best solution in this scenario. So I can use team-city to publish to Dev and test and live using same package and different web configs in one go.
To configure items at deployment time which are not automatically created for you. You can add a file named parameters.xml to your project and extend what you want to make available at deployment time.
Here's some documentation on the approach Using Deployment Parameters for Web.Config File Settings.
I have two Rails 3 applications that will share portions of the same database through an internally developed gem. This is an internal project where we will always have full control over both applications. One application is bare metal administration (dev facing, potentially unstable) and another is the content publishing system (user facing, production). Its not practical nor desirable to meld the applications.
I've already seen Rails - Shared Database Tables between two apps
My proposed solution is to git submodule and share the /db directory of both applications.
I want to know if this is a valid approach, and if so are there any pitfalls I'm setting myself up for? If this isn't valid what is a good alternative? (The goal here is to remain as simple as possible, no interprocess APIs.)
I have used this approach and it does work. If you are using capistrano for deployment enable submodule deployment like this
set :git_enable_submodules, 1
You have to be careful not to forget to sync the /db folder, before you start creating migrations, they are created with a timestamp and you can end up with the wrong sequence of migrations.
I have a wordpress mu-site. I need to set up a test-version of it so that the client can run test on the changes we make, test the plugins with new updates etc.
Anybody who has worked with wordpress know it's a bit off a hassle to move between servers and/or domain-names, due to the absolute paths used. Does anybody have a good solution how to create a stage-enviorment of wordpress?
Here's how I do it + some adjustments I want to make:
Two WP installs on identical environments - dev & production
They each have their own FQDN
Version control (SVN in this case) to handle merges from dev to production
When merging, I don't ever merge database changes. I only merge code, and modify any of the domain specific things during the merge (which really should only be in the DB.)
Recreate any DB changes needed during deployment
There are other ways to do it, but they often require changing the hosts file or access to internal systems. So if you want to be able to show an external client a site, then those methods aren't likely to work.
I also sometimes copy the DB back from production to dev, and just do a find & replace for the FQDN.
You can also dev locally and use the above listed method for staging only.
I want to set up a production and development environment for a wordpress website. The Wordpress site uses a lot of plugins. These plugins consist of php files which I upload to a directory within the main wordpress directory.
When activating and modifying the plugins, much of the configurations are stored in the mysql database. Developing on wordpress means much of my "code" and "changes" are stored in the database, as opposed to physical files that can be committed to and updated from a CVS repository. So instead of having a CVS keep track of my changes, I have to frequently and manually do mysqldumps of the database on production and import it into the development server.
Is there a better way to set up a development and production environment where much of the development changes are happening in the database?
Use CVS's hooks to perform the dump whenever you commit. I'm not familiar with how CVS does them, since I've only done it with SVN. However, from reading a bit of the manual, it seems pretty similar.
This section of the CVS manual explains what happens, script-wise, when you commit. Take a look at the section further down, "C.4.4.2 Keeping a checked out copy". You should be able to modify this example to put in your mysqldump command.