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 !!

easing a hurricane called TEAM

Meetup WordPress Porto

I had the pleasure to attend the WordPress Oporto’s Meetup. A group of geeks that get together monthly, uninterrupted for 4 years and counting. Travelling to the beautiful city of Oporto is always a pleasure, even if the distance from Lisbon goes past 300km.

easing a hurricane called TEAM

My presentation’s title. This talk starts with a brief travel on some moments of my career as a software developer. With some much needed passages on some “dramas”, which without those, I wasn’t what I am today. Those moments also enabled me to connect with some of the best professionals in the field. Some, I have the pleasure to call friends nowadays.

With them I learned what SCRUM and eXtreme Programming was and, the real importance of a CTO as a human being.

Years gone by, I see myself in that place, leading a software development team in a company that permits the usage of some of those eXtreme Programming best practices.

The second half of my talk goes on those best practices (coding standards, code review, test-driven development, continuous integration, continuous delivery), what they do daily to my team and for my team.

Next November 2nd I will have the opportunity to revisit this presentation, now at Lisbon in the change.log meetup.

Hope to catch you there.