The Tuenti release and development process blog post series

It’s time to announce a blog post series i’m publishing in the Tuenti developers blog.

It’s about the release and development process and i’ll try to explain how we work internally in our company, since a developer starts programming till the code goes to the production servers, passing through the development environment, Jenkins, the continuous integration and delivery and some internal tools we’ve developed to automate and ease the process.

This first part of the series just makes an introduction of what will come further on and shows the differences of how Tuenti was in the past (4 years ago approximately) and how is now.

In a nutshell, before there were many manual and error prone tasks the ended up in bugs in the site and now, everything is fast, reliable and automatic, with no manual intervetion at all.

I will announce the forthcoming posts here.


4 thoughts on “The Tuenti release and development process blog post series

  1. No, we don’t use any control version system for DB changes. I think the only reason to use one is to be able to go back to a previous version just in case a release needs to be reverted.

    In our case, we almost never rollback releases, usually that is the last option to consider and in the case we need to rollback a release, we always force developers to make the code to be released backwards compatible with the old schema, so there is no problem with the new schema and we don’t need to change it.

    But, that’s not feasible always (sometimes there is no way to make the code backwards compatible), but it is in most of the cases, so far we haven’t had problems with it but it’s true that we don’t have a perfect solution. And i think that DB schema changes is one of the hardest issue to solve, at least, i’ve been discussing about that in some conferences i attend and we couldn’t find the silver bullet.

    So, if you find it, please tell me πŸ˜‰

    • Yep, thats true, deal with database schema changes many times it’s hard. Also some schema changes requires to change also some data, and rollback to previous releases with broken FK it’s not a fun situation.

      Some time ago in our company we integrated liquibase (, it allows manage the database changes with small changelog files (in xml, json, etc).
      So when you release a new version that needs a schema or data change, you can create a new release database changelog file and liquibase will apply it automaticaly during the deployment process, allowing also the rollback if it’s necessary.

      The cons, you have to invest time to translate your schema to the liquibase format and test in depth the commit and rollback of the database changes.

      We integrated liquibase in a small project some time ago, and after a few problems worked like a charm.

      Hope it helps πŸ˜‰

      • Thanks for the link, we’ll check it out.

        I remember we studied this kind of tools some time ago but in the end we didn’t use them, i don’t know why… maybe it’s a good time to reconsider such options

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s