{"id":12730,"date":"2019-04-12T10:41:29","date_gmt":"2019-04-12T08:41:29","guid":{"rendered":"https:\/\/chartmogul.com\/blog\/?p=12730"},"modified":"2023-08-11T11:13:52","modified_gmt":"2023-08-11T09:13:52","slug":"the-continuous-saga","status":"publish","type":"post","link":"https:\/\/chartmogul.com\/blog\/the-continuous-saga\/","title":{"rendered":"The Continuous Saga: how to keep a steady pace without breaking things"},"content":{"rendered":"\n

One of the most exciting and important moments for a product and engineering team is when you grow beyond 2-3 contributors to as many as 10-15. In my experience everyone is full of energy, is positive and is engaged — but with more hands on and ideas on the development lifecycle, there is more room for risks and roadblocks.<\/p>\n\n\n\n

Imagine a scenario like this…<\/em><\/p>\n\n\n\n

Your new, bigger team starts to implement multiple changes to the product(s), autonomously, in parallel and without the level of coordination that you used to have when there were just a few people. Sound familiar?<\/p>\n\n\n\n

At first, all is okay (exciting even) but in time, product starts to bleed from each and every angle. As a result, the team spends more time fighting fires and eventually, burnout sets in. One by one, each person becomes less engaged and as a team lead, you are left to pick up and resolve resulting personnel and product issues.<\/p>\n\n\n\n

As a functional team lead in product or in engineering, it is critical that you prevent a scenario like this in order to ensure the long term success of the business and of course, the happiness of your customers.<\/p>\n\n\n\n

Avoid the avoidable<\/h2>\n\n\n\n

It\u2019s been almost a decade since Jez Humble and David Farley released Continuous Delivery<\/a>, in which they formalized state-of-the-art principles and practices to craft quality software at scale. The first iPad was just being released; Atari was still a company and Bitcoin was worth $0.01.<\/p>\n\n\n\n

Today continuous delivery is not just a nice-to-have — it is a must-have if your goal is to provide high value to your clients. However in order to talk about continuous delivery, we first need to have a broader conversation about what I call the continuous saga: continuous integration, continuous delivery and continuous deployment.<\/em><\/p>\n\n\n\n

Continuous Integration<\/h3>\n\n\n\n

The youngest of the three was first mentioned in 1991 in the context of extreme programming. The goal of CI is simply to integrate and test every single change<\/em> you add to your code base (aka product). <\/p>\n\n\n\n

So in other words, every time an engineer adds code to the version that is currently running in production, principles of CI mean that you are integrating and testing the full application before releasing it.<\/p>\n\n\n\n

\"\"\/<\/figure><\/div>\n\n\n\n

So what?<\/p>\n\n\n\n

Continuous integration helps the overall product development process because it:<\/p>\n\n\n\n