Research Notes on CI systems for Pallant

ci-systems.md

Requirements

• Build Checks
• Unit Testing
• Behavior Testing
• Deployment

Workflow / Environment changes

1. Standardising and implementing testing procedures
   1. Build checks (verifying the build, i.e. everything has been compiled as expected )
   2. Behaviour vs Unit tests
   3. PHPUnit for php projects? Codeception allows Behaviour and unit tests
   4. QUnit, Jasmin, Mocha etc for javascript projects?
2. Building everything as a 'package' i.e. Composer or NPM with build scripts and unit tests all configured using those.
3. Rollback command for our shell scripts, basically to revert back to previous, or specific release (version) and re-deploy

Software Options

1. Jenkins + EC2
2. BitBucket Pipelines
3. Drone.io
4. Any number of other paid for services

Jenkins + EC2

Features

It's free and Open source, well supported.

The most popular open source solution to CI.

"Blue Ocean" plugin currently a beta looks like it's going to make the UI super nice.

1000+ community contributed plugins for deploying / building etc, which could make it easy / quick.

It means running a server, so the 'freeness' of it is counteracted by the need for us to maintain a server.

Min requirements are Java 8 , 1GB Ram, 50GB+ disk space

BitBucket Pipelines

As far as I can tell, both build/test scripts AND deployment would need to be built into a single YAML file. i.e. no preset easy deploy methods.

It's new, not yet established, pricing may change in the new year when they launch it.

Interface currently is confusing, I cannot figure out if it's possible to have multiple build scripts or not.

Drone.io

I've had a quick look at this and it seems to be quite cost effective, they're quoted as saying that it's cheaper than Jenkins on EC2, plus it's hosted / managed. I've also briefly looked at several others (there are literally hundreds of CI(aaS)) and most of them seem more expensive than Drone.io so using this as the baseline.

$25 a month for 5 projects, $49 a month for unlimited projects (though 5 is probably enough for us at the moment)

Features

Supports BitBucket (Travis does not). Built to be simple and extensible, definitely a nice way to start. Took 5 minutes to set up a working deploy script for one of my sites.

Build & Testing

The ability to write build scripts in a variety of languages (Node, PHP) for Unit testing, using Docker containers if needed.

Can run phantomJS / Firefox / Chrome or Selenium for behavior tests.

Status Badges -> which we can embed in readme files to check current build status, also useful to build a Dev Dashboard to see all current build and test statuses for all projects.

Deployment

The ability to set up multiple deployments on different branches so we could push to dev servers / live servers separately.

Can deploy via SSH or direct to S3, Heroku, AppEngine, dotCloud. SSH is probably most straight forward for our current infrastructure.

Notifications

Email notifications on successful / failed builds

Issues

Their PHP image is Beta and 5.4. There are some known issues with running Composer on high volume build server. Not sure this will be a problem unless we start writing some PHP 7 apps that are in no way backwards compatible.

workflow.md

Workflow

After looking into Jenkins, I think testing and deploying needs to be considered as totally separate processes. Deploying simply requires a script / server to connect to the remote server and run some stuff. Testing each build however requires a testing/staging server. While this can be done on our local dev boxes. Our local environments tend to vary from the production environment so an actual Staging server would be best served as a duplicate of the production server.

We could use something like Drone.io to deploy the code to staging, and then run the tests on the staging env (rather than using their nice Docker virtual machines), though I'm not sure if this is overkill for something that essentially does the following;

• SSH to server
• CD to designated path
• git clone / pull / move
• Record the responses

In a scenario where we don't necessarily have a staging server (although for the pallant projects we could have a duplicate of the server for staging), we can run the tests locally just fine before deploying. Having the CI system just ties those processes / workflows together into a visible recordable form with plugins / rollbacks etc.

1. Change Something ( Hotfix / Feature)

2. Run Tests locally on branch

3. Merge ( Hotfix / Release )

4. Build

   • Rebuild all CSS files
   • Rebuild all JS files
   • Rebuild manifest

5. Test

   • Update Test Environment (could be local, could be staging / additional server)
   • Run Acceptance Tests
   • Run Unit Tests

6. Deploy

   • Merge and push changes to origin/master + Tag latest version
   • Pull changes on production into src/repo folder
   • Checkout to latest version tag
   • composer update
   • php artisan migrate --env=live
   • rsync / copy files from release folder into new release based on tag (/wherever/releases/1.10.1/)
   • symlink latest release folder to /var/www/
   • Remove old releases (keep 1 previous release?)

7. Rollback

   • if previous / chosen release folder doesn't exist (/wherever/releases/chosen/)
     • Check src/repo folder out to previous / chosen tag
     • composer update
     • php artisan migrate --env=live
     • Copy files into relevant release folder (/wherever/releases/chosen)
   • Switch symlink to chosen release, delete newer release folder