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.

Continuous Integration and Continuous Development

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