Month: November 2013

Life, Uncategorized

Thanksgiving 2013


It is again that time of the year when we in the US take a break from our busy lives to express Gratitude (and eat, shop, etc).

Gratitude is a positive emotion we feel in acknowledgment of a benefit we have received. Saying “Thank You” is the way to express that emotion which is the basis of life in community. It recognizes that we depend on one another to live, to be ourselves.

We get used to say “Thank You” as a matter of social protocol. This is the time to bring its meaning back to consciousness.

I grew up in Brazil and my native language is Portuguese. We say “Obrigado“, which is not my favorite expression because it equals gratitude with indebtedness. Literally, it says “I owe you something in exchange for this”.

In my travels around the world I have always taken interest not only on the local word to express gratitude, but also on its literal meaning and the social attitude behind it.

My favorite form of “Thank You” is the one used in Malaysia. “Terima Kasih” sounds very friendly and it literally translates to “Receive Love”.

I am no historian or linguist, but I theorize that words equating gratitude and indebtedness have roots in a period in history where gratitude was used as social currency between levels of hierarchy, where favors were exchanged for political loyalty. Words that equals gratitude with love reflect a more equal exchange between peers.

As we shift towards a world where stronger relationships are more equal and transparent, gratitude has to be more like love and less like indebtedness.

With that in mind, I would like to say Thank You for reading, agreeing or disagreeing, providing feedback and teaching me through interaction in 2013.

Here is a list to say Thank You in other languages.

Happy Thanksgiving.

Uncategorized

The Road to Continuous Delivery in SW Development


(this post originally written for Daitan Blog)

Once upon a time, people just wrote code and then run it to find how well it worked. Working individually, the developer was able to iterate quickly until the software was useful to solve a real problem.

By the 1990’s, as software became more complex, it was broken into separate and independent sub-modules developed more or less in isolation by individual developers. Each sub-module was tested, the system was integrated back together, then tested, staged, released, deployed. Software development cycles stretched over several months (or several years).

The pendulum is swinging back. Software engineering is now evolving towards shortening the feedback loops and minimizing the time it takes from code being written and being in production. This time, we want to do it with more quality and predictability. The tools to achieve that are processes, automation, and collaboration.

Process Agility

Moving across the levels depicted on the picture above (Source Code Control, Build Automation, Test Automation, Continuous Integration, Release Automation, Continuous Delivery) is not simple. It involves not only changing processes and automating them, but also changes in culture and organization.

  • Source Code Control – Single source code repository with version control.
  • Build Automation – Compile and Build applications without human intervention.
  • Test Automation – Execute unit, integration and service tests without human intervention.
  • Continuous Integration – Developers integrate code into a shared repository (which triggers automated build/test) often.
  • Release Automation – Packaging, deploying and post-deployment testing without human intervention.
  • Continuous Delivery – Every change to the system is releasable. Release can be done by the push of a button.

Continuous Integration

Continuous Integration (CI) is the practice of accelerating the daily commits of code by software developers. If in the past developers would work for weeks before trying to integrate their work to the main tree, in a CI environment you want developers to check-in their work several times a day.

A CI server monitors code check-outs and check-ins by developers and, as often as practical, it builds the system and runs unit and integration tests. If there is any failure in the process, the CI server alerts the developers. A broken build gets the attention and top priority from the team.

CI requires test-driven development and automation.

Benefits:

  • CI does not eliminate software bugs, but it accelerates their discovery and keeps people from going in the wrong direction for too long.
  • The system is always in a state that can be released to users. That provides more flexibility to the business and enables the automation of the release process and delivery to users.

Continuous Delivery

Once you are doing Continuous Integration and is able to automate the deployment process, you can consider extending the process and automation all the way to the end-user. Continuous Delivery (CD) is the practice and ability to rapidly, reliably and repeatedly push out enhancements and bug fixes to customers at low risk and with minimal manual overhead.

The automation system let changes to the system be released on a granular basis. Releasing features just to a subset of users and being able to seamless roll back to a previous version become possible.

The result is that there is no delay between enhancements and bug fixes being implemented and available to users.