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
Related
I have a website built on php and MySQL and trying to finally become more organised using git for making a distinction between code that is live and code that is still in test. I am the only developer working on the site
I cannot afford having a production and test server. So on the same server I made separate folders, one which is live /www/live/ and the other that is in development /www/dev/.
The development part of the site /www/dev/ is linked to a sub-domain dev.mydomain.com
Problem 1: I wish to setup git in such a way that my commits go to /www/dev/ and my pushes go live to /www/live. Is it reasonable to do it this way?
Problem 2: There are two places in the /www/dev code where links to the MySQL development database and folders are hard-coded. Commits would work fine, but then pushes would change the live code to now point to development databases and folders. Is there a neat way of managing this?
No - that's what git branches are for. Create a new branch called develop for all of your dev stuff and push commits to that which you would pull down from /www/dev. When ready to go live, merge the develop branch into master and pull master down on /www/live
Either git ignore the config files or better yet define the environment based on URL, directory path or an environment variable.
Recently we have started exploring GIT with the target of enabling our developers to work from any place and secondly to automate the overall deployment process.
We have a central test server where we host all apps/sites for testing and/or demo purpose and once the development and testing is finalized we move the application to their respective live servers.
Whatever i have set up with GIT, is as follows
1. Create a bare repo on test server
2. Get a local clone for each involved developer, Developers will push to remote(test server) dev branch
3. Someone will merger all changes from dev branch to master branch and push it to remote
4. The test server (bare repo) has a post-receive hook, which checks out the master branch to public_html folder (using GIT_WORKING_DIR and checkout -f).
As of now, everything works good and i am able to see merge on master branch on hosted pages (on test server, of course). Now my questions are ...
1. Am I doing this right?
2. I guess the post-receive hook I have set, executes on push to dev branch as well. How to avoid this?
3. How I can ship these contents to my live server? As I have some projects with large code base, checking out everything on test server and then ship it to live doesn't looks good enough.
I've heard of CI servers, but as much as I know they check out locally and upload everything to live using 'rsync' (don't know if it just syncs changes or uploads everything) or such tools. I just want to avoid that everything part and keep an option open to rollback, if anything goes wrong. I am good with setting up git on live servers.
Yes. You can see other considerations at "reset hard on git push".
You can test the name of the branch when receiving the commits.
branch=$(git rev-parse --symbolic --abbrev-ref $refname)
See also "Writing a git post-receive hook to deal with a specific branch"
a rsync is usually recommended for live server (where git isn't necessary): it will update only what has changed.
If you have git on live server, then various approaches are described in "Git for Websites / post-receive / Separation of Test and Production Sites"
Regarding deployment, as seen in "Deploy with rsync(or svn, git, cvs) and ignore inconsistent state during deployment?", deploying (even everything) in a separate directory and symlink the prod instance to that directory is a nice way of avoiding inconsistencies during deployment, and to facilitate rollback (symlink back to the previous live directory) in case of trouble.
I am using the downtime over Christmas to set up an affective development environment and workflow that will serve me well as my business increases. I maily do PHP development..
At the moment:
Local Development
I have NetBeans on my Windows PC. I have Apache, MySQL, PHP, etc. all installed for local development and testing purposes. I have integrated it all with NetBeans, and I have PHPUnit and Git integrated too. It seems to be working great and I now have my own local repository on my PC.
What I plan:
"Master" Repository
I want to have the same sort of development environment on my laptop, so I can work away from the office. My plan is the have a repository on my VPS for each project (at some point, I'll start deploying dedicated repository servers), that I can upload changes at the end of each work session. In the morning, I'll just download them changes into my local repository and upload any work done at the end of the day. This will serve as a sort of "official" project history, and when I work with other developers, they will work with this too.
Production Repository
I want a repository on my VPS, in the "live" area for my applications. I would like to be able to send out approved and tested changes from the "master" repository to this one when those changes are ready, rather than FTPing files.
Am I going the right way about this? Are there any guides to setting up this sort of thing?
Why do you need a production repository at all? For you to actually utilize it, it would have to not be a bare repository, and you cannot push to the checked-out branch of a repository anyway.
I think the better solution is to have a "production" or "stable" branch in your repository that contains whatever you want to be in production. Then you checkout that branch in your production environment. Whenever you want to deploy something to production, you merge it into that branch, push it to your repository, and then in the clone you have on your server, pull.
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 worked on several PHP projects and always I have problems with organizing my work. Where do you develop your application - on localhost, remote server or maybe production one(!) ?
When I work on my localhost after making some major path I send new files by ftp - but sometimes it happens to forget about one file and it is just tiring to browse several directiores to copy changed files.
What best practises do you propose?
This is how we manage our commercial site:
Develop in a local sand box
Check-in to SVN
Automated build/test from SVN onto internal
dev server
Scripted deploy using rsync to staging
server for QA/UAT
Scripted deploy onto production
servers.
Staging and production servers are both hosted by the ISP and are hardware and version matched and run RHEL, internal Dev server is version matched CentOS.
This way, when code hits the production servers there shouldn't be any nasty surprises as even the deploy scripts get checked in stage 4.
Google App Engine has an apposite tool that automatically uploads to the production environment files that are modified; don't know if there's something similar for PHP.
So, doing a dev2prod script (a script that does this automatically) should be a good solution.
To do local source file management, everyone may suggest you to use a source code control system.
I'm developing on a development machine which has an identical enviroment like the production one - that prevents some different behaviour because of different versions or configs. after finishing i just move all the files on to the production server.
Winmerge is a nice and free windows tool to diff your files between development and production machine.
Develop in your local machine with the same exact configuration as your development enviroment (that is apache mods, php extensions and so on), using a version control system (I prefer SVN) to keep track of modified files and what not.
Then you can write a script in your production or testing enviroment to copy/update files off the repository to the web server path.
Probably get told off for redirecting an old post but here's how I do it using free tools:
I use Netbeans, Git, bitbucket, source tree, gitflow and FTPloy.
Bitbucket.com : sign up for free account.
SourceTree: free from bitbucket. Great tool for managing git repositories. All commits, merges and pulls can be done in here. Issues in bitbucket can be tracked.
In sourcetree, take the master branch and click "git flow" - google gitflow - it's fantastic work flow of feature, hotfix, development, and release branches and sourcetree helps automate the process.
FTPloy.com automates the deployment of your master branch. Free is one repo/server. But worth the upgrade if you want to push development branch to a server sandbox for testing.
Hope this helps someone searching the web!
This is my own PHP Development lifecycle.
Create a GIT Private Repository on Github or Bitbucket.
Connect the GIT with cPanel. (It's very easy to commit the changes to the repo as well as a production server).
Develop on Localhost(probably on Xampp on Windows) with Visual Studio Code or Sublime Text
Initialise GIT and connected with the private repository.
Push the changes to the GIT repository (master/branches) - master changes will upload to the production server automatically.