I am trying to set up Jenkins to run our Cucumber features. I am a little lost when it comes to setting this up. Here are some details of our setup:
Cucumber features with steps written in Ruby and PHP (using Cuke4PHP)
PHP application (which often links to other PHP applications)
Using Capybara and Selenium to exercise Javascript
In development environments, since our apps need to link to each other, we set up apache vhosts with domains like http://developername.dev.exampleapp.com
How should I set up this Jenkins environment to run our cucumber tests?
It seems like you would want to set up a virtual machine using VirtualBox or something in order to set up an environment similar to your production environment and serve the project from that virtual host. But then do you run the tests outside the virtual machine? Or do you run the tests on the virtual machine and report back to Jenkins? Do you set up virtual hosts when you provision the virtual machine? How do you set up your project to use an isolated database? How do you run your features in parallel so they don't take forever? If someone could shed some light I would greatly appreciate it.
We have recently started using Vagrant to setup a development environment on virtual machine in which we use folder sharing between host machine and guest Vm for application source code and application database itself is on Virtual machine. We haven't implemented with CI yet though.
For setting up your application environment for a build, you can use Vagrant to setup your applications environment. And assign a ip for your Vm which can handle Virtualhost for that ip by itself.
For running the tests, your selenium/acceptance tests should run from your host/build machine, considering a client and server architecture for you applications as pointed by Amber. But unit test should run on your VM itself. I don't have much idea about running features in parallel. But will share my experience once we have implemented whole process into CI.
Do you have your clients run their browsers on your production servers? (Hopefully not - hopefully they run them on their own computers!) Thus:
The server VM is the equivalent of your production server, so it's not where the tests should be running - Selenium tests run in the browser. Depending on how many browsers/what kinds of browser setups you want to test, you can either set up separate VMs with OS/browser combos to run the tests, or you can run them outside of a VM on a standard browser install.
Related
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.
I currently have a problem with how to setup my virtual environment for my LAMP stack. The site I'm developing is a web application written in PHP and uses MySQL for the database. Right now, I have a single VM running inside Virtualbox with CentOS. I run the web/mysql server in it and have my code folder setup with GIT.
The host OS (Mac/Windows) currently is setup with a SAMBA share to access the code inside the GIT folder on the VM. From this, I use SourceTree and PHPStorm to manipulate the files and make commits. Permissions on the files/folders are set with a force mask (which doesn't seem to be possible with NFS)
(Samba server on CentOS(guest os), Samba client on Windows/Mac(host os))
The problems occur on occasion when I run my environment like this. I've had my GIT repository have weird errors and corrupting (HEAD detaching, index files corrupting / being too small, other .git files corrupting). There is also an issue where the file names are case insensitive and the CentOS guest OS runs it as case sensitive.
Ultimately, my questions is: How can I setup my development environment to execute the code inside my CentOS Guest OS, have file permissions not be a hassle when I'm commiting/executing, allow me to setup an environment that will match my multi-server environment (ie. multiple Virtualbox instances), and have it run into no or minor problems as if I was just running it all under CentOS for development?
I would prefer to be able to run VirtualBox, be able to develop my software using my PHPStorm/SourceTree applications on my Host OS, and avoid any problems that lead to corruption of my filesystem in GIT.
I am working on a multi-site Magento implementation and I need suggestions.
I am working on a dual core 1.8ghz machine at work with 3GB ram and have found it to be very slow when using MAMP for my personal development environment, so I have set up a virtual machine using CentOS that mimics the actual staging and production server.
The problem is I have to do my changes, commit them to SVN and then update the repository on my virtual server which is using a crap load of production time. This Magento implementation is a multi site/store so it uses a lot of RAM and I need a stable file system with speed.
I am on a Windows XP Pro machine using WAMP normally but like I said I have found that to be slow. Is there any way I could develop it on my machine without it slowing down every other process?
I have my IDE (Aptana) open and most the time Thunderbird open as well as MySQL Workbench so I have a lot of programs running and the Virtual Machine dedicates those resources, but like I said it it tedious to continuously update the repository.
Can any Magento or expert developers weigh in? I really want to plan ahead for when I get more projects like this, and I would love to hear what some of you other developers do.
Thanks,
Darren
You don't specify that the virtual box is remote, but I'm going to make that assumption here (since a virtual box on your local host would by definition be slower than the machine it is hosted on).
I would suggest connecting to your higher-spec machine remotely to work with the files and testing on that environment. Basically, use it as a development instance and make changes remotely. Then, check in those changes as necessary.
I am very much a Linux developer so your toolchain is a bit outside of my expertise, but you should be able to mount the remote drive as a local network drive, or your IDE may even support mounting it over SSH (which would probably be a bit faster).
Hope that helps!
Thanks,
Joe
EDIT: I should say that, if your virtual instance is not remote, that changes my answer a little bit. Go rent a virtual dedicated machine with some reasonable stats, set it up for Magento, and then do go the above. The monthly cost of a virtual dedicated machine is quite low compared to any hardware technology upgrades you might buy, and it gives you a safe place to break things. The downside to this workflow is that you must be online to accomplish anything.
I develop locally on a Mac using MAMP (and in the past Zend Server). The IDE of my choice is Netbeans. I highly suggest you checkout (no pun intended) Git for doing development work.
I have a server that I use for production and staging. The production and staging have two different databases. A Git central repo also resides on this server.
Essentially, I do my modules and dev work locally on my Mac. I try upgrades and such, then use Git to commit them and push them to the central repo on the server. Once there, I merge the changes into the staging server and test, test, test. If everything is cool, I then pull (merge) the changes into production.
This has served my purposes quite well and I have not had a botched upgrade or anything... if something goes wrong you just rollback the changes in Git. You did make a dump of the DB before upgrading correct :)
As you get more sophisticated you can start using phing to do some automated roll out of your code, but that is another story all together.
Best of luck!
I have a question related to phing. Do I use it on my local development machine to deploy an application or do I call it via ssh from production machine? I'm not sure where to do the steps from Eran Galperin (What is your preferred PHP deployment strategy). I'm a beginner with deployment scripts. So be forgiving :)
Marco
You'll usually have two deploy scripts - One that you run locally, which ssh's in to the remote server and then kicks off the remote script.
Your local script might do an svn export, zip the contents and push them (scp) to the remote server first. The remote script would do stuff like migrating, restarting services etc.
The basic strategy is that you create a build (well, basically a copy of your web application that you can put online) on your local machine, and then deploy it on the server.
You run it on your local machine and the PHPing will connect to production server and deploy the website. :)
Phing can be applied in many ways.
If you don't have directives on how to deploy, the best way is usually first to generate a "test build" from your local copy, check out if it is working as intended and then generate the productive build.
In some cases where you have to follow certain rules in your development enviroment you can easily adapt Phing to meet those demands.
I developed a phing deploy script and I've used it in both of the ways you've described. As long as the phing library and dependencies are installed locally or on the remote machine you can do it in both ways, and it's actually a benefit to be able to run it from any of your environments.
Let me elaborate on my experience, but keep in mind that every person lives within the microcosm of the needs and requirements of their own projects/studios so it's possible that what works for me, may not work for other people.
I think deployment is usually so important for a business that it needs to happen in the exact same way every time. When there's a multitude of people doing the deployments, then it's easy for bad habits or procedures to diverge and that's when mistakes can happen. Automated deployments with phng are handy because if everyone is using the same procedure, then there's much lower potential for mistakes. Phing makes it easy to follow strict procedures because all the developers have to do is to run a simple command like "phing deploy" or "phing build" or what have you.
Now going back to your original question, it's also helpful for these procedures to be adhered to on local development machines as well as on staging, testing, production servers because just like people, machines can have small ideosyncracies that differ from machine to machine. With phing, you can develop a script that will have the same results on any of your enterprise machines (depending on the strength and intent of your code but phing lives in a format that makes it easy to meet that ideal). So if you run your phing build from your development box, ideally it has the same effect if you run it from your testing box or your production server. If you can run the deployment the same way on any machine, you can feel confident that any problems that arise after deployment were not a result of your deploy procedures (as they will not differ from when you deployed to your testing or local dev box).
It's really nice to be able to deploy my code to my local machine with the exact same procedure that I use to deploy it to production.
As far as what is the best to do, I say, why not all of the above? If you can run it locally, then you can run it remotely. If the deploy procedures are strong, then the result will be the same.
You can do it both ways. You can run the tool locally as you develop to run tests and just generally ensure that your code is in good condition. The server automation (if you choose to do that) can also run tests, generate documentation, and deploy changes to test or production setups.
Doing it locally reduces the chance that the process will get stalled on the server setup, while the CI works on a regular basis to ensure nothing has been broken via mistake.
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.