I'm currently working on a symfony webapp, which is already on production. To develop and add/delete/modify functionnality of the model, I work on my laptop, using symfony 'dev' environnemment.
I test if everything work fine, then I pray a little and deploy it on the prod server (with all the risk of data error, like when I add new not null attributes on the model, prod server configuration special stuff, version of php/apache etc.).
The problem is that I would like to setup a "staging" server, which would be a copy of the production server (same database, same configuration apache/php), so that, if the deployment goes bad, the production user stay untouched and working, only the staging server is down. But my client has only 1 FTP available.
So, the question is : can I run 2 symfony project, with different models, on the same FTP ?
Or is there another way to do what I want to do ?
Thank you !
A staging server should really be exactly the same as production. Same versions, same directory structure, etc... a clone. However, you can still get most of the benefits by installing the site into a subdomain (staging.domain.com). Check to see if their host allows subdomains (%99.999 of them do) and install your application there.
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'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.
I have some questions about development and deployment. I'll try to be clear:
Notes:
1- I'm using Codeigniter for my project. I have in my database.php config file set up two environments: development and production with two different settings, of course.
2- I have two domains in the same server, one is for development (dev.domain.com) and the other one for production (domain.com)
3- The SVN repository is on the same server and it is under a subdomain too (svn.domain.com)
4- Locally, Im using MAMP server and I have a virtual Host for testing. Also, I'm using Netbeans and Git for managing the repo (git-svn commands)
5- I read the other similar posts, but I think my project have some differences to take into account
Questions:
I want to make changes locally and then, using Phing, deploy the changes to the development environment. This environment is just for testing purposes, I want to keep my production environment running, but if I add some new features, I want to test them in a real environment (server) before add them to the production environment.
1- What happens with the config files? If I deploy the development environment, the database config should change aswell. I can do this with Phing, but then I'll have changes on my working tree and I'll need to commit it first and change them again when working locally.
2- Should I work with branches for every release to production? I can do a git svn rebase on the development environment, but what happens with the production one?
I have kind of mess on my head about all of this. Can you clear my mind a little bit, please?
Thanks in advance.
Just use 2 separate branches for DEV and PROD (or trunk+branch) with different configs and different deploy targets for Phing (per "branches")
Merge tested changes from DEV to PROD after debug, tag merged (and working) revisions in PROD tree without additional branching
PS - using both Git and SVN seems as excess solution for me
I'm struggling with the best approach to test php development code which is dependent on certain framework files to be present. I think there are three possible scenario's with git:
Create a copy of the live production directory and clone this 'dev' directory to the local workstation. The next step would be to edit code on the local workstation and commit/push every change. You can check your work via the 'dev' url on the production server. If everything is alright you can push the changes to the 'live' directory. This approach may result in a lot of commits as you are editing/fixing your code (syntax errors or other obvious mistakes) and it adds an extra step (commit/push) to see your result.
Create a 'dev' server which mirrors the production server. This server will contain all the framework files and you'll be able to edit a copy of the 'live' directory directly and immediately see your changes. If you prefer you can mount the remote 'dev' directory to your local workstation. This requires an extra server which needs to be maintained and you would need the resources to set it up.
Create a local 'dev' workstation environment and clone the repository on the 'live' or 'dev' server. This way you'll be able to test all the code on your local machine and only push out the commits which have been tested and approved. This reduces the number of commits as opposed to method one. To recreate the 'dev' environment locally you might have to install a lot framework/dependent files to your local workstation and even then it might not be 100% reliable when the code is ported to the actual live server.
Basically I want to find the best method for the 'write-test-revise-test-revise-test-commit'
cycle if you are dependent on framework files (whatever framework that may be). Would you create a 'dev' server or would you recreate the exact production environment on your local workstation? Ideally you would only commit the code when you have done some initial testing (obvious syntax errors etc.). A 'dev' server with local git repo would require that you commit every little change to test your work which may be tedious....
I hope I have made myself clear. I'm looking for the best way to integrate git and the 'write-test-commit' cycle. Normally you would test on the local machine but with web development you may need a webserver + framework to be able to test your code. Editing directly on the 'live' server is what I want to avoid.
Thanks for your input!
There are definitely many ways to do this, but here is my 2 cents from how I have been working lately.
First off, I would probably avoid a dev server per se, because if you have more than 1 developer, each developer may try to update the dev server with conflicting code, or if they are working on similar areas, overwrite some of your test code since you both probably are working from the same branch but have both modified the code and not yet pushed the changes.
That said, you may want a dev server that closely resembles your live server so that after you and some of your other developers have made a number of changes, you can test them on the dev server before updating the code on the live server.
In my environment, I develop on Linux and have Apache/PHP running the same versions and configs as the live server. This way, I clone my git repo, have my environment set up so that my document root is the "public" directory of my git repo (e.g. htdocs). In this case, we have a dev MySQL server which is usually shared, and not on the local machine, but you can do whatever is easiest there. Our system depends on constantly updated data from the field so this is why the shared database, we have a system which adds a lot of this necessary "test" data automatically to the database.
This way, I can pull the latest code from git, work on it all I want, work-break-fix-work-work-work etc etc and when I have completed my task, I can push the changes back to git for other developers.
When you are ready for a release, you can do all of your testing and stuff on the dev server, verify it is good to go and then push to the live.
In my case for updating the "live" server, one person is responsible for that, and I use rsync to sync my local working directory to the live server. So when I am absolutely sure we are ready to deploy, I pull the most recent code from git, and run my script which rsyncs my git directory to the server.
I'd avoid your methods 1 & 2, and go with something like 3. That will probably be the sanest thing for you to do and easiest to manage. Depending on what your team is like, you could create a dev VM that is pre-built with all the dependencies, correct software, and development tools you are all using, or leave it up to the developer to set themselves up.
So far this method has worked pretty well for me and the others on my team.
Call me opinionated, but every developer should have a local development AMP stack which they can develop against. If you don't know how to set up an exact mirror of your production server, solve that problem first.
Once you're there, it should be trivial to have each developer set up a virtual machine with a clean OS install, configure web/php/db servers and libraries/framewroks to match the production environment, check out your project, and get to work.
Developers commit against personal branches in their own local repos as they go, and after local testing, ship their code (via either a push, or a pull request, or whatever).
The exact rules about how to merge changes into master depend on your team an preferences. But developers should almost always have a complete local dev environment. If it seems like it's hard to set one up, that's a big problem. Figure out how to make it easy and then document it.
I've read a number of topics in the same sort of ballpark as this one, but in all honesty I'm still not exactly sure on the best approach (as a starting point). I am a solo developer in a small office and I have around 30 websites which are hosted on a linux VPS. I want to start using using version control (probably SVN) and also set up a staging server. At the moment, I do development either locally on my machine before using FTP to upload to the live server, or ocassionally for small changes I edit the remote files directly, which is not an ideal approach.
I'm looking for some guidance on how to improve my development environment. I imagine I should be installing SVN on the web server, which would then allow me to check out versions to my local machine (which would also require SVN i think). Also, if I want to set up a staging server, should I just set up subdomains for each of the live websites, then use these subdomains for showing clients changes to the site before making them live?
Hope this makes sense!
This is what we do at work:
We have a staging server running Apache and a Subversion server. We have a post commit hook that updates a working copy in the htdocs directory, that way, when a developer commits something it automatically gets updated on the staging server, so everyone can see the latest code.
On the client's production servers (the ones we can control) we have the Subversion client installed and the website is a working copy. When we need to update the live site we login to a shell and run svn up. If you do something like this, make sure to limit access to the .svn directories, either with .htaccess files or from the main Apache config.
We have a custom app that manages the projects, but that is only because we're lazy and don't want to setup each project by hand, the app creates the necessary directories and working copies. You could write a quick script to do this.
We never, ever, edit files via FTP on the live site. All in all we have been using this setup for almost 2 years and aside from the occasional conflict on the staging server, we never have had any problems.
You can actually install the SVN server on your local machine, which I would recommend in lieu of installing it on the web server (assuming you make backups). The easiest thing to do, since it’s only you using it, would be to use the file:// protocol, but using svnserve is a little more robust, and the preferred method if you want to take the time to do it.
#Michael, I disagree - I would say it's better to install on the linux vps, especially if you are already paying for the hosting service. I find it very helpful to be able to browse and download stuff from my svn repo wherever I am, from whatever computer I'm on.
#nicky, I started with svn (and version control) several years ago and I took baby steps which made it easier to tackle.
If I had to do it over again, I'd read the svn book to start with. The book is very well laid out and didn't take more than 1-2 days to plow thru.
While you're reading, install svn on your linux vps with an apache front end.
Once you have that up, pick one of your websites and import it into svn. This is how I structure my svn repo. For example, say my repo is hosted at http://mysvn.mydomain.com/svn/:
mywebsite1
- trunk
- tags
- branches
mywebsite2
- trunk
- tags
- branches
Don't worry about creating the perfect structure. It's pretty easy to re-organize especially when you're starting out. After you import a few projects into svn, you'll start to get a feel for which projects should have their own "trunk/tags/branches" dir structure and which can be combined.
For creating test environments, I do exactly what you describe. I use build scripts to checkout from svn and download files into dirs that are mapped to subdomains like "test.clientsite.com" (I work primarily in java and use ant and maven, but I think you can use whatever scripting language you're familiar with).
Once you get used to version control, you'll never go back, good luck!