Trying to understand this CI thing so I've downloaded Jenkins in my production server...
1. Is Jenkins (or any other CI system) installed in the production server or I should have a separate server for Jenkins builds? If Jenkins is in another server, how can I integrate the builds as my running production code? Or this CI thing does have nothing to do with deploys?
Then I created a SSH key at /var/lib/jenkins/.ssh added to my Bitbucket (Git) repository as Deployment key...
2. Is this the correct approach?
...And set the repository URL git@bitbucket.org:... with jenkins user credentials in the Git plugin at project settings. So far so good, my build checkout the project to the Jenkins workspace, then I noticed that every build it run is a checkout and for every checkout, as a Composer powered project, my vendors/ directory isn't there, so I don't have the autoload.php file that phpunit.xml uses as bootstrap to load the classes and run the tests. So besides phpunit as one of the build shell commands I've added composer init.
3. Is this right? Should I run composer init on every build?
The main question maybe is: are my builds constructed from greenfield space? Should I checkout and run composer install and whatever scripts my project must take to be running every time (every build)?
Thanks!
- Is Jenkins (or any other CI system) installed in the production server or I should have a separate server for Jenkins builds? If Jenkins is in another server, how can I integrate the builds as my running production code? Or this CI thing does have nothing to do with deploys?
Then I created a SSH key at /var/lib/jenkins/.ssh added to my Bitbucket >(Git) repository as Deployment key...
- Is this the correct approach?
That's correct. I have a bunch of servers configured this way. In the near future I want investigate if it would be possible to use the SSH Credentials Plugin to store my credentials there, so that I don't have to take care with the file system permissions for that key.
- Is this right? Should I run composer init on every build?
The main question maybe is: are my builds constructed from greenfield space? Should I checkout and run composer install and whatever scripts my project must take to be running every time (every build)?
It depends on your requirements. You can have several builds, or parametrize you build to support different behaviours. For instance, I have Laravel builds that depending on the environment parameter, they might do further testing with Selenium, or simply run phpunit.
I usually have two projects in Jenkins for each PHP application. One that checks out the code from git, clean any left-over of other builds in the workspace, and invokes Laravel's Envoy for building the project. What it basically does, is call composer install with some extra parameters, and call the migration and database seed routines to prepare the application for testing.
The other job is triggered when I promote (with Jenkins Promoted Builds Plugin) a build, and it copies (with the Copy Artifacts Plugin) the workspace created during build and already tested, and deploys it via scp to a folder in a QA server. It then updates some symbolic links, and finally it's ready to test.
With time and more requirements from developers and other teams, you'll get familiar with many other plug-ins, like the Email-ext Plug-in, to send custom notifications and include further information about the build.
Best practices would dictate a separate VM for Jenkins, just to keep it apart from other environments that it might deploy TO.
Jenkins can take down other services using scripts, so taking down the same tomcat running Jenkins that you are deploying a project to would be... inconvenient.
I fall into the camp that favors multiple Jenkins jobs that are chained together. One job builds. Another tests. and a third deploys. That way you know exactly which job is problematic. You can also look at job run times and get a better picture of what is taking so long (is it deploy? is it the unit tests?) and troubleshoot the problems from a higher POV.
I have a Jenkins Best Practices presentation I gave at the Boise Code Camp 2015 available here: http://lanyrd.com/2015/boise-code-camp/sdkggb/