Micro perl code#
The whole system was becoming untenable.While tests let you catch breakage like this, working on a fix at a given point in time is a cost that you may not want to incur. while our services/scripts were working at that point, we couldn’t fully discount the possibility that a future change in environment (and not the code!) in a direct or indirect way could bring down some critical services - which we couldn’t afford. They were forced to use our shared development environment which could get some time to get used to. It was hard to even work on a small part of the codebase as it was not possible to run a script/service in isolation. However, it was intimidating for new team members. To be fair, our monolithic codebase was fairly modular and it was not that hard for people who were familiar with it (we were a 5-person engineering unit then) to build on/extend it. It was getting difficult to on-board new engineers into the team quickly.This was also a problem because for any given module (as it was installed globally), we didn’t know who its dependents were We were starting to get very conservative about upgrading dependent modules because we didn’t want existing scripts/services to break. This was largely because of the tight coupling between our code and the environment in which it was running on. Deploying code across our fleet of machines had become very slow.
Two years in, in 2014, we had a few problems - problems that we had brushed aside earlier but which were now staring at us in the face:
However, best practices are best practices for a reason. We were aware of the pitfalls of this approach but found the convenience that it offered, in helping us ship fast in the early days of the company, very valuable. We used system Perl (the version that ships with the OS) and installed dependent modules globally. We started off with a single code-base like most other startups. We must admit that our development process wasn’t always the way that it is today.
0 kommentar(er)
