Hi guys I have a PHP project and I need a tool for make deployment and I foud Deployer, a deployment tool for PHP, which is your opinion and experience about it?
Regards
Deployer is good choose: it's has simple api, a lot of recipes for popular frameworks and apps, and can run parallel deploy. Also it requires only for PHP.
deployer.org
github.com/deployphp/deployer
Here is an example of little task:
task('my_task', function () {
// Your tasks code...
});
Deployer has a good quality code:
I use deployer. It works as advertised, or better. That is my experience and opinion, to answer your question. Let me give some more information:
You get parallel deployment on remote servers and going forward/back is very simple. Your release and rollback procedures become documented in code and repeatable by anyone on your team with permissions.
Your directory structure looks like this:
./releases/yyyymmddhhmmss/
./current -> ./releases/currentrelease/
./shared/
The releases folder contains each release that has been made. You should tag these on git yourself too because deployer will clean them up for you when they get old (you configure that.) current is a symlink that points at a current, ready to go, release. You can move it forward and back to release and roll-back. Deployer manages it all for you.
You setup and configure deployer by creating your Deployerfile (deploy.php) in your project root. Use composer to install deployer.
Then to deploy on all staging servers simply run:
vendor/bin/dep deploy stage
And when happy you can send to all production servers in parallel with:
vendor/bin/dep deploy production
The only really "difficult" task was figuring out how to integrate with our database migrations, deployer gives you many tools but migrations are of course left up to your database layer. I would also love to see some more resources from deployer about suggestions for permissions and thoughts on using a deploy user on the remote hosts.
It will be worth your time to automate your release and rollback procedures so that anyone on your team can handle them. Deployer is a great tool set for doing that.
I'm planning to do an automated deployment of a website,but im kind of stuck at this moment. I have looked at MS-Deploy, it got all the functions for deploying Website. I have a created a Web application package (.ZIP file) and I tested this on my local machine it is deploying website i.e
Create Web application under default website
Publishing files in c:\inetpub\wwwroot directory
Set ACLs on directories,etc
But i want to achieve few more extra steps for example:
Check whether Web application exists in Default Website, if not
create a Web application
Check whether Application pool exists, if not create a App pool
(given name) with a specific credentials and Assign App-pool to Web
application
Before it deploys take a backup copy of existing Web application (IF
exists)
publish offline page (app_offline.htm)
publishing the files to application directory
Replace the AppSettings section(in web.config file) to with actual values
Encrypt Web.config connection string
If there is any error whilst installing web application, rollback the web application to its previous version
The question is whether can i achieve all these functions via MS-Deploy or do i need to write any script, please suggest me what scripting language should i use
Please let me know if you need more information.
Thanks in advance
I'm not an expert on this topic but have been doing a bit of research on automated deployment with MSDeploy lately, and think I can offer the following;
This is default behaviour if you use the iisApp provider.
I know you can do this with the appPoolConfig provider, but I'm unsure as to how you would run this and #1 together as part of the same package. Perhaps as part of a pre- or post-sync command?
This is standard in v3, as long as it's set up on the server. Not used it myself, but read this anyway.
Fiddly. Not supported in MSDeploy, but you can vote for it if you want. Also, check out this SO answer (and also worth checking out PackageWeb, but the same answers' author).
Not sure I follow. This is done as part of a successful deployment, surely?
Use web.config transforms and optionally the aforementioned PackageWeb for a neat way to do this. Also check out Web Publish Profiles.
Difficult. My understanding is that the encryption is based on the machine.config, so you'd either have to run a post-sync script which would run some sort of remote Powershell script on the remote server to encrypt the web.config using aspnet_regiis, or you'd have to encrypt the config as part of your build process and then muck about with custom keys and the RSA provider (some info here).
I hope that helps. As I said, I'm no expert, so happy to be corrected by those more knowledgeable. Maybe also worth mentioning that MSDeploy is a lot more powerful if you use it via the command-line rather than creating packages from VS, although there is a bit of a learning curve to go with it.
I have some questions around the best mechanism to deploy MVC web applications to different environments. Previously I used setup projects (.msi's) but as these have been discontinued in VS2012 I am looking to move to an alternative.
Let me explain my current setup. I currently have a CI setup using TFSBuild 2010 with Team Foundation Server for source control.
A number of developers work on their local machines and check in to the TFS Server. We regularly deploy to a single server dev environment and a load balanced qa environment with 2 servers. Our current process includes installing an msi which carries out some of the following custom actions:
brings current app offline with the app_offline.htm file
run in database scripts (from database project in the solution)
modifies web.config (different for each web server of qa)
labels the code
warmup each deployed file via http request
etc
This is the current process. Now I would like to make some changes. Firstly, I need alternative to msi's. From som research I believe that web deploy via IIS and using MsDeploy is the best alternative. I can use web config transforms for web config modifications. Is this correct and if so, could I get an outline of what I need to do?
Secondly I want to set up continuous delivery via TFSBuild, I have no idea how this may be achieved, would it be possible to get an outline of how it can be integrated in to my current setup? Rather than check in driven, I would like it to be user driven following check in. Also, would it be possible for this to also run in database scripts from a database project in the solution.
Finally, there is also a production environment, but I would like to manually deploy this - can my process also produce an artifact that I can manually install?
Vishal Joshi has some information on his blog that is reasonably good, http://vishaljoshi.blogspot.com/2010/11/team-build-web-deployment-web-deploy-vs.html. It does have the downside that your deployment password is include in the properties you pass to msbuild.
Syed Hashimi has also posted some information on this in another questions Team Build: Publish locally using MSDeploy.
I'm using Fedora and I deploy Symfony projects in my local machine using virtual hosts. How can I deploy my projects in server to public which others can view it through their machines?
Thanx...
You have several way to deploy you symfony project. I will avoid ftp, svn up on prod, etc .. So, here is 2 good ways.
The built-in deploy task
Symfony comes with a built-in depoy task that has been used when symfony 1.4 was released. I think it's less and less used now (because there is better tool).
The simplest way to deploy your website is to use the built-in project:deploy task. It uses SSH and rsync to connect and transfer the files from one computer to another one.
Using capifony, which use Capistrano
Capistrano is an open source tool for running scripts on multiple servers. It’s primary use is for easily deploying applications.
capifony is a deployment recipes collection that works with both symfony and Symfony2 applications.
This way is far better than the previous one because you can automate many script when deploying (like testing your code, start a fresh built lib, upgrade database, share config file). But the most important one (from my POV) is that you can easily rollback a bad deployement. It's damm easy.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I am working on my first Drupal project on XAMPP in my MacBook. It's a prototype and receives positive feedback from my client.
I am going to deploy the project on a Linux VPS two weeks later. Is there a better way than 're-do'ing everything on the server from scratch?
install Drupal
download modules (CCK, Views, Date, Calendar)
create the Contents
...
Thanks
A couple of tips:
Use source control, NOT FTP/etc., for the files. It doesn't matter what you use; we tend to spin up an Unfuddle.com subversion account for each client so they have a place to log bugs as well, but the critical first step is getting the full source tree of your site into version control. When changes are made on the testing server or staging server, you see if they work, you commit, then you update on the live server. Rollbacks and deployment gets a lot, lot simpler. For clusters of multiple webheads you can repeat the process, or rsync from a single 'canonical' server.
If you use SVN, though, you can also use CVS checkouts of Drupal and other modules/themes and the SVN/CVS metadata will be able to live beside each other happily.
For bulky folders like the files directory, use a symlink in the 'proper' location to point to a server-side directory outside of the webroot. That lets your source control repo include all the code and a symlink, instead of all the code and all the files users have uploaded.
Databases are trickier; cleaning up the dev/staging DB and pushing it to live is easiest for the initial rollout but there are a few wrinkles when doing incremental DB updates if users on the live site are also generating content.
I did a presentation on Drupal deployment best practices last year. Feel free to check the slides out.
Features.module is an extremely powerful tool for managing Drupal configuration changes.
Content Types, CCK settings, Views, Drupal Variables, Contexts, Imagecache presets, Menus, Taxonomies, and Permissions can all be rolled into a feature, which can be checked into version control. From there, deploying a new site, or pushing changes to an existing one, is easily managed with the Features UI or Drush.
Make sure you install Strongarm.module for exporting drupal config that gets stored in your Variables table. You can also static content/nodes (ie: about us, faqs, etc) into Features by installing uuid_features.module.
Hands down, this is the best way to work with other developers on the same site, and to move your site from Development to Testing to Staging and Production.
We've had an extensive discussion on this at my workplace, and the way we finally settled on was pushing code updates (including modules and themes) from development to staging to production. We're using Subversion for this, and it's working well so far.
What's particularly important is that you automate a process for pushing the database back from production, so that your developers can keep their copies of the database as close to production as possible. In a mission-critical environment, you want to be absolutely certain a module update isn't going to hose your database. The process we use is as follows:
Install a module on the development server.
Take note of whatever changes and updates were necessary. If there are any hitches, revert and do again until you have a solid, error-free process.
Test your changes! Repeat your testing process as a normal, logged-in user, and again as an anonymous user.
If the update process involved anything other than running update.php, then write a script to do it.
Copy the production database to your staging server, and perform the same steps immediately. If it fails, diagnose the failure and return to step 1. Otherwise, continue.
Test your changes!
BACK UP YOUR PRODUCTION DATABASE and TAKE NOTE OF THE REVISION YOU HAVE CHECKED OUT FROM SVN.
Put your production Drupal in maintenance mode, run "svn update" on your production tree, and go through your update process.
Take Drupal out of maintenance mode and test everything (as admin, regular user, and anonymous)
And that's it. One thing you can never really expect for a community framework such as Drupal is to be able to move your database from testing to production after you go live. From then on, all database moves are from production to testing, which complicates the deployment process somewhat. Be careful! :)
We use the Features module extensively to capture features and then install them easily at the production site.
I'm surprised that no one mentioned the Deployment module. Here is an excerpt from its project page:
... designed to allow users to easily stage content from one Drupal site to another. Deploy automatically manages dependencies between entities (like node references). It is designed to have a rich API which can be easily extended to be used in a variety of content staging situations.
I don't work with Drupal, but I do work with Joomla a lot. I deploy by archiving all the files in the web root (tar and gzip in my case, but you could use zip) and then uploading and expanding that archive on the production server. I then take a SQL dump (mysqldump -u user -h host -p databasename > dump.sql), upload that, and use the reverse command to insert the data (mysql -u produser -h prodDBserver -p prodDatabase < dump.sql). If you don't have shell access you can upload the files one at a time and write a PHP script to import dump.sql.
Any version control system (GIT, SVN) + Features module to deploy Drupal code + custom settings (content types, custom fields, module dependencies, views etc.).
As Deploy module is still in development mode, so you may like to use Node export module in Drupal 7 to deploy your content / nodes.
If you're new to deployment (and or Drupal) then be sure to do everything in one lump.
You have to be quite careful once there are users effecting content while you are working on another copy.
It is possible to leave the tables that relate to actual content, taxonomy, users, etc. rather than their structure. Then push the ones relating to configuration. However, this add an order of magnitude of complexity.
Apologies if deployment is something old hat to you, thus this is vaguely insulting.
A good strategy that I have found and am currently implementing is to use a combination of the deploy module to migrate my content, and then drush along with dbscripts to merge and update the core and modules. It takes care of database merging even if you have live content, security and module updates, and I currently have mine set up to work with svn.