I'm running my rails app on my laptop.
Now that things are up and running, I want to pass it all to a online server. How can I copy the app to the server, set it to Production mod and make everything work?
I have seen a lot of replies to pass an app from development to production mode on the same server but not to a different machine...
Can you point me to some online tutorial for tis? I haven't found any...
Thanks
A couple of things that you need to keep in mind whenever deploying to a production server:
I prefer to bundle my gems into the vendor directory bundle --deployment
Also, be sure to compile your assets rake assets:precompile.
You need to pick a web server (apache/nginx/etc) and and application server (phusion passenger).
You should check out http://railscasts.com/episodes/335-deploying-to-a-vps which covers some details on how you can deploy your website to a production machine. Also check out some of these videos http://railscasts.com/?tag_id=21.
Related
I have a php sqlite app I cannot make work locally offline .
I downloaded from https://www.sanskrit-lexicon.uni-koeln.de/
I installed MySQL myphpadmin apache2 and sqlite
I am not able to get the DB stuff to run because the app uses sqlite files.
I am not familiar with these tools and I want to run these locally as a user and then tell my friend who is less skilled to do the same. It is really for him. I have php MySQL myphpadmin and Apache running fine. I just need to have the DB work now.
How to do this?
I would prefer not to use xammp be because it is not standard repo stuff but if it really simplifies things you can include that.
We want to make it work offline (Ubuntu) because this monastery wants to be offline as much as possible. (It is a Sanskrit app)
Afternoon All,
Here is my context:
I am setting up an existing worklight project with App Envs for IPhone, Android, and Mobile Web.
When using the Worklight Console to preview the apps, I get context root errors from the iPhone app only. (I get the Error: The Server was unable to process the request from the appl...)
When I open the browsers JS console, I see the problem is that the app is requesting the wrong context root. It is accessing the /worklight/ context, which is not there.
The contextroot that does work is the following:
http://localhost:8080/apps/services/api/[APPNAME]/iphone/init
The Context root that the iphone is trying to hit:
http://localhost:8080/worklight/apps/services/api/[APPNAME]/iphone/init
Here is the weird part. The context root is fine for the Android, and Mobile Web environments. Only the iPhone environment is having context root issues.
All three environments are sharing the same application-descriptor.xml file and same server.
Below are some file outputs.
Files below:
/server/conf/worklight.properties
publicWorkLightHostname=localhost
publicWorkLightProtocol=http
publicWorkLightPort=8080
publicWorkLightContext=/worklight/
/apps/[APPNAME]/application-descriptor.xml
<worklightServerRootURL>http://localhost:8080</worklightServerRootURL>
So a couple of questions.
1) When setting the context roots, what is the relationship between the client and server. Do the context roots have to match between the two? Is one a master and the other simply slaves from that and does not need settings?
2) (Somewhat unrelated) While debugging this issue I have come across zero documentation about how to go about "un-deploying" the server in the Eclipse dev ide. (un-deploy the server is right from IBM's documentation) I need to know how to redeploy the server when I make changes to the server settings (worklight.properties). I have seen references to cracking open the war manually, to just stopping and starting the server in the IDE.
Any help is greatly appreciated.
If you are using a context root, it must exist in both worklight.properties and application-descriptor.xml. make sure both match, then re-build and deploy and see if the problem persists.
When using the development edition of Worklight, your server is based on Jetty which is run within Eclipse (it is bundled with the Worklight Studio plug-in you have installed in Eclipse). You do not need to "undeploy" anything. Simply make the changes to worklight.properties and application-descriptor.xml and re-build your application. The changes will make their way to both the server and client.
Do note, though, that using a context root is mainly for when using application servers such as Tomcat, Liberty or WAS.
I am running Mountain Lion, none RVM managed.
I have attempted:
middleman server -p 4567 -e development
middleman server
and
bundle exec middleman server
I've tried various combinations with templates, removed the install and started over several times.
Everything seems to run just find and middleman is standing watch, etc. I then navigate to http://localhost:4567/ (when applicable) and the browser always says that it cannot connect to the server "localhost"
the problem persists across two environments with dropbox sinking the source files between the two. Maybe I'm doing something wrong but I can't figure out any other steps from the docs and I've tried to connect to the official user forum but repeated "resends" of the confirmation e-mail don't work for two different accounts. Yah, it's been one of those development days...
Thanks for any help!
Ok, for some reason localhost is getting grabbed up on my computer. switching to 0.0.0.0:4500 solves it.
I'll be using RTC in the near future here at work. My question is: where does it put the files the team members will be working on? I understand that each programmer will work on the projects files and they will push the changes to the main repository. We have a local web server where we test our work (php). So, do we have to configure RTC to publish the files to the web server? or the RTC server must be installed in the webserver so it can save the files?
We use Rational Team Concert almost exactly as you describe, and it works brilliantly. My small team of web developers collaborates on website source code and delivers it to two different streams depending on its readiness: production-stream and staging-stream. Then we have defined two builds that check out the source code, move some things around, and push the files to the web servers via SCP. So, with a few clicks we kick off a staging build, watch it finish in about two minutes and everyone can see the changes on the staging server. When the code is ready for prime-time, the change sets are delivered to production-stream and the production build is kicked off, which is configured to copy the files to the production web server.
But even before a staging or production build is run, any of us can simply configure a local web server in RTC using the Eclipse PDE and Web Tools add-ons and see the site running in localhost as we develop.
All our work is done within Rational Team Concert, from planning, to bug tracking, to source control, to builds. It's very well-suited for website management.
Your understanding is correct - you work on files locally, and they get uploaded on to the server when you checkin. Bear in mind that checkin in RTC terms really means back-up your files to the server, it is a Deliver command that shares the files with others (it is worth a quick look at the articles on jazz.net that explains how SCM works).
One way to pubish to your php server is to make that part of a build, or a build in its own right (which RTC also handles - in conjunction with your favourite build tool). The build would copy the files to the php server. The advantage of doing this as a build is you will know exactly what versions of your files are being copied, and you will be able to reproduce this copy at any point in the future.
You do not need to install the RTC server on the php server.
You can also try posting on the forums on http://jazz.net/ if you have questions on RTC.
Hope that helps.
Another alternative would be to use the command line interface to accept all changes into a workspace and run that with a cron job.
To handle discarded change sets, you'd probably want to use something like:
scm workspace replace-components <workspace-name> stream <uuid-of-stream> --all
after you had initially loaded the workspace on your web server.
Typically I develop my websites on trunk, then merge changes to a testing branch where they are put on a 'beta' website, and then finally they are merged onto a live branch and put onto the live website.
With a Facebook application things are a bit tricky. As you can't view a Facebook application through a normal web browser (it has to go through the Facebook servers) you can't easily give each developer their own version of the website to work with and test.
I have not come across anything about the best way to develop and test a Facebook application while continuing to have a stable live website that users can use. My question is this, what is the best practice for organising the development and testing of a Facebook application?
Try updating your hosts file (for windows users # c:\windows\System32\Drivers\etc\hosts) with an entry that will route all requests from your live domain back to your machine.
So 127.0.0.1 mywebappthatusesfacebook.com.
Then make sure that your app is running at the root of your webserver. # http://localhost/ Then goto mywebappthatusesfacebook.com in your browser and it should redirect right back to your local machine. Facebook won't know the difference. Hope this helps
The way I and my partner did it was we each made our own private Facebook applications, that pointed to our IP address where we worked on it. Since we worked in the same place, we each picked a different port, and had our router forward that port to our local IP address. It was kinda slow to refresh a page, but it worked very nicely.
You'll have to add both trunk and test versions as different applications and test them using test accounts. You may also use a single application and switch its target URL between cycles.
Testing FB apps is still a rather primitive process.
I generally setup a test application that is a complete copy of the production settings inside the FB development environment that uses an SSH tunnel to point to my development server. You can setup as many applications as you need inside FB - I generally have a development application, a staging app and production. Staging and Production are both on "live" servers rather than an SSH tunnel.
In your application you then use whatever language/framework/server tools are at your disposal to switch the FB configuration based on the server. In Rails, the Facebooker gem actually has built in support for different FB configurations.
Once all of that is done, testing is, unfortunately, still a matter of running the app within FB itself. I use Selenium to automate as much of this as possible.
Best way to do this:
Remove 'App Domain' from 'Basic Info'
Set website's 'Site URL' to : "http://localhost/" .
That simple.
(This only apply if you don't have a live system running in parallel to the test env. In that case get yourself another key.)
We have it setup much like Toby. A series of config files for each developer, that has the Facebook APP Id info (a different app for each developer), separate pages where the app is hosted, and git ignores the config files. We're LAMP with Code Igniter, and it's similar to Rails in that we can set the environment in 1 file, which points to the config with the Facebook constants.
Branching out into Selenium, using unit tests for model-testing.
For local testing we simply use a different app than for the server. In our case the Canvas-URL is set to localhost.local:8000.
You only have to make sure that when you use facebook connect that you type in localhost.local into the address field of the browser and not just localhost.
For testing a canvas or tab app it is faster if you use the 'open iframe in new tab' command of Firefox. This way the session and cookies from Facebook are preserved.
Another solution is NGROK
https://ngrok.com/
It opens a public tunnel to your local app
Example on my rails application by simply typing
./ngrok 3000
I get
http://630066fe.ngrok.com -> 127.0.0.1:3000