When Automations and Continuous Integrations Fail

Everyone has tasks they have to do but would rather not. There are a handful of things we can automate, and should like paying bills, reminders for appointments or testing code before deploying. Every one of these can fail if you do not have a plan to review them regularly.

Automatic bill pay

Automatic bill pay is a great way to make sure your bills get paid on time. But it is not fully automatic, or it should not be. If you are maxed out on your credit card or do not account for money in your checking account, the payment will fail and may add charges and penalties.

You can prevent penalties by having a budget and knowing when accounts are due. You can also create a buffer, so any unexpected charges do not take you off guard. Having an emergency fund and a backup plan will help you in the long run.

Calendar reminders

Writing appointments in a calendar is a great way to know what is coming up soon. Do you have a meeting Tuesday you need to complete preparation? A birthday or anniversary coming up you need a card or gift?

Regular reviews of your upcoming week will help you plan better; help you be agile. Knowing your schedule is key to not becoming overwhelmed when the unexpected happens.

Continuous Integration

Continuous Integration (CI) is vital for any developer. Correctly set up, the CI process will alert you when the unexcited happens. Using three levels of automatic testing, you can catch 90% or more of the issues that may occur with your site.

  • phpcs – Tests the cleanliness of your code; are you following standards?
  • PHPUnit – Tests the function of your code; does it work as you expect?
  • behat – Tests the front end

But automatic testing is not enough. Computers will only do what someone told them to do. That means if we wrote the test wrong you would see false positives, some of which may not be caught for days. You need to have a human look at the site to very everything is correct.

I believe you should have a three by three testing module, a combination of man and machine.

Dev Test Prod
Code CI/H CI/H H
Function CI/H CI/H H
Front end CI/H CI/H H

Code

  • Dev – A developer writes code and checks it locally with phpcs.
  • Test – The code is checked on every commit, and the results logged, before going live a code review is done by another developer.
  • Live – Periodically you pull the code form live and perform a diff to see if anything changed that you are not aware of.

Function

  • Dev – A developer writes tests and checks it locally with PHPUnit.
  • Test – PHPUnit tests the code before going live, and the results logged.
  • Live – As you are working on the site you note any issues you find so they can be fixed. If the site is somewhat static, create a schedule to test the site every month or two.

Front end

  • Dev – A developer writes behat tests and tests locally.
  • Test – Behat tests run before going live, the Project Manager or tester reviews the side and theme for issues.
  • Live – Periodically you walk through the site to see if the content has changed the layout.

In summary; automate what you can and schedule a time to review your systems.