In bart, we’re developing dozens of projects – sometimes we work on them in the office, sometimes from home. If we want to code or test something, we always have to run the project locally. In our case, this process has so far included the build (minification and compiling code, adding components from libraries, etc.) of all its components (services). The more services the project uses (API, databases…), the longer it takes to “get started” so that a person can realistically look at it or work on it.
In practice, in some cases you can start the project and go have a cup of coffee for 10 minutes, until all the builds pass and you can actually intervene in the code. This is especially ineffective if you just need to insert one or two commands or test something. In addition, if there’s two of you working on a project, each on their own computer, the launch process takes place at both. At least you can go and have a cup of coffee together.
Prolonged launching takes away your (and the customer’s) most important commodity – time. And since we value our and our clients’ time, we sat down one Wednesday after work and set up the task to come up with a faster way of compiling the Crossuite project. Recently, we have expanded it quite a lot and so the whole system needed proper optimization.
There were six of us in the beginning. During the first hour, we explained the structure of the current functioning and the reasons why the triggering system needs to be redone. The next two hours were spent on analysis and pizza. We brainstormed a lot, designed a concept and divided tasks. And the last five hours were spent coding. I arrived home at 1:30 in the morning, but with a good feeling of achieving something.
And what did we achieve?
The new launch system that we designed and partially tested is constructed so that build is performed automatically, for example after pushing the code of a given service into the repository. At the same time, the so-called service image is created – a version that is ready for use but cannot be interfered with.
When someone subsequently starts the app, this part doesn’t need to be built – the solution simply loads the prepared images. If a programmer wants to change something in the code, they only build the service they need to edit. Everything else is ready for use. The total launching time is thus reduced from tens of minutes to seconds.
Colleagues from the QA team were most delighted by this new feature, as they often launch the project without the need to intervene in it, just to verify whether something works as it should. Since they don’t need to change any part of the code, just look at the result, images are enough for them and the entire build process is omitted.
We were able to solve the automatic build for the 6 most critical services of our project. In order to deploy the solution into production, we need to provide it for the other ones, write down the documentation, complete the initiation of the database… However, we have laid a solid foundation at the hackathon and verified in practice something, until now, theoretical. Plus, we had a great meal and a great laugh. Such Wednesdays could be more frequent, without question.
