Continuous Integration

Continuous Integration


Continuous Integration (CI) is a process that allows developers to integrate, in a repository share by the entire team, code developed by himself, at least once a day. At an Utopian Universe, those integrations should happen several times each day, basically every time some code is “pushed” into the repository. This action will trigger the automated process.


Agile methodologies demands code to be always “ready” to be delivered. This process of continuous integration of the entire team’s code, in the product/project code base, allows an early error detection.

In a Waterfall process, each code delivery might took several months to happen. As you can imagine, in that time, it was usual to set a “War Room”, where the entire development team would be, in the company of the entire operations team, QA team, product team, and management team. The delivery process were a terrible chaos, a real nightmare, and it could take hours to deliver (don’t bother asking about any issue that might occur, the responsible team had to fix it “pronto”).

In fact, back in those days, imagining that each code push might trigger a battery of tests (unit, integration, acceptance, …) and have immediate feedback about the possibility of the new code breaks any existing functionality, it was unthinkable. A true adventure !!


There are several available options for those that wish to start using a development pipeline with continuous integration. Probably the most notorious is Jenkins. An open-source tool written in JAVA. To those that do not want to add another tool to their setlist of tools to administer/manage, there are some SaaS solutions. Nowadays, at log, we use the CloudBees’ SaaS Codeship.

Once configured, every time a new push to a Git repository happens, it will trigger an automated process where a virtual environment, with characteristics specified by ourselves, is set and where the build process will happen, followed by the entire tests battery – unit, integration, acceptance, mutation, …

In any scenario, if a problem occurs, the entire continuous integration process fails and we will have a complete report. It is important to state that when the process fails, there are no possibilities for a deployment – automatic or manual – to whichever environment.

There will be no eXtreme Programming without this important process !!

Code Review

Code Review

IBM championed the code review process since a long time, in fact since 1974. It was initially defined as a “code inspection”, a formal static analysis process to evaluate if the software was full-filling the requirements. This process was slow but, even so, IBM enabled to obtain significant quality improvements in the delivered code.

The company (IBM) nearly doubled the number of lines of code shipped for System/370 software products since 1976, while the number of defects per thousand lines of code was reduced by two-thirds – Michael Fagan

Thanks to collaborative version control tools, it was possible to speed up this process, making it a daily routine process. In my team, in every single day, each software engineer reads, reviews, evaluates and comments on a colleague’s code. The ultimate goal is increase trust in the shippable code, reducing the number of possible bugs. The review process implies that the code may be updated and reviewed again. This exchange – between the author and the reviewer – should happen the necessary number of times until the demand level of quality is secured.

There aren’t specific rules on how this process should work. With the dissemination of this process, the good sense prevailed and some good practices emerged from different sources.

SmartBear Software company published a small white-paper with 11 good practices for an effective code review process:

  1. Review fewer than 200-400 lines of code (LOC) at a time.
    • More then 400 LOC will demand more time, and will demoralise the reviewer who will know before hand that this task will take him an enormous amount of time.
  2. Aim for an inspection rate of less than 300-500 LOC/hour.
    • It is preferable to review less LOC but to look for situations such as bugs, possible security holes, possible optimisation failures and even possible design or architecture flaws.
  3. Take enough time for a proper, slow review, but not more than 60-90 minutes.
    • As it is a task that requires attention to detail, the ability to concentrate will drastically decrease the longer it takes the task to complete. From personal experience, after 60 minutes of effective code review, or you take a break (go for a coffee, get up from the chair and do some stretching, read an article, etc.), or you start being complacent with the code on sensitive matters such as security issues, optimisation, and scalability.
  4. Authors should annotate source code before the review begins.
    • It is important for the author to inform colleagues which files should be reviewed, preventing previously reviewed code from being validated again.
  5. Establish quantifiable goals for code review and capture metrics so you can improve your processes.
    • It is important that the management team has a way of quantifying whether the code review process is effective, such as accounting for the number of bugs reported by the client.
  6. Checklists substantially improve results for both authors and reviewers.
    • What to review? Without a list, each engineer can search for something in particular and leave forgotten other important points.
  7. Verify that defects are actually fixed!
    • It isn’t enough for a reviewer to indicate where the faults are or to suggest improvements. And it’s not a matter of trusting colleagues. It’s important to validate that, in fact, the changes where well implemented.
  8. Managers must foster a good code review culture in which finding defects is viewed positively.
    • It is necessary to avoid the culture of “why you didn’t write it well in the first time?”. It’s important that zero bugs are found in production. The development and revision stage is where they are to be found. It is important to have room for an engineer to make a mistake. Only then can you learn something new.
  9. Beware the “Big Brother” effect.
    • Similar to point 8, but from the engineer’s perspective. It is important to be aware that the suggestions or bugs reported in code reviews are quantifiable. This data should serve the managers to see if the process is working or if an engineer is in particular difficulty. But should never be used for performance evaluations.
  10. The Ego Effect: Do at least some code review, even if you don’t have time to review it all.
    • Knowing that our code will be peer reviewed alerts us to be more cautious in what we write.
  11. Lightweight-style code reviews are efficient, practical, and effective at finding bugs.
    • It’s not necessary to enter in the procedure described by IBM 30 years ago, where 5-10 people would close themselves for periodic meetings with code impressions and scribble each line of code. Using tools like Git, you can participate in the code review process, write and associate comments with specific lines, discuss solutions through asynchronous messages with the author, etc.

I advise you to read the document for a more in-depth view of each point.

It is impossible to refute that the code review will improve the quality of the code produced, reducing the number of bugs and improving the design. There are some additional assets such as sharing knowledge among peers and mentoring more junior team members.

It’s a fact that this process, even if done in a lighter way, will take time to the project. In the review process, we have to add the author’s response time and again the review time again. In an attempt to expedite this consumption of time, I advise that, after two unsuccessful revisions, the author and the reviewer sit side by side and debate the piece of code that is causing the problem.

But it’s really important to state a phrase from IBM’s site –  Slow down to go faster.

I would like to end with a note, which I have as too important. The code review process demands the entire development team to demonstrate high emotional intelligence. As a rule, programmers have a strong ego and feel they are “parents” of the code written by themselves. It’s sometimes not easy to accept less constructive comments. Totally destructive, provocative or jocular commentaries “will do more harm than good,” and may even destroy the morale of a team. It is important to follow these elements, to try to change their attitudes or, as a last resort, to remove them from the team.

Coding Standards

Are you one of those developers that use to write code in some sort of cypher, whose only you understands, afraid of being ripped off of your code or seeing your job terminated?

Hopefully you will read this through because I have bad news to you.

To the rest of you, please continue. You will find value for sure.

WordPress community uses the tagline “code is poetry“. I rather think of code as a good prose, written with attention, using decent punctuation and with no hidden sense. Basically, going through all the “clean code” mantras.

Standard (male noun), which serves as a model or reference.

By definition, everything that may serve as a model or reference enabling consistency might be called a standard. Therefore, a standard may be just a coding guide style; or some well proofed formulas to specific problems, known as design patterns.

Standards adoption allows a better code readability. This means, your code will be more easy to be read by others. Contrary to the initial premise, more eyes over the code will improve the detection of bugs, security and performance flaws. This will also diminish the feeling of sole ownership, allowing a better knowledge share among the entire team. No, nobody will take your place…in fact, you will improve chances to become a better developer, and that will help you keep that job longer.

(Source: Rose-Hulman – Institute of Technology)

Design patterns aren’t a new thing, they exists quite some time and there’s an amazing book, written by the gang of 4 – Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides – “Design Patterns: Elements of Reusable Object-Oriented Software“.

However, in this post I intend to focus more on style guides.

At log, we daily use PHP and WordPress, JavaScript, CSS and HTML. I think that every single programming language has its own coding style guide.

There’s a project called “PHP Framework Interop Group” where are debated which standards will be enforced by the PHP community. Related to style guides we have the PSR-1 (Basic Coding Standard) and the PSR-2 (Coding Style Guide). There’s a proposal for a new standard, the PSR-12 (Extended Style Guide) but it’s a draft in early stages.

WordPress, although its codebase is PHP, suggests a different style guide – WordPress Coding Standards – whom collides with the PSR-2. If your intent is plugin or theme development, or say you want to collaborate for the core codebase, you better respect the WordPress style guide.

In our team we follow the WordPress Coding Standards, but we added some rules of our own. Please, be free to read, use or contribute in our github.

Many times, if not the majority of times, this sort of projects born inside companies that may not be directly related with the creation of the language or framework (or CMS). JavaScript Coding Style Guide by airbnb is a good example of it. One of many advantages of Open-Source software for sure. The project is born inside some company and its ownership belongs to the World since there are many external collaborators working in its maintenance and evolution.

CSS related, there are many methodologies like BEM (Block Element Modifier), which one we use at log.

Bottom-line, it does not matter if you will adopt the style guide A or B, but if any will be adopted by your entire team. That’s the biggest challenge and where the major benefits will arise. The feeling of share ownership will increase code quality. Better code quality will decrease the number of bug reports. Better code will be easy to maintain. Better code will enable your system to be more mature and stable. A better system will make you more proud of your work and soo as your employer.

As you see, the entire team will benefit, and so will you.