We have many php applications working on old php version 5.
Now am working on to update the codebase from php 5 to php 8. To update codebase am using packages like phpcompatibility/php-compatibility, phpcsstandards/phpcsutils etc.
After each application codebase update (to php 8) I will generate compatibility report (using phpcompatibility) to validate the update.
But I want to be sure (that codebase will work on php 8) and not only depend on report (phpcompatibility).
Hence, I decided to deploy applications on local servers (on php8, to check). But each application is giving me headaches. Each application ask for specific requirements (databases, users, files, classes). The php applciations were developed by other teams who have moved on (I dont have the environment in which they were developed).
Is there any quick way to do it? Am thinking may be I can -
1.go to production server
2.create docker Image
3. Open docker image locally and update php version(php 8)
4. Deploy php application in this local docker image (php applciation codebase is now 8)
5. If everything looks ok then update the production server version to php 8.
Am not sure will this work, is there any better way?
Related
I want to move my application from custom framework to laravel and I try to figure out how I'll provide tests on Laravel in future.
At the moment I test like this:
I have my app in 2 folders main and test
main folder for appexample.com domain
test folder for test.appexample.com domain
So when I want to do some changes, firstly I make it in test folder and check if everything works fine, then I copy with replace test folder to main folder
If I would want to use laravel, how should I do those tests correctly with laravel?
Thanks
So, what you have is not a test environment but a staging environment...
What you would have to have is 2 Laravel apps:
Production (appexample.com) should be using a production GIT tag (for example, v1.5.3) or at least use a production branch like master or main
Staging (test.exampleapp.com) should be using a development branch like develop or whatever your team defined as it
You can have a look at Laravel Forge and Laravel Envoyer.
Forge: Allows you to manage servers, environments, deployments, PHP versions, databases (I do not recommend to have a database on the Laravel app server), and more stuff
Those servers can be on AWS, Digital Ocean, and more
Envoyer: Allows you to manage deployments, environments, and more
The take away from Envoyer is that it will help you deploy easier to multiple servers (let's say you have a load balancer and 4 servers behind it, it will automatically deploy the same code and run deployment steps on each server, and if any fails, it just goes back without the client knowing anything happened)
This means you SHOULD (I would say MUST) have separate databases, one for staging and one for production (YOU NEVER RUN PHPUNIT TEST ON ANY ENVIRONMENT EXCEPT LOCAL OR DEVELOPMENT).
Also, you should "replicate" your data on staging, so staging is as similar as possible related to prouction:
Same database version
Same web server engine
Same PHP version
Etc.
If you are going to upgrade any, it is fine if staging has a newer database, web server, PHP, etc. version than production, that is the idea, test stuff there before release.
I have created a react-laravel project using laravel-mix. Right now I am run project using
npm run watch
php artisan serve
So by this, I access project by : http://localhost:8000
I have also worked in laravel. In laravel, if we want to access project without php artisan serve then we can access using : http://localhost/project_name/public.
Now my question is, how can I access/execute react-laravel project without php artisan serve? Is there any kind of way to access/execute project without port? Because I want to set up react-laravel on live server and I don't want to continue open terminal on server after code uploading.
I will really appreciate your feedbacks.
There are a multitude of ways to set up a laravel project. and it has nothing to do with the frontend suite you use whether its React or Vue, I will give you 2 options here to run a laravel application.
1. vagrant/homestead
Laravel Homestead is an official, pre-packaged Vagrant box that provides you a wonderful development environment without requiring you to install PHP, a web server, and any other server software on your local machine. No more worrying about messing up your operating system! Vagrant boxes are completely disposable. If something goes wrong, you can destroy and re-create the box in minutes!
Doc Link
2. XAMPP/WAMP/ or any LAMP stack
XAMPP is a completely free, easy to install Apache distribution containing MariaDB, PHP, and Perl. The XAMPP open source package has been set up to be incredibly easy to install and to use.
Link
Personally I prefer Laravel Homestead since it contains everything out of the box for laravel Development. like PHP, Nginx, MariaDB, Node, etc...
I have developed a Symfony2 app on my local machine. I access it using PHP's built-in server, via http://localhost:8000/
Question: how do I move this application to my VPS (LAMP CentOS) so that it can be accessed like this:
http://example.com
and is it any different for installing it on:
http://subdomain.example.com
PLEASE if by any chance you can provide a step by step instructions, it will be much appreciated and I'm sure useful to many others too. I'm used to working with stuff where you can simply move files from one place to another, update some config data and it works (Wordpress, coding without frameworks etc.)
The best solution to me is to have your project in a versionning system like git or svn without the vendors dir of course ...
This way, your simply have to do :
1) git clone your project into the prod dir
2) php composer.phar install to install your vendors
2b) create the mysql user with correct login and password according to your parameters.yml
3) php app/console doctrine:database:create to create your database with the credentials you set up in mysql
4) php app/console doctrine:schema:update --force to perform the database tables creation
5) testing the project :)
If you are not using a versionning system just upload your project to your server with an ftp software without the vendors directory ( it will be feeded by step 2) then perform 3rd , 4th and 5th steps !
For the subdomain part of your request you have to creats a subdomain folder on your server ( by using plesk if you have it ) or by manually creating a vhost config to specify the sub domain path. I can t provide you an example right now ( i m writing this from my mobile device and i don t have clear step by step procedure in order to achieve this )
[Install your environment]
So, First you need to install and run an apache Server. Find here the minimum basics to get your application running under Apache2. Then make sure you've PHP5 and MySQL up and running. Otherwise check,
Install and Configure MySQL Database Server
Installing and Configuring PHP
[Deploy your application]
Deploying can be a complex and varied task depending on your setup and
needs - Symfony.com
It's then up to you to choose the right way to deploy your application, you can do it,
Using Basic File Transfer
Using Source Control
Using Build scripts
I would recommend using Capifony which was build on top of Capistrano to adapt it to Symfony applications.
[Post-Deployment Tasks]
Your deployment process should be tailored to guarantee that all the required post-deployment tasks (Like updating your dependencies, setting your application configuration files, clearing the cache and dumping your assets, etc) are executed.
To get the big picture, read the How to deploy a Symfony2 application of the Cookbook.
I am in the midst of setting up the development environment (PHP/MySQL) for my start-up. We use three sets of servers:
LIVE - the servers which provide the actual application
TEST - providing a testing version before it is actually released
DEV - the development servers
The development servers run SVN with each developer checking out their local copy. At the end of each day completed fixes are checked in and then we use Hudson to automate our build process and then transfer it over to TEST. We then check the application still functions correctly using a tester and then if everything is fine move it to LIVE. I am happy with this process but I do have two questions:
How would you recommend we do local testing - as each developer adds new pages or changes functionality I want them to be able to test what they are doing. Would you just setup local Apache and a local database and have them test locally on their own machine?
How would you recommend dealing with data layer changes?
Is there anything else you would recommend doing to really make our development process as easy and efficient as possible?
Thanks in advance
+1 to each developer running her own setup, complete with Apache and database.
Keep the database schema under version control.
Possibly you could keep (maybe in a separate repository) a small but representative set of data, in a test database. Each morning you check out the latest copy of this test database, and start hacking. When you change schemas, update your test data repository accordingly.
Anyone doing development SHOULD have their own local environment. I use Mac so I run MAMP so that I can have my own LAMP environment local and independent of any other environment. This will also allow me to know that nobody else is changing / working on the same components I am and removes any possible confusion. If you are a windows user, there are also easy to install local versions of the LAMP stack such as XAMP, etc. If you are running Linux as your desktop, you will most likely already know how to install LAMP for the flavor of Linux you are running.
The database schema version is a great idea. It is what we use as well. In addition to the schema under version control, we add a schema version table to the schema and keep it updated so we can quickly tell what version is in production/qa/dev when we need to compare.
As for the data layer changes there are two things I would recommend.
Always create your migration path, forward and backward. This means that when you have the schema you want to put on production to upgrade an existing schema, you should always make it part of the release. A clear concise process for ALTERing the tables. By the same token, you need to have a working and tested ROLLBACK version as well in case something goes wrong.
What I have found helpful is using a backup of production to load on my local (or QA/DEV) so that I have the most up-to-date data / schema to play with without affecting production. If you are not performing regular backups of production, maybe now is a good time to implement a policy. Then you will kill two birds with one stone. You will have backups for any outage and a useful live schema with data you can load to test with on another machine. This will also lend itself to raising any possible issues with schema changes as the data will be matching production. So if it works locally (and on DEV/QA), it reduces the risk of something going wrong in production.
There's another post on SO relating to .NET -- not us. Pure PHP. Trying to find the best way/process to deploy stable version of our PHP app. I've seen an article on Capistrano, but am curious what else is out there. Aside from the obvious reasons, I'm also looking to add some scripting so that the SVN rev number gets added in there as well.
Much thanks.
I've used a home-grown script for quite some time. It will (based on an application configuration file):
Run svn export on the repository based on a tag.
Package the export into a tar or zip file, which includes the tag in the name.
Use scp to copy the package to the appropriate server (QA or release).
Connect to the server with ssh to install the package and run post-install scripts.
The application configuration file is part of the project. It can tell the script (at step 2) to strip paths and otherwise process specified files. It also specifies server names and how to handle externals.
I've recently migrated the script to support Git as well as Subversion. I'm also probably going to migrate it to PHP since we're now running in a mixed (Linux and Windows) set up, with Linux now in the minority.
I have plans to automatically call the script with post-commit hooks, but haven't had the need to implement that just yet.
Coincidentally, I was just reading about an Apache Ant/gnu make like build tool called Phing. What I like about it is the ability to write custom extensions in PHP!
I don't know if it works for deploying an app live, but phpUnderControl is a continuous integration suite (which I'm just now starting to look into). If it doesn't support doing deployments natively, it can probably be extended to do them.
Chris Hartjes has a nice view on this: Deployment is not a 4 letter word
We're using Webistrano, which is a web frontend for Capistrano, to deploy a few dozen projects. It's built as a Ruby on Rails app, and provides a nice, centralized and consistent user interface for Capistrano deployments.
Instead of having cap recipes in every project, and running command-line tools, Webistrano stores the recipes in its database, and allows you to attach the recipes to multiple projects and stages. This reduces duplication of scripts.
Also nice is that all deployment logs are stored so there's an auditing trail. Who deployed which revision to the live server, that sort of thing.
As you requested, the Revision number is stored in the deployed project as well.
All in all, we're very pleased with it.