Continuous Integration/Development Programming


  • Is it going to fix something or make it more performant?
  • Can we afford it breaking what’s already working?
  • Does it require rewriting a lot of tests?
  • Do we really need to make that change?

From Mohamed Said – Laravel Team

Continuous Integration/Development

How to setup Continuous Integration ?

Developers practicing continuous integration merge their changes back to the main branch as often as possible. The developer’s changes are validated by creating a build and running automated tests against the build. By doing so, you avoid the integration hell that usually happens when people wait for release day to merge their changes into the release branch.

Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch.

see diagram here

See steps by step implementation here

Continuous Integration/Development Git

How to resolve GITHUB key already in use ?

Find out which repository is already in use

ssh -T -ai ~/.ssh/id_rsa [email protected]

Solution 1

#1 Remove the key from your GITHUB repository->deploy

#2 Copy your key from macbook

pbcopy < ~/.ssh/

#3 Paste your key in the Github->repository you want to use

Solution 2

you can do a do a git clone against the https url

git clone

Continuous Integration/Development Programming Web API

How to step by step implement Continuous Integration and Continuous Development in your software team ?

Fast development and Integration according to David Raleche – Process





  • Introducing new bugs after making a change (No proper regression test)
  • Increase Automation overall
  • Lack of transparency
  • Improve quality and testability
  • No Proper Api documentation (Swagger)


  • Duplicate code throughout the program
  • Reading or writing code which is difficult to understand (PSR-2)
  • No Peer Programming (Code Review) in place (Pull Request)




  • DRY do not repeat yourself
  • KISS – Keep it Stupid Simple
  • PSR-2 Code Styling
  • PSR-3 Log for debug purposes
  • PSR-4 Comment Code Properly
  • Function no exceeding 40 lines




  • PHP Code
    • No Errors
    • No Warnings
    • No Notices
  • Unit Testing – 2 per api calls


  • CREATE Functional API Test


    • 3 positive tests
    • 3 negatives



  • Final API Documentation (swagger)



  • Check PHP logs (Nagios)
    • PHP Code
      • No Errors
      • No Warnings
      • No Notices


  • Execute Regression Testing

  • Make sure unit testing reach out full Code coverage