How to deploy Yii advanced application on Openshift? - php

Can someone give me some general guidelines or point me to any source on how to deploy an advanced Yii template application v2 on OpenShift?
The problem is that I have not much experience with that platform and can not find specific documentation.
I can't access appdns/frontend or /backend (it gives me 404 error).

Given that non-use OpenShift but I use another platform that does not provide access to the shell so I can not make the normal installation Yii2 commands (composer and so on). I assume that you are my same condition. If you can be useful I depart from a copy of the entire application correctly configured on my local server and using ftp I transfer what is necessary. During the initial installation of course I transfer everything, then with a version control appropriately focused on my local copy I manage updates to be transferred to the server in the cloud. I hope this will be useful.

Related

Recommended way of migrating SilverStripe from dev to live

I'm rather new with the silverstripe framework but i have experience with magento which is also in PHP.
I have read several topics about deploying silverstripe. It seems that a lot of users preferred to download a fresh version of silverstripe install it on live server and then transfer the template and mysite folders and do the /dev/build
I guess this can work if you have access to the live server but what if you have a client who just wants his site on USB (mainly for security reasons)? What then?
So my question is this: what is the recommended way of migrating SilverStripe from dev to live server?
Will it work if you just copy paste all the files and the database?
As long as the live server meets SilverStripe's requirement it will work.
You'll need to ensure you update the database details if they change...
define('SS_DATABASE_SERVER', '');
define('SS_DATABASE_NAME','');
define('SS_DATABASE_USERNAME', '');
define('SS_DATABASE_PASSWORD', '');
...along with the environment type.
define('SS_ENVIRONMENT_TYPE', 'live');
Unlike other systems the IP or URL aren't baked into the database. Although It's advisable to do a /dev/build on the live server
The client should know what files on the server should be writeable by the webserver / php (namely assets/ and cache dir) and what not (all the rest imho).
I also recommend to setup all server specific configuration (see Phill's answer) in a file called _ss_environment.php (see docs) which can reside outside the webroot.
Then grab the database dump and setup the site on another server.

Where to deploy symfony2 application

I have developed a symfony application and it's done.
It's been a couple of days and I can't figure out how to deploy this into a real apache server, when I copy it to the public_html it doesn't work assets don't load properly.
Can some one give me a step by step description of how to deploy it so that when I navgiate to example.com url I see my symfony application.
Thank you
If you try to deploy your application on a server, you have to configure apache. The best way its to make a virtual host.
Here the documentation:
http://httpd.apache.org/docs/current/en/vhosts/examples.html
http://symfony.com/doc/current/cookbook/configuration/web_server_configuration.html
I would suggest using Capifony which provides a specialized set of tools on top of Capistrano, tailored specifically to symfony and Symfony2 projects. (according to the documentation)
The advantages of using capifony are,
deploying is as simple as running cap deploy from your project root directory.
It stores multiple releases.
It allows you to use SCM(s) to pull your application code down to the server.
You can configure it to run any batch command during the deployment.
It performs a transactional-like deployment process (if any step fails, the deployment is
rolled back and the current directory points to your last release)
You'll also need to troll through this part of the documentation to figure out how to get your application running under Apache.

GIT - Web Development workflow/deployment

I'm part of a team of 3 (2 developers and 1 designer) who sometimes work in the office and sometimes remotely and I'm looking at a way of using GIT to develop our websites seamlessly. I've got a managed account with Rackspace and have 3 servers setup on the account - development, staging and production.
I'm looking at the best way for our team to develop daily on our websites without having to FTP the files up to the server each time we make any changes. I've used SVN in the past but i'm looking to use Git for version control. The workflow I had in mind for an example website called 'test' was the following:
Development Server would have a directory (called trunk but not sure if it should be called something else?) for each user as well as a central directory. E.g /var/www/test/jbloggs/, /var/www/test/asmith/, /var/www/test/rjohnson/ and /var/www/test/central/trunk/.
The central repository would be installed within /var/www/test/central/trunk/ and then /asmith/, /rjohnson/ and /jbloggs/ would clone the trunk which would mean they would become /var/www/test/asmith/trunk, /var/www/test/rjohnson/trunk/ and /var/www/test/jbloggs/trunk/.
Each user would then have a copy of /trunk/ which will contain all the website files, will all have a subdomain configured i.e jbloggs.test.development, rjohnson.test.development etc and will configure their IDE to automatically SFTP to the server so that they are working directly within their directory the development server. The central directory domain will be test.development. When they come to committing any changes to the central repository they will SSH into the server and commit their changes and when we want to update the central repository we will pull these changes to get the latest version which can then be viewed at test.development.
Is this the right method of doing things or should we all have a local LAMP stack installed (apart from the designer who uses Windows) and have our repositories locally? If so, should the central repo still be on the rackspace server? The developers will be using phpstorm and the designer dreamweaver.
Hope the above makes sense.
Thanks
I strongly advise you to work local and then commit on the shared server. This is what git is made for. Development will be more reactive and easier for everybody. Make sure all dev master git so they can do their internal soup as they want. If one dev destroy the database, the others can keep on working. But you'll also need a convenient way to synch databases so developers work with an up to date local database.
The rest of your chain is ok, you can still have two test step like dev server for dev team and test server for testers. This will make testers working on a more stable version and it will also make you test the upgrade process when you copy changes from dev server to test server. Lot of errors arise because of untested upgrade procedures.
You can updates changes on test and production server either by installing GIT on them or just using a simple script that will ftp changed files. I don't like having git on a production server but this is a personal opinion.

How do I use GIT with my structure/environment?

I want to use GIT as version control for the PHP/MySQL web app I'm developing. I'm going with the server style setup since a couple of developers will also be working on it. I have the sandbox/dev server running (Ubuntu 10.10 server, LAMP package, CodeIgniter 2.01 framework) and its web root is /data/www/webapp.
How do I correctly set up GIT with my environment? Essentially how do I get GIT's "push to" or "I'm up to date and ready to test" directory the same as the web root (so I can just hit refresh in the browser and see the changes results)?
I'm still learning how GIT works so please excuse any incorrect use of terms. Also please no comments about other VCS systems - I'm sticking with GIT for sure.
Thanks in advance
One possible solution is to use a hook in your repo that will react to either new changes or a tag being updated that will export the new content into the appropriate location for your webserver.
The use of hooks makes things very flexible. There are hook points for quite a few actions in a repository and they can do just about anything (if you write it).

Source Control Advice

I've inherited a significantly sized internal app at the company I work for. It has two parts. One runs on a LAMP server, the other runs on a WAMP server. There is no source control to be seen.
Currently, developers will log into each server via FTP and just directly edit the PHP files that are there. Or log into phpMyAdmin and make changes to DB schema where necessary.
What is the best way to implement some source control into this situation? I'm not very knowledgeable on how to best setup CVS ans SVN. Would all developers need their own "test system"? Meaning, would I have to setup a LAMP+WAMP enviornment for each developer? Or can they would off a central dev server? What is the best way to deploy changes that have been made?
Developers all use Windows. We also use Zend Studio 5.5 for development.
Thank you in advance for any advice.
It's really not a lot of effort for a developer to have a personal LAMP/WAMP running locally or in a VM. A local dev server is worth having for testing non-live changes in a closely matched environment but it doesn't really scale if all developers are making their changes on that at once.
I'd have all developers committing to trunk in Subversion and then have a stable branch which is automatically (using a post-commit hook) deployed onto the server. Only certain people should have write access to the stable branch to ensure a junior developer doesn't accidentally screw the live server.
That's a horrible way to work on websites, especially with a team. The whole setup should be changed.
The source code should live somewhere else, and then get deployed to the website when it's ready. You could have a script that does the deployment and whatnot (copy the files over ssh, plus any other setup if needed, etc). The point is: no one should ever edit files directly on the production server.

Categories