Method 1 - The Aggregator Pattern
\nThe Aggregator Pattern is usually a standalone microservice. It offers a uniform API that a client can use to access data from different microservices.
\nThis composite service is utilized when we need to prepare the result data produced from the outputs of several microservices. The aggregator pattern is designed to combine data from several endpoints and provide it as a single endpoint to the client. If necessary, it can also cache that data according to predetermined criteria or rules. You can read more about this pattern here: https://www.edureka.co/blog/microservices-design-patterns
\nSo to sum up, we can simply execute two or more api requests to separate services and accumulate the data we need to show the results in the list. This sounds good, except for one drawback: Performance! It is at the expense of performance. One more way to enhance this behavior is by using asynchronous api requests, which basically execute these multiple api requests in parallel. However, it does not provide the best performance (depending on the use-case, it was not an option for us).
\nMethod 2 - Importing the data into the microservice
\nSince the data like VIN, stock number, etc. will not change in the future, importing fixed data to the service database sounds very suitable. So the key message here is: don't rely on sending synchronous queries to obtain data that was previously controlled by another microservice if your primary microservice requires it. Instead, use consistency to duplicate or propagate that data (just the properties you require) into the other service's database.
\nThe only data that changes over the course of a refurbishment is the state. For syncing the refurbishment state, we used asynchronous messaging. Every time the initial state of a refurbishment is changed, a message will be produced to SQS (Simple Queue Service). From there, we can easily consume that message and change the state in the new microservice.
\nTo provide a fast search, we added an index only to the state field, since too many composite indexes can have degradation on insertion, deletion, and updating performance. The Data Manipulation Language statement has to modify the table data and the indexed data too, which might decrease the performance depending on the amount of data. We have slow query alerts in place, so we get notified when it might be time for an investigation to improve the performance.
\nTech Decision 2: Event Sourcing the State Changes
\nEvent sourcing is a way for an event-driven microservice to respond to events in order to carry out its tasks. A higher-level operation is performed by a number of these services interacting with one another in an event-driven architecture based on messaging. The interaction usually consists of a series of messages taken by the various services to handle, for e.g. state changes.
\nMessaging at AUTO1 works in the following way. Every service that publishes messages must specify the SNS topic to which it intends to deliver those messages. Topics are bound by message type, so if the message type is Refurbishment.State then the topic is named Refurbishment_State. Messages are then routed to the subscribed SQS queues using topics that have been specified. These messages can be consumed by multiple consumers.
So to keep the state changes updated, we created a Message Listener that listens to state changes and updates the state. A message producer for the state changes was already in place since several other services needed to consume this message as well and make their own updates.
\nTech Decision 3: Implementing Feature Flags
\nFeature flags can be helpful in a variety of situations. It's essential to understand that feature flags can be used to configure a wide range of application components. Some feature flags are used to run specific parts of the application, and some feature flags intentionally prevent that. Additionally, feature flags may be applied to the frontend and/or backend. Enabling or disabling features for individual parts of an application is a common use case.
\nThe strategy we usually apply is to enable features for specific car repair workshops using a feature flag. That way, we can steadily monitor for errors and let the feature evolve so it is ready to be rolled out to all the other car repair workshops as well. For some features, it might be needed to backfill data to pre-existing entities to support the feature in earlier refurbishments.
\n4. Quality Assurance (QA)
\nQuality assurance is an essential part of software development and therefore should ideally take place not only at the end, but throughout the development process.
\nIf you want to create good software, you should include software tests in the development process from the very beginning. Here are three reasons for the need of good-quality testing:
\n- \n
- \n
A high-quality user experience is guaranteed by quality assurance
\n
\nSoftware quality issues have an impact on functionality and as a result the user experience. When it comes to developing good software, the user always comes first. Only this ensures that the product is of high quality. \n - \n
Quality assurance saves time and money
\n
\nThose who recognize quality assurance as an essential component of software development from the start save time and money. The later errors are discovered, the longer the development time and the higher the costs. \n - \n
More security is provided by quality assurance
\n
\nContinuous quality assurance throughout the development process ensures that security vulnerabilities are detected and addressed early on. \n
5. Monitoring
\nTo improve the quality of an application, you need monitoring. Application monitoring helps developers to locate bugs easier and speeds up the development time. If application monitoring is ignored, it could lead to unexpected crashes or poor performance that would cause significant harm to the company. It can enable engineers to gain insights into how their systems will behave.
\nThis information enables them to identify issues or flaws while they are still small enough to be handled with relative ease. At AUTO1 every new service has its own Grafana monitoring dashboard to provide several key metrics like:
\n- \n
- JVM Memory usage \n
- JVM Heap size usage \n
- ECS Container Memory usage \n
- Docker Container CPU usage \n
- Load Averages \n
- Garbage Collector Metrics \n
- Cache Metrics \n
- Thread Pool Metrics \n
- etc. \n
When a software-based company grows, it creates lots of new code, which means multiple engineers may be facing the same problems across the whole platform. They will usually come up with various solutions to fix it. Some of them might be generic and reusable, while others will be tailored to one’s needs. As it usually happens, the solutions will then be bundled together to create libraries. This is very good, up to a certain point, since over the years, engineers will create them by the dozens and this, in turn, will bring about other hurdles such as: This was quite a big pain point for AUTO1 software developers as we have 60+ common libraries that need to work perfectly in 600+ production services across multiple business units and products. One simple mistake, for example, a wrong configuration change leftover after a debug session can end up in disaster. Enabling protection against direct commits for main branches will address the first hurdle - only pull requests with double approvals and tested by CI can be merged. The next 2 issues are more about ease of usability for the developers, as they might be reluctant to upgrade their service if the process is troublesome. So, in the best-case scenario, our end-user should periodically update only a single property. In addition, our common library developers need to be able to easily publish their changes. The solution to it was the release trains, usually known as BOMs or for AUTO1 developers, service-commons-dependencies. After successful implementation, you will just need to trigger CI build to get the newly released version, which in turn can be pasted into a pom/gradle file. So, right now everything looks good, but can we be 100% sure that our changes are going to work? Perhaps there is a very small bug in a messaging lib or we will lose tracing for incidents. That’s unacceptable. So let’s ensure that will never happen by introducing automatic real use case testing. In our approach, we thought most of the problems could be revealed by running extensive integration testing. The test harness probably catches all bugs in our codebase and simply fails when needed preventing the release of a buggy version. But no matter what you do or how extensive your tests are, you are never going to be able to perfectly mock the production environment. Enter the End to End testing of newly released To get it done, we need CI pipelines that will automatically test our new versions of release trains that are triggered either manually or automatically every week. All tests need to be as close to the real-world scenarios as possible. A practical solution is to create a new service that will include all of the most popular use cases of the aforementioned libs. Then we need to deploy it to all of our environments - as previously mentioned there is always something different between local, QA, and production environments, so we need to cover them all. The tests must be the same for all environments. But the trigger may differ - for example, we are using our test environments to prepare new releases for production. The following diagram illustrates the basic principle of how it should work: In our implementation, we chose to use Jenkins with JobDSL pipelines and Groovy for scripting. The first stage of the E2E process is checking whether a new version of service-commons-dependencies exists by using the maven versions plugin: To check for any changes: If nothing new was found let’s just abort the pipeline and wait for another CRON or manual trigger.\nIn case a new release was found, we need to build it, deploy it, and run E2E tests.\nIf there are no failures the pipeline will create a new core-test-service release.\nFor those cases, we are using parameterized jobs, for example, to trigger the E2E tests we can use the following commands: The new release will be picked up by the production pipeline by checking the latest tag creation time in our repository: If the release of core-test-service was created within the last 2 hours we will deploy it by triggering another pipeline. As the last step, it will run E2E tests. As mentioned above, both testing environments will use a shared codebase for acceptance testing. It can be done by setting up one extra job that will fetch an external repository using this block: We chose Cucumber as our main test framework since it will give us unparalleled leverage compared to other choices. Tests are written using natural language in a way that allows for troubleshooting to be done basically at a glance. For example here is the scenario that tests the libraries responsible for sending messages in our platform exposed via HTTP endpoint: The above, combined with this generated report, is a joy to work with.\n Furthermore, we decided to create a dedicated slack channel to notify us about the new releases and test results. So after getting this message We can finally get our much-needed stress-free beauty sleep, not that it will help us much, right? Hopefully, this small article will get you in the mood for some nice automation work in your company. Have fun and enjoy your peaceful nights. Let's talk about harmony! If you have a look at an English dictionary, you'll see that even though almost everyone has some knowledge of the meaning of the word harmony, it's not so simple to properly define it. There are many contexts that it may apply, such as people relationships, business, law, and so on. But, at the end of the day, this concept imported from the music means that something happens in a way or frequency that makes it pleasant and less error-prone. So I want you to focus on the idea that the proper frequency is a way to achieve harmony. There are some cases where you would like to limit the frequency that something happens to it work properly. Imagine that you have a coffee machine, it's obvious that you would like it to dispense coffee at a frequency that you can replace the cups and be able to serve all your guests. It happens everywhere, even on software. At least while we have limited resources, we have to orchestrate them to work in harmony. One strategy is to use Rate Limiters, a maneuver to control the frequency in which some action is handled. A common pattern to achieve the Rate Limiter strategy is to use the Token Bucket algorithm. In a nutshell, the Token Bucket mimics a real bucket where Theme Park tickets are stored. To enter to play around at the Theme Park, you need to take a ticket. But if the bucket is empty, you have to wait until some new tickets are put in there. Doing like that, you become able to control the flow of people to the Theme Park by controlling the number of tickets that are put into the bucket and the time interval in which the refill occurs. If we put 10 tickets per minute on that bucket, it'll assure that at most 10 people will enter the Theme Park in each 1-minute interval. Libraries like Google Guava, Resilience4j, and Bucket4j are examples of how we can achieve rate-limiting in our Java software. Despite being a beta version by the time of this writing, using the Google Guava RateLimiter library is pretty straightforward. You create a RateLimiter object defining the number of permits per second and, for each task, you specify that it should \"acquire\" the token that allows it to proceed. For Resilience4J you need to create some configuration before and decorate your task: In the same path, now using Bucket4j, you need to specify the refill interval and the limit: But if you want that the employees from the theme park's main entrance do other tasks while the customers are in the queue and still not allowed to enter, I mean if you want that your thread is used for other tasks, at least these 3 libraries have a pattern that may be a problem to you: they block the thread. Now we are in the second part of this article, and as we are talking about Threads, it's good to know some basics about them. The first step is to know that they allow us to work concurrently, two tasks running virtually at the same time. But Threads are notoriously complex and error-prone, inaugurating a new sorts of problems like Deadlock, Race Condition, and so on. As we said at the start of this article, considering that we have limited resources, we have to use Threads with wisdom and be as clever as possible. If I and my wife are in the kitchen and we have just one knife available, it is appropriate that once one of us stop using the knife we leave it available to the other over the table, so that the other could start working with this piece of cutlery. When one forgets about this rule, the other one is kept waiting for the tool, and important work is not held, preventing the flow of a harmonious cuisine. The computer environment works like this kitchen, we have a limited number of Threads. And when something blocks one thread with a Thread.sleep() or LockSupport.parkNanos(), this Thread goes to the TIMED_WAITING state and during this time it can not be used. It is like the unused knife in the cooker's hand of an unharmonious kitchen. In practical terms, consider the following code: It will output as follow: What we wanted was that our 4 tasks were completed in a frequency of at most 2 for each second, but the Rate Limiter also has blocked the other tasks. You may ask, what to do? Perhaps, we should schedule instead of blocking! Imagine when you need to go to the doctor. Unless there is an emergency, you will likely have to make an appointment. The schedules are spread in a timeline, considering the doctor's ability to do the entire checkup: anamnesis, some additional exams, and so on. So to say, if the doctor takes an average of 30 minutes to attend to a patient appointment, those appointments should be guaranteed in intervals of 30 minutes. With this in mind, we could refactor our previous code. If we need that our tasks are executed at a rate of 2 per second, it means that we should schedule our tasks for every 500 milliseconds, which is one second (1000 milliseconds) divided by 2. Now that we know our interval, we have to find a way to keep track of our \"appointments\", to avoid scheduling more than one task to the same interval. Let's use an AtomicInteger class for that. Let's scratch some code: It will output as follows: Oh, it worked, but seems like we are cheating, because we just added a new thread to the game. How can we know for sure if that new thread is not being blocked? Well, we can test it like this: And voilà: The downside of this approach is that the ScheduledExecutorService, that we receive from the newSingleThreadScheduledExecutor() method of the Executors class, uses an unbounded queue. This means that no task will ever be rejected (by the meaning of the unbounded word, it is like an unlimited queue), and because of that, we have the risk of consuming too much memory if we receive tasks more quickly than we can handle them. Of course, we can avoid that in many ways. One approach could be to track the number of scheduled tasks and reject new tasks if we hit the specified threshold. First of all, let's refactor our code so that we use a queue of tasks as the source to be used by the scheduler. Our log: Now in this version, we are using the scheduleAtFixedRate() method, which frees us from keeping track of the already used intervals. It now checks for new tasks for every expected interval. But what would happen if we have more tasks coming than we are able to handle? The following code creates a new task for each 250ms but handles new tasks just in an interval of 500ms. Our output would be something like this: The size of the queue will not stop raising, leading us to an out-of-memory error. Oh, but don't be so afraid my friend, as we said we can limit the schedule based on that queue. Like if you call the doctor to make an appointment and they answer you: \"sorry, for the next 10 years all our schedules are already taken, please call in another day (or year).\" Our output: Here we have to talk about backpressure. Remember that this problem about memory only occurs if always the input of tasks is faster than the output. If the input of tasks was faster in just a point of time, this surplus of tasks will be kept on the queue and properly handled in the following time. So with this approach, our application could control the rate of events so that fast producers (sending new tasks) does not overwhelm our consumer. In a blocking approach, the producer will be forced to wait. In the scheduling approach, the new tasks will be handled in time, and only if it overloads that some of them will be queued. You could say, but how long should be my queue? Well, I may say that it depends on your use case. A doctor could have a schedule book for all the current year. And if it shows to be not enough, the doctor can buy a new schedule book for the next year. As in your application service, if you can afford more memory, your queues can be as long as you want. But in the case of a traveling circus, if it will be in the town for just 3 weeks it doesn't make sense to accept schedules for the next month. The same as your application, if its capacity of handling tasks isn't fast enough at a point that the handling of an older schedule task starts to become unmeaningful, you should shrink your queue. We can conclude that scheduling is a good approach for rate-limiting without the downside of blocking the thread. It gives us the opportunity of controlling the flow of incoming tasks, queueing peaks, and always handle the tasks in harmony with all other components. I don't have time for automation - how often do you say that? I said that once and now I feel a bit ashamed thinking about it. To never repeat this mistake I had to find some solution, to not only have enough time for automation but also to be much faster using it. I realized that when I was repeating the same test case manually for the 5th time, it was incredibly boring and each try was taking 15 minutes of my time. Today I would like to share my experience with you on how to make it faster and more pleasant. In the big picture, it is all about being agile, splitting the job between small pieces, done as fast as possible. Before the feature is fully ready for tests we have so many different opportunities to start working on automation. An hour of planning can save you 10 hours of doing - Dale Carnegie As soon as test scenarios are prepared, you can select candidates for automation and choose which ones should be executed on API level and which on UI. It should be a part of a well-prepared automation strategy (more about test automation strategy here https://auto1.tech/efficient-testing-1/ ). Check whether all necessary API calls are available for you (maybe you need to ask developers to create new endpoints?), what will be the steps to prepare the environment for the test, explore existing automation infrastructure and recognize how many new methods and classes you will need to prepare. Sometimes our features are settled on some other pages or we need to go through other features or applications to do our tests. As these parts already exist, it is a great time to cover it with automation if nobody hasn't done that before. It is also a great time to consider which tools will be needed and find new libraries that will be more effective. Test data means all that needs to be prepared before your real test will start. When you are sure that you know all the preconditions and steps required to arrange the system before beginning the testing, you can recognize how to prepare it just when the first version of the specification is written. For example, let's take an order in the shop. When developers write their code you can write your own which will prepare test data via API, so following our example the order in specified state. To make it more efficient you can store example of the order in the queue (read more about it here https://auto1.tech/faster-automation-tests/). It will be so helpful when you will need to execute the first most basic test and speeds up the whole process significantly. Developers in your team will be also very grateful for the created test data that they can take and quickly test their changes on. If you use Page Object Pattern you can create a page objects skeleton just now based on the design. Prepare all classes storing variables with empty locators, write all methods which will use these locators to interact on the page and prepare bigger steps that will do your manual work. When the front end part of the feature will be implemented you can just fill in locators one by one look at the DOM and adjust steps easily. With unique locators added by developers, it will be almost a pure pleasure. Let's take this design of the saved searches page as an example and imagine a test scenario that verifies that saved searches are displayed on the proper page and the user can use a saved search to view the current results of searching. We know that to be able to execute this scenario we need the signed-in user so we can prepare this user just now. Looking at this picture we already know that we have an upper menu that should be already covered with automation (if it isn't covered, the time to do it is just now) and we need to use it to open my account view. We have also a side menu to open the saved searches page from my account context. We know how the saved search will look and which button we will need to click to open search results. Having all this information we can prepare the saved search page class, empty locators for all elements and methods that will interact with the page. Many times I saw this approach to automation. I will do everything manually and leave the automation creation at the end or it doesn't make any sense to create automation now, because I will have to change it. Have you seen something similar? But how much time will be needed then to write all automated tests? Two weeks, or more? Who will give this time, when a new urgent feature is upcoming? From my perspective, it is really hard to find that person and it is well-argued. That's why in my humble opinion it is much better to split your time into small sessions before the feature is ready for tests and then have all automation components already done, then just write tests on demand. Isn't it beautiful having valuable tests from the start and be able to use them as regression tests at any time? I will give you my example: I was testing integration between two systems. Requirements were very agile, five teams were engaged in this feature and multiple layers of integration were created, so we had many bugs by the way. I had to repeat every test scenario 10 times on average. Manually test data preparation for each took 10 minutes, the real testing part between 5 and 10 minutes. After the third attempt, I was tired and frustrated. The more tired and frustrated I was - the more mistakes I made. It was a critical point for me to start writing automated tests. Of course, I had to spend a few hours to have it ready, but what a relief I felt when the 15 minutes scenario was done by my automation in 3 minutes. The other big benefit was that automation doesn't make mistakes and I could run my tests how many times I needed so I've stopped caring about the number of repetitions. I was able to share these tests with my colleague that needed them for testing the other part of this integration. My rough calculations show that I saved a few days and so many hairs which I would have ripped out of my head if I had to do all these tests manually to the end. When I was asked about regression I needed only a few minutes of my effort. We have so many opportunities to be well prepared for upcoming features and to reduce the effort needed in manual testing. Creating smart automation will develop our coding skills and help to save time and frustration. I am sure that there are many other ways to receive significant benefits by automating early, we just need to use them. If you are already familiar with MDC (Mapped Diagnostic Context) you can go to the next section of this article. If not, please take a look at this first to get a better understanding of what MDC is. In one of our services we had an endpoint responsible for invoking process related to car auction with a lot of logs for debugging purposes. We already had a request-id to trace it in Kibana, but we wanted to filter logs in a more convenient way, by value that we know even before invoking this endpoint which was the stock number of the car. So we decided to use MDC as it allows us to add diagnostic key-value pairs to every log in given Thread. Although MDC is a great tool, it forces programmers to write clunky code due to the fact that every key-value pair that was set should be cleared, otherwise in some edge cases it could be used by another thread. Clearing can be done by invoking MDC.clear() or by MDC.remove(key). First one clears all MDC keys so we could accidentally remove keys that were set higher in stack. Second one is better then but it has to be invoked for every key. And also in both cases it should be done in finally block to be sure that no matter what happened, context was cleared. MDC also has To stand against MDC drawbacks, we came up with this functional style solution: At first glance we can see that there is no Try Catch block anymore and we are only setting key-value pairs and not clearing them, however everything works exactly the same. So how is it done? Solution is pretty simple. It is based on a container class for storing MDC context keys mixed with Step Builder Pattern. Let's take a look at implementation. LogContextSteps is a wrapping class for two step interfaces: ContextStep which contains method for adding new log key-value pair ExecuteStep which also extends ContextStep and serves execute method responsible for invoking action that we want to wrap with MDC. implements interfaces from stores MDC keys in executes action that we want to wrap with MDC context For testing purposes there are some package protected classes and methods like So, how does this flow work? We begin with the static factory method MDC key is stored in Finally we can invoke Assuming that we have an ELK stack for monitoring and proper log configuration we can go to Kibana to find interesting logs via our MDC key-value pairs. Depending on the log configuration, key can be directly accessible or under the flat field (which was in our case) For key-value pair: stock-number - SN12356 Kibana filter may look like this: Hello everyone, my name is Ihor Sila and I'm a Senior Software Engineer in AUTO1, with over 6 years of developing experience. When I joined AUTO1, I received my laptop and I found out that it's a new MacBook Pro with M1 processor and I believe that's really great, because I've read a lot of articles about this chip's performance and comparisons with Intel i-core series. However when I've tried to build microservices that my team presented to me, I found some unusual situations with tests, which are working with embedded libraries such as redis and postgres. When I've run first time integration-tests that using embedded-postgres library, I've got next exception in stack trace: With the postgres problem, the solution was pretty simple and after I found it in our Slack channel I applied it and it solved the problem. So, when you are setting up your Mac, please check the environment variables and switch locale to en_US.UTF-8 from default one, because the embedded postgres library tries to start its library with a different locale and has problems with the process id. Another solution is to increase the size of a single shared memory segment a Linux process can allocate. So the commands in terminal will be the next And that you should restart your MacBook to apply all settings. After that the problem should gone. Moving on to redis, the problem was that it was newly added to AUTO1. So, from a code perspective everything is fine, but when you try to run the integration tests that are using embedded redis, they just won't be executed, because redis doesn't want to start. There is some exception log that you receive but that's about it, nothing special. When I've tried to debug the library code, it also appeared fine from a first look, but when I've debugged the stack trace of the startup, I've realized that this old version of redis doesn't know anything about the new M1 architecture and that macOS can be built on something different other than an Intel chip. Basically, old redis library only knows that macOS can be either x86 or x86_64. After a thorough investigation, I realized that there is no solution yet and repositories that provide embedded redis solutions haven't updated their libraries so far. The solution to this problem consists of two parts: To solve the first problem, I thought that I could just download the latest redis-server, then get the application file from the library folder and replace the old app file with the new one. Soon after the first try I've realized that my solution will work only for M1 chips, therefore no compatibility with the Intel chipped Macs. I've dived deeper into the redis library to understand how it knows which architecture (x86 or x86_64) it needs to use. The solution was pretty simple, it just executes the command to get system flags and then analyzes these flags to see which version to use. When I executed the same command on my local machine, I realized that on M1 architecture some new flags were added, which represents that the current architecture is written with a new chip. In embedded redis you can tell redis to use another embedded redis application, but not the solution from the library. If you execute next command at the terminal, you will found extra flags for AMD architecture: But if you will execute the same command on Intel-based architecture, you will see another flags, that are specific for Intel architecture: After realizing that, we created a class so that we can tell the library the fact that if the OS is macOS, then it needs to analyze the system flags. If it will find M1-specific flags (which are not present on Intel architecture), then use the latest redis application file which can be executed on macOS with M1(AMD) architecture, otherwise use the existing solution, because it's working on macOS with Intel processor. We also should store this application file in our resource folder, so in that case new developers can just download the source code and the redis application file will be already there. We've tested this approach on our microservices and it's stable. As for now, our core-team already replaced dependency from old embedded-redis to new one and it's working for both Intel and AMD architecture without additional changes. Thanks for reading! Test data management using SHIFT The test cases, scenarios, and strategies are maintained in SHIFT, our internal (and soon to be open-sourced) test case management system. Our QAs make use of a test data tool which is integrated to SHIFT. The 100+ types of test data required by the teams are generated using automation suites that run in Jenkins. This test data is then queued in SHIFT and as a result increased the productivity of our QA team by reducing the effort for manual test data creation. Our director of QA has briefed this here https://auto1.tech/faster-automation-tests/. Seamless Integrations Our CI system, Jenkins, is wired to run these tests against our various QA environments. The integration of SHIFT with Slack, Jenkins, and Jira has helped the teams immensely. The status of Jenkins jobs/sanity suites is notified in Slack. The time taken to debug the issue is hugely reduced since SHIFT displays a precise list of failed tests including the screenshot reference, which helps me to quickly understand the exact point of failure. Once I have identified the issue, I fix it and test it locally, then push the branch to our repository. The process is set in such a way that merge can be done only after review, which gives me more confidence and validation for the proposed solution. This helps me address the issues faster and get the system up and running. This is indeed why the QA team at AUTO1 is one of the key pillars of the Engineering team. My automation testing journey at AUTO1 could not have been this impactful if not for this perfect blend of the best tech stacks and resources, and most importantly, my amazing team. My learning on the job has been very effective and hands-on, and it makes each day filled with new challenges and new learning opportunities that help my work create a real impact. From the very many opportunities that came my way and the deep learning curve it has presented me with, I now realize that - the journey has just begun! The AUTO1 microservice landscape is growing in size day by day, with new services from a spectrum of languages being erected and usually communicating with each other by using REST contracts. In a fast paced environment, such as AUTO1, often the service providing the REST API and the service consuming this REST API are developed in parallel, by independent teams. On top of that the business requirements over the lifetime of a project evolve, thus impacting the stability of the API. Having these moving parts in picture can make the development process quite challenging, especially when aiming for high productivity, zero downtime and independent development of the client and server parts. Hence, having a clearly documented and language agnostic API is vital for the success of the whole process. After extensive research, we found a great candidate seemingly accommodating all the aforementioned requirements - OpenAPI. In short the OpenAPI specification defines a language agnostic standard allowing to describe REST APIs in a human readable form, imposing a unified structure, clearly and comprehensively aligning expectations between the consumer and provider sides. Below is an example of such an API described using the OpenAPI 3.0 standard: In general, we distinguish two approaches when developing APIs. The code first approach, which is basically about developing the source code fulfilling the business requirements and afterwards, optionally, generating the API specification from it, which for OpenAPI can be done using the swagger annotations. The second approach known as design first, is all about describing the API in a human readable language first, by using for example the OpenAPI specification, and then optionally, based on this artifact generating the source code for server and/or client. Naturally, both approaches come with pros and cons. As previously mentioned, in AUTO1 it often happens that changes that are being introduced in the API on the server side need to be implemented at more or less the same time on the client side. In such a situation, if the code first approach would be practiced, the consumers would need to wait for the server side implementation to be delivered before starting their part, that would be simply inefficient. Here, for the rescue comes the design first approach, where from the moment when the API specification is agreed upon, both server and consumer side can kick-off their side of the implementation, independently. Additionally, this allows to spot misalignments already at a very early stage, and rectify them before the actual implementation from either of the sides is started, hence less expensive to fix. The OpenAPI comes with a rich ecosystem, from UI tools such as Swagger UI allowing to visualize and test ad-hoc the specifications to AWS integration providing a fast lane to expose the specification via AWS API Gateway. Another very helpful set of tools are the code generators, that can generate client side libraries and server side stubs from the OpenAPI definitions. These extendible generators support a variety of languages and frameworks, which lets one move faster, especially in a polyglot microservice environment. For our Spring Java applications we have decided to go for a generator that is very well configurable and easily customizable. It can be executed in various ways such as via cli, maven/gradle plugin, etc. Since our Java projects use maven for the build automation process, the maven openapi generator plugin was the natural choice for us. Despite the vast configuration possibilities offered by the OpenAPI code generators, in order to integrate OpenAPI into our AUTO1 development world seamlessly and make the generated API and models classes adhere to our coding standards we needed to extend the default Spring generator that we’ve decided to go with in first place, to include some AUTO1 specific code structures. To be more productive, concise and spare some boilerplate code we use in AUTO1 the Lombok library, a lot, hence we couldn’t afford not having the Lombok annotations included in the generated classes as well. To follow the OpenAPI generator practices, we have added a configuration property to control enabling and disabling the usage of Lombok annotations: The above setting would result in generating the following annotations in the output classes: Sometimes the need arises to define custom annotations but only on some specific classes, for that purpose we have introduced a new attribute to our OpenAPI specifications called x-extra-annotation, that hints the generator to add additional annotations to the generated code. For example: The above attribute would result in generating the following annotations in the output classes: Generics is a very powerful feature that is available and widely used in the Java language for almost two decades now. Unfortunately, as of the time of writing of the article the OpenAPI does not support out of the box inheritance together with generics. To make it available to our developers we have introduced yet another attribute in the API specification named x-make-parent-generic specifying the genericType sub-attribute that indicates a generic type of the parent class (in this case PageDTO): The above attribute would result in generating the following generic parent in the output classes: As mentioned at the beginning of this article, our Java services are using the Spring Cloud stack with declarative Feign REST clients, originally the Spring Cloud Netflix Feign module was used for that purpose, however, with recent upgrades to newer Spring versions it was replaced by the Spring Cloud OpenFeign module that resulted in changes in the imported packages (import org.springframework.cloud.netflix.feign.* was replaced with import org.springframework.cloud.openfeign.*). So we ended up in a situation where services use either the old Feign clients (located in their respective packages) or the new ones, yet share the same OpenAPI specification. To support both cases we made it configurable for consumers to go with either one: Another shortcoming of the default OpenAPI Spring MVC generator was the lack of support for making the generated classes implement specific interfaces (using the “implements” keyword), as of version 4.3.1 only the “extends” keyword was supported. We have overcome this limitation by introducing a custom attribute x-codegen-implements allowing us to specify a number of interfaces the generated class should implement. The generated output for the above configuration can be found below: Teams often run into the situation where they have to use multiple OpenAPI specifications to generate the necessary contracts to communicate with the upstream services. Unfortunately, the org.openapitools:openapi-generator-maven-plugin requires a separate configuration for each specification, which was a bit too verbose and too cumbersome for us. In order to circumvent this issue we have created our own maven plugin The main aim of it was to reduce the boilerplate configuration, yet keep the flexibility of the original plugin: When dealing with a large number of microservices a common case is that they share common features, hence common models, within a single bounded context. In a typical Code First approach operating in the Java ecosystem this problem would be solved by sharing a common jar which would be then included by the interested parties. We were interested in achieving similar functionality but from the OpenAPI perspective. We achieved this by simply extracting part of the common functionality into separate specification files and referencing them from the individual OpenAPI specifications that would like to reuse these definitions. The challenge in having OpenAPI specifications referencing other OpenAPI specifications was the dependency management and versioning part. It was especially hard from the consumer perspective, since consumers would need to include both specifications in their respective versions (the referencing one and the referenced one) in order for the code generator to succeed. The solution for this was building API bundling, by adding to the specification a meta attribute called x-bundle-apis we could make all referenced definitions to be included in a single final artifact that was then uploaded in the CI pipeline to artifactory. This meant, from the consumer perspective, that they just needed to include a single dependency now, making their life significantly easier. By default, when bundling the API we’ve always included the latest referenced specification. Since we have had cases where we wanted to give more control to the API owners to specify which concrete version of a “common API” they would like to reference, we’ve included another attribute x-bundle-imports which could be used as following: Despite the vast number of improvements we have already made in order to retrofit OpenAPI and its tooling into our existing AUTO1 ecosystem and practices, there is still room for improvements. Just to name a few. Although OpenAPI specification itself is language agnostic, we have language specific generators which in some cases need to be instructed on how to generate the output code, and unfortunately these generator hints often make sense only in context of a specific language. As an example, instructing the generator to make the generated Java classes implement some specific java interface. Since the OpenAPI specifications are enriched directly with these hints, it results in obscuring and cluttering the contract definition. Yet another challenge would be to generate more complex classes resembling the structure as seen when written manually in the times from before the OpenAPI approach was adopted. As presented in the article, OpenAPI is a very powerful tool that enabled our AUTO1 organization to move forward faster in a more structured and unified way in terms of defining and evolving the REST APIs. It’s not a silver bullet, as the design first approach and the OpenAPI specification come with a number of challenges by themselves. However, with the talented engineering force we have we were able to resolve most of them in an efficient manner, yet every organization planning to adopt this tool needs to weigh in the benefits and the shortcomings and make the call for themselves. Hi everyone! This article is the first in a series of AUTO1 testing-related posts, I hope you’ll find the content interesting enough to return for the rest in the series :) To start off, let’s ask one of the most important questions: In AUTO1 the test strategy is a high level, short and concise document which defines: Scope of the testing Risks - areas that potentially can be broken Automation strategy Required test data Security In agile and fast changing environments we usually do not spend that much time on test documentation as in waterfall. However, even in such cases we cannot underestimate the importance of a test strategy. When you are creating a strategy it becomes your guide, a channel for your thoughts - you have a space to stop for a moment to try to understand what should be verified and do it at a very early stage. It is much easier to go back to the feature if you already wrote down your thoughts and you have some kind of summary. Let’s go through our thinking process, step by step. Start with defining what exactly has to be tested. You can ask yourself a few questions: Who is going to use the feature? What apps will be changed/created? On what devices will it be used? What types of testing will be needed? It allows you to better understand the product you are going to test and the environment setup you’ll need. Now think about all the things that can go wrong. Here the questions will be: What apps/areas can be impacted by our change? Are we modifying dependencies of another system? Is my domain knowledge enough to understand a feature? Are there any missing prerequisites which can block testing? Are changes going to be compatible with existing solutions? Answering these questions will help us create a plan in order to mitigate all risks. It can be planning an onboarding session with someone who has knowledge we need, investigating regression testing possibilities for apps or areas in danger or setting up a plan on how to get blockers done. Automation is an important part of our testing process. We think about the approach on the test strategy stage. We create our tests on an UI and API level. When we’ll have the technical specifications, which include details of implementation, then it is time to plan what and when will be automated. We ask questions such as: Where is the specific logic placed? Is it frontend or backend? Do we have existing automation in this area? If yes, do we have to adjust it? Do we have all prerequisites needed to start writing automation? At AUTO1 we have a lot of connections between several areas. It created dependencies which have to be covered in test data preparation. We have to be sure we know the preconditions and steps required to arrange the system before starting testing. Here we can specify if we need additional onboarding or support from other teams. Having answers to the above questions means we are prepared to plan more detailed test cases and we can use our strategy as some kind of a cheatsheet. However, do not blindly follow what you’ve planned - requirements can change. Review your strategy from time to time, to ensure that it is not outdated. Test strategy shouldn’t take much time but it is important for the next step - creating a test plan. It can be a great guide which will help you to structure your initial ideas and be prepared for upcoming changes faster. BACKGROUND This post is in addition to the previous article about plugin development but with a focus on UI based plugin implementations. Sometimes it can be really useful to have an UI and make it possible to interact with it by doing some checkboxes selections or maybe to have some input areas for text. Let's investigate how to develop a simple plugin with input text area as input entry point and some new generated classes, based on input text as a result. As a source code example we will have a look at source code based on my pet project that also was used as a development tool in AUTO1 to generate non GraphQl based POJO classes. USER STORY As an Android developer I need to interact with backend data. It can be usually presented as JSON data or if we can speak about new and modern practices it also can be presented as a GraphQl scheme. GraphQl is a really powerful framework with its own classes generation framework. But let's go back one step and imagine that we have to do some data presentation classes updated for the project without GraphQl support. To do it, we need to find the target class, compare its fields with new JSON fields and update it. It can be easy if we have only one field changed, but for multiple inner fields and classes with its own inner fields it can be too complicated. We can find some online services to convert JSON to POJO and copy/paste output files, but let's try to integrate this technology to our IDE! And our job will be only to copy/paste new JSON to some window input field! Like this one: To make it possible, let's think about our problem and try to do small decomposition into logical steps. Lets formulate our goals by imaging simple user stories: As a user I want to input JSON text into the input field. As a user I want to transform JSON text into POJO files. As a user I want to see the result notification. We will skip JSON to POJO transformation for this article, but we will learn how to develop a plugin with required user interface. Let's think about option number two as about some library that we already have and can use as a part of our small project. TECHNOLOGY STACK Before we will start let's have a look on basis plugin implementation. There are 2 base options to develop new plugin: We will speak about gradle implementation. Gradle is a really powerful framework and it can be really helpful if we want to simplify our building, releasing and testing. The project structure is a common structure for gradle based projects: Most important topic for us will be the plugin.xml file. We already discussed some details in the previous article and we can be focused on some UI related topics. During the plugin development we can use Java/Kotlin and all utility tools that we want like jUnit testing and dependency injection frameworks. In our current example Koin and JUnit can be found. So, now we have and know about project structure, some utility tools, language to write the code and now we are ready to think how it can be possible to create a user interface and connect it with our IDE. Let's remember about our major goals: GOAL 1 - As a user I want to input JSON text into the input field.\n and see how we can implement it. GOAL 1 First of all, let's learn how to connect our plugin with the IDE user interface. As we can see the IDE has a lot of action groups to do something (create new files for example). According to our idea to have some logic that can help us to convert JSON to POJO it would be great to have a new item in the new file list. It will be something like an action “Create new POJO file”. To connect our logic with the IDE by following this path we have to remember about the plugin.xml file that was discussed early. We can use this configuration file to describe our plugin and how it can be used. Let's find the actions section and define new action to show our input field dialog view. As we can see we can use some properties to describe how users will be available to interact with our plugin. We can define a custom icon for our action, define the position inside of the items list (“NewGroup” anchor “last”) and we can define the class to execute when action will be invoked by the user. Custom action class should extend the abstract AnAction class with the implementation of actionPerformed() method. Inside of actionPerformed() method implementation we can add the logic to show a dialog window with the input field for JSON text. To show dialog view we can easily use DialogBuilder from plugin development SDK and Java swing to create a user interface. More information about actions can be found on the official documentation page. GOAL 2 Let's imagine now that we already implemented logic to show the input text dialog with some selectable options to transform this text. We also added some logic of transformation - that can be some library to work with it or maybe our own implementation. And as the result of that transformation some new POJO files were generated added into our project (We can interact directly with the project or we can use project representation, provided by the plugin development SDK). But what about the next steps? We also need to notify the user about the result: it can be a success result notification, or maybe some error case notification. To implement it we can use default tools, provided by plugin development SDK. We can show some information to the user by using popup, notifications or messages. Let's imagine the following case: we have a text input field and we have some logic to convert/transform the text from this input field. If we can speak about JSON to POJO transformation, we have to understand that any random text cannot be converted to POJO correctly. Target text should satisfy some conditions and also should have the correct JSON structure and it means that we have to not only show some notification if text structure is not valid, but we have to block UI and break our transformation flow. Messages can really help us with it! According to the official documentation: The Messages class provides a way to show simple message boxes, input dialogs (modal dialogs with a text field), and chooser dialogs (modal dialogs with a combo box). The function of different methods of the class should be clear from their names. When running on macOS, the message boxes shown by the Messages class use the native UI. Lets see the following code: As we can see we can use the show dialog method, provided by SDK. We can define some dialog parameters, like title, message, button and of course we can define our custom plugin icon. If the image is not defined, standart Java icon or IDE icon would be shown. More information about images support can be found here. Also as it was already discussed here we can add support for internationalization instead of hardcoding only english string values. And as the result we can see this amazing small UI blocking window with our message text: It looks now that we found a solution to cover the error cases. Now we can prevent users from wrong input and show notification about it. Let's think about the success use case. Let's imagine that the input text was correct and we processed our JSON to POJO transformation as expected. Maybe some new files were generated, maybe it was only one new file. It will be a really good user experience if we can find a possibility to inform our users about it. Maybe one of the possible ways can be to show notification messages. It can be a small popup view with some text, like this one: and maybe we also can print some information to the event log: It looks now that we are ready to totally satisfy our user story requirements! Let's do the final steps and implement the following code: As we can see we can use the create notification method, provided by SDK. Unlike dialog related logic, we also have to define the project that we want to use to show the notification. As an example let's get only the first project (most popular use case), but we have to understand that users can open not only one project in the IDE and we have to take care about it too. So, as we can see it is also possible to define message text. Also we can define the message type (it can be INFORMATION, WARNING or ERROR) and we have to take care about the notification group that was defined inside of our plugin.xml file: FEW WORDS AT THE END As we can see it was not really a big deal to develop some small and hopefully useful tools for daily use or to help your teammates. The major idea is just to understand that integration with IDE can be really simple and when we will finish with it, we can be focused on the functionality of our tool. Perhaps in the future when we will have a stable version with some really cool features we can share our tool not only with teammates that we are working with directly, but maybe it also can be helpful for some developers from some random parts of the world. And maybe together we can simplify our daily job! Big organisations are hard to manage. Everyone knows that. It is even harder to manage if an organisation wants to keep innovating and remain profitable and functional. How do we do that without creating a lot of bureaucratic roadblocks and wrap every single decision in a web of workflows and processes? And what data do we need to know that we are moving in the right direction with the right speed? Can we get this data with the least effort possible? In this article, I would like to show AUTO1 Technology’s attempt to address these questions. With the original approach, we had a few issues on our hands. AUTO1 Technology split to 8 Business Units, each of them has its own set of functions, for example, under the Internal BU, we have DevOps, Design, Core etc. In total, we have 30+ functions and each of them has their roadmap to deliver. And, each team also will need to keep an eye on their technical debt. Every day in A1 Technology we plan new features, define the specs, test and do tens of releases to Production. Our roadmaps are living documents and change all the time as we need to react to market events or predict customers needs. We are a Product organisation, meaning that we split our teams into Product-oriented pods, where cross-functional engineers paired with a Product Manager and a QA. Sometimes, depending on the type of feature, they are joined by a Designer. Historically, to keep the roadmaps up to date, PMs needed to maintain headcounts in a Google Sheet. Consider this scenario - a PM knows that FE engineer John Doe works on a Feature A and their QA Jane Doe works on a Feature B. They update the spreadsheet and then find out that the TL switch Jane to a Feature B 5 mins ago. Now, multiplying this scenario to 30, we will see that the final allocations were not always actual, softly speaking. We could resolve it by telling our engineers to log their time somewhere, and they will need to log every hour of their workday. This way we would see them go to another company very shortly. Engineers like to do what they were trained for and not fill up neverending timesheets. And let’s not forget about the PMs, who were people chasers instead of being a customer/revenue/idea chasers. Finally, they spent too much time on getting these numbers instead of focusing on their daily tasks. Looking at the above issue we can also clearly see another one. To manage all of that we use Google spreadsheet UI and it has its limitations: It’s very easy to accidentally remove a value from a cell and don’t even notice it. Which happened a few times... There are no backups and it's very hard to restore some of the values there. The history of updates is hidden and it's not always working as we need to. The purpose of the spreadsheet is to be... well, a spreadsheet - to calculate something to present some existing data in a table view. This doesn’t work well for our use case. Managing pipelines is much more complex tasks that requires a lot more to it - see the next section. Google spreadsheet also doesn’t allow to track the feature lifecycle very well and validate if some steps were missed. NB: The above sentence is not 100% true. But it would require a lot of complex configuration and a lot of maintenance time to implement such functionality there. Which won’t make it a very robust solution. Our process is quite flexible and depends on the type of the feature and the Business unit but in general consist of some common steps: Requirements gathering Writing the specs Getting signoffs from the SHs Demoing the increment to them etc. Using just the spreadsheet functionality it’s very easy to miss some of them accidentally or to take some shortcuts intentionally. There is no easy way to validate whether all the important steps were taken. Some of our features require designs or mobile app counterpart development. How can we track it more efficiently? In the original approach, we would need to manually duplicate records from the BU’s pipeline to a corresponding Design and Mobile team pipelines. There was no easy way to automate it. So, how one would go about managing all these features across the Tech organisation? To help us with that we came up with TechOS, an AUTO1 Technology Operating System, the tool that would help us with all of that. TechOS designed to tackle the issues above. It allowed us to: Get up-to-date data on our Engineers allocations Free up our PMs from a burden of chasing people Introduce some insurance in a form of backups and changelogs Add a feature lifecycle validation to all the items on the roadmap Automate some of the tasks and jobs Get this data - after all, we are a data-driven company - that we need to back-up our decisions, like: What are the late features?\nWhich of our MVPs were too long and too costly?\nDo we maintain a 1 to 3 ratio of QAs and Devs that we claim we do? PMs create tasks in the UI that we built in house. All our engineers receive a notification that reminds them to submit an update for today. This action only takes up to 30 seconds and it can be done from a mobile phone. We only ask them to choose a task that they were working today from the list of tasks. They choose a task as Primary or Secondary (non-mandatory) and hit submit. We don’t ask about comments or any notes. We don’t ask about the exact time they spent on it. No. Just two dropdowns, one of them is not required at all. We don’t use these updates to measure employees performance. They are only used to know the allocations for the task: On the screenshot above we see a pipeline view with some key data about the Roadmap item and the number of people who are working on these tasks. The decimal numbers are there because we show a weekly average. The best thing about TechOS is its data and how it can be used. With people linked to tasks, we can have very powerful reports that can give us insights into how we work and what needs to change. Here are a few examples. We have a textual or a visual representation of how our PMs, Devs and QA are allocated on the task This report shows us how much effort is spent in different areas of the task: in planning, writing specs, development etc. The above two reports combined are a powerful tool and enable us to be agile and adapt rapidly. No more accidental deletes of data in cells Permissions that allow different access to different areas of the roadmap A lot of flexibility configuring tasks workflows. A bit more on that below: On the diagram above you can see an example of how we can configure a life cycle of a task. Something that wasn’t available to us before. Automation - now we can automatically create tasks in corresponding pipelines if a checkbox was ticked. I.e. if someone creates a feature that requires the Design team’s effort, they can just choose the “Design” checkbox and a corresponding task will be created in the Design team pipeline. In order to scale up our CI/CD build platform running with Jenkins[1], we used to leverage the AWS Elastic FileSystem, also known as EFS, to provide a network filesystem that can be mounted across one or more VM instances. This deployment setup works well with a containerised workload as the orchestrator can schedule the container or virtually any node on the cluster, therefore we need to make sure the storage is available for every instance where the build platform will be deployed. We accomplished this by simply attaching the EFS storage in all nodes on the cluster, thus allowing the container to be rescheduled in any instance at any time. However, we started to face some challenges with the increase of new services and the introduction of features such as Jenkins Pipeline and Multibranch Pipelines. We noticed that the system build queue was growing bigger over time, as our build system was taking longer to process the services pipelines, with a direct impact on the development time and life cycle. In our investigation and analysis we identified the storage file system as one of the biggest contributors to the performance of the Jenkins Master node. We tested and decided to migrate the Jenkins filesystem to another storage type - AWS Elastic Block Store service, also known as EBS, that provided better performance in our tests compared to the EFS file system. The Jenkins Home directory will often be composed of lots of small to medium size files, which can be troublesome when operating in a network file system due to the overhead required to send the file operations over the network. Moving Jenkins to a faster storage system can lead to a great performance impact on the overall build platform. The downside of running the platform on AWS EBS is that we degraded the high availability of the platform as EBS is limited to a single Availability Zone (actually, one of the reasons why the storage is faster), leading to an adjustment to the service deployment, ensuring it’s deployed on the same AWS availability zone and introducing new plugins that will integrate the container system with EBS. The new adjustments also introduce more complexity to the infrastructure. Nevertheless, we decided that improving the performance of the system will bring more value to the development side and consequently could have a positive impact on the business. Most of the performance gain is bound to the Jenkins Master itself, as only the master was using the EFS storage and the Jenkins Build Nodes were already using EBS or instance local storage. Nevertheless, there could still be improvements as the Jenkins Master was responding faster even when when communicating with the build nodes. After the migration to EBS we started to see an improvement on the Jenkins Master Build Queue. In the following graph, we can see the number of builds queued to be processed. The bigger the queue, the longer the waiting time for the new jobs to start the services pipelines build and deployments. On the other hand, with the EBS storage, the build dropped to 4 seconds as shown on the image below: We calculated a simple estimation and we expected an impact of 2 hours on engineering - based on the time Jenkins takes to process the pipeline and start the builds, and the time it takes to scan a multibranch pipeline. This estimation does not account for indirect performance gains such as navigating into Jenkins UI, like when waiting on Jenkins to render the build’s output. [1] Multibranch Pipeline job is processed by cloning down the GitHub repository, scanning on the branches looking for a Jenkinsfile into the project root directory and creating or starting a build on the given branch when a new branch is created or the branch received any git changes. Hello, colleagues, friends, readers and all of you excellent people out there! It's been a while, right? Let's pick up where we left off... Our second Tech Talk took place in February at Maze, an event space fashioned after the Berliner spirit. Antonella and Alexander attracted almost 100 people with their promise of delivering amazing content, while having two different tracks allowed for the exposure of the participants to other vital parts of a tech start-up/unicorn. This event, the second in a series of events meant to promote local growth and accelerated learning, is now available for everyone to enjoy, on Youtube, along with the slides from the presentations. Antonella Zagaria - Localisation in an ever-growing startup\n\n Alexander Gyulai - SHIFT your testing gear\n\n \n
\nservice-commons-dependencies, more commonly known in AUTO1 from here on out, “E2E testing”.mvn -U versions:update-property -Dproperty='service-commons-dependencies.version'def hasChanges = sh(returnStatus: true, script: \"git diff --exit-code\")build(job: 'java/core-svc/core_test_end_to_end_test', parameters: [booleanParam(name: 'SEND_SLACK_NOTIFICATION', value: \"true\"), string(name: 'RELEASE_TRAIN_VERSION', value: service_commons_dependencies_version)])String latestTagDateString = sh(returnStdout: true, script: \"git rev-list -1 \\$(git describe --abbrev=0 --tags) --pretty=oneline --format=%ci | awk 'NR%2==0'\")\n\ndef proceedWithE2ETesting = wasTagReleasedRecently(latestTagDateString)\n\n@NonCPS\n\n def wasTagReleasedRecently(String lastTagDateString) {\n\n def formatter = DateTimeFormatter.ofPattern(\"yyyy-MM-dd HH:mm:ss Z\")\n\n def lastTagDateTime = OffsetDateTime.parse(lastTagDateString.trim(), formatter)\n\n def currentTimeMinus2hours = OffsetDateTime.now().minus(2, ChronoUnit.HOURS)\n\n return lastTagDateTime.isAfter(currentTimeMinus2hours)\n\n}definition {\n cpsScm {\n scm {\n git {\n remote {\n github(\"core-e2e-tests\", 'ssh')\n credentials(\"token\")\n branch(\"master\")\n }\n extensions {\n wipeOutWorkspace()\n }\n }\n }\n\n scriptPath(\"jenkins/core_e2e_tests.gvy\")\n }\n}Scenario: Should have a working API endpoint for creating a message\n\nGiven an object with generated id and message: This is a test\nWhen making a POST call on messaging endpoint with the body containing the given object in JSON representation\nThen should result in a 201 response status code\nAnd should receive an empty bodySanity checks for new release train X.Y.Z on env:\n\n * REST API simple entity integration ✅\n * REST API dated entity integration ✅\n * REST API auditable entity integration\n * Messaging integration ✅\n * Messaging FIFO integration ✅\n * Storage integration ✅\n * Health integration ✅\n * Metrics integration ✅\n * Logging integration ✅Rate Limiters
\nfinal RateLimiter rateLimiter = RateLimiter.create(2.0); // rate is \"2 permits per second\"\n void submitTasks(List<Runnable> tasks, Executor executor) {\n for (Runnable task : tasks) {\n rateLimiter.acquire(); // may wait\n executor.execute(task);\n }\n} // Create a custom RateLimiter configuration\nRateLimiterConfig config = RateLimiterConfig.custom()\n .timeoutDuration(Duration.ofMillis(100))\n .limitRefreshPeriod(Duration.ofSeconds(1))\n .limitForPeriod(2)\n .build();\n// Create a RateLimiter\nRateLimiter rateLimiter = RateLimiter.of(**\"backendName\"**, config);\n\n// Decorate your call to BackendService.doSomething()\nSupplier<String> restrictedSupplier = RateLimiter\n .decorateSupplier(rateLimiter, backendService::doSomething);\n\n// First call is successful\nTry<String> firstTry = Try.ofSupplier(restrictedSupplier);\nassertThat(firstTry.isSuccess()).isTrue();Refill refill = Refill.intervally(2, Duration.ofSeconds(1));\nBandwidth limit = Bandwidth.classic(2, refill);\nBucket bucket = Bucket4j.builder()\n .addLimit(limit)\n .build();\n\nif (bucket.tryConsume(1)) {\n executor.execute(task);\n}Thread Blocking
\nprivate void guavaRateLimiter() {\nRateLimiter rateLimiter = RateLimiter.create(2);\nlogWithThreadTimeStamped(\"Starting\");\n\nIntStream.rangeClosed(1, 4).forEach(i -> {\n rateLimiter.acquire();\n logWithThreadTimeStamped(\"Task n. \" + i);\n});\n\nlogWithThreadTimeStamped(\"I'm blocked =(\");\nlogWithThreadTimeStamped(\"Finishing\");\n\n}[12:01:31.972073] Starting Thread: main\n[12:01:31.978520] Task n. 1 Thread: main\n[12:01:32.471752] Task n. 2 Thread: main\n[12:01:32.967231] Task n. 3 Thread: main\n[12:01:33.470331] Task n. 4 Thread: main\n[12:01:33.470662] I'm blocked =( Thread: main\n[12:01:33.470845] Finishing Thread: mainScheduling
\nprivate void taskScheduling() {\nvar scheduleExecutor = Executors.newSingleThreadScheduledExecutor();\nvar intervalDiary = new AtomicInteger();\nvar expectedInterval = 500;\nlogWithThread(\"Starting\");\n\nIntStream.rangeClosed(1, 4).forEach(i -> {\n scheduleExecutor.schedule(\n () -> logWithThread(\"Task n. \" + i),\n intervalDiary.getAndAdd(expectedInterval), TimeUnit.MILLISECONDS\n );\n});\n\nlogWithThread(\"I'm NOT blocked =D\");\nlogWithThread(\"Finishing\");\n}\n\nprivate void logWithThread(String message) {\n System.out.println(message + \" Thread: \" + Thread.currentThread().getName());\n}Starting - Thread: main\nI'm NOT blocked =D Thread: main\nFinishing - Thread: main\nTask n. 1 - Thread: pool-1-thread-1\nTask n. 2 - Thread: pool-1-thread-1\nTask n. 3 - Thread: pool-1-thread-1\nTask n. 4 - Thread: pool-1-thread-1private void taskSchedulingV2() {\nvar scheduleExecutor = Executors.newSingleThreadScheduledExecutor();\nvar intervalDiary = new AtomicInteger();\nvar expectedInterval = 500;\nscheduleExecutor.execute(() -> logWithThread(\"Starting\"));\n\nIntStream.rangeClosed(1, 4).forEach(i -> {\n scheduleExecutor.schedule(\n () -> logWithThread(\"Task n. \" + i),\n intervalDiary.getAndAdd(expectedInterval), TimeUnit.MILLISECONDS\n );\n});\n\nscheduleExecutor.execute(() -> logWithThread(\"I'm NOT blocked =D\"));\nscheduleExecutor.execute(() -> logWithThread(\"Finishing\"));\n}Starting Thread: pool-1-thread-1\nTask n. 1 Thread: pool-1-thread-1\nI'm NOT blocked =D Thread: pool-1-thread-1\nFinishing Thread: pool-1-thread-1\nTask n. 2 Thread: pool-1-thread-1\nTask n. 3 Thread: pool-1-thread-1\nTask n. 4 Thread: pool-1-thread-1private void taskSchedulingV3() {\nvar scheduleExecutor = Executors.newSingleThreadScheduledExecutor();\nvar myTasks = new ConcurrentLinkedQueue<Runnable>();\nvar EXPECTED_INTERVAL = 500;\nscheduleExecutor.execute(() -> logWithThread(\"Starting\"));\n\nscheduleExecutor.scheduleAtFixedRate(() ->\n ofNullable(myTasks.poll()).ifPresent(Runnable::run),\n 0, EXPECTED_INTERVAL, TimeUnit.MILLISECONDS\n);\n\nIntStream.rangeClosed(1, 4).forEach(i ->\n myTasks.add(() -> logWithThread(\"Task n.\" + i))\n);\n\nscheduleExecutor.execute(() -> logWithThread(\"I'm NOT blocked =D\"));\nscheduleExecutor.execute(() -> logWithThread(\"Finishing\"));\n}Starting Thread: pool-1-thread-1\nTask n.1 Thread: pool-1-thread-1\nI'm NOT blocked =D Thread: pool-1-thread-1\nFinishing Thread: pool-1-thread-1\nTask n.2 Thread: pool-1-thread-1\nTask n.3 Thread: pool-1-thread-1\nTask n.4 Thread: pool-1-thread-1private void taskSchedulingOverload() {\nvar scheduleExecutor = Executors.newSingleThreadScheduledExecutor();\nvar myTasks = new ConcurrentLinkedQueue<Runnable>();\nvar EXPECTED_INTERVAL = 500;\nvar SMALLER_INTERVAL = 250;\nscheduleExecutor.execute(() -> logWithThread(\"Starting\"));\n\nscheduleExecutor.scheduleAtFixedRate(() ->\n ofNullable(myTasks.poll()).ifPresent(Runnable::run),\n 0, EXPECTED_INTERVAL, TimeUnit.MILLISECONDS\n);\n\n\nscheduleExecutor.scheduleAtFixedRate(() ->\n myTasks.add(() -> logWithThread(\"Fast Task! Task lasting: \" + myTasks.size())),\n 0, SMALLER_INTERVAL, TimeUnit.MILLISECONDS\n);\n\n\nscheduleExecutor.execute(() -> logWithThread(\"I'm NOT blocked =D\"));\nscheduleExecutor.execute(() -> logWithThread(\"Finishing\"));\n}Starting Thread: pool-1-thread-1\nI'm NOT blocked =D Thread: pool-1-thread-1\nFinishing Thread: pool-1-thread-1\nFast Task! Task lasting: 1 Thread: pool-1-thread-1\nFast Task! Task lasting: 2 Thread: pool-1-thread-1\nFast Task! Task lasting: 3 Thread: pool-1-thread-1\nFast Task! Task lasting: 4 Thread: pool-1-thread-1\nFast Task! Task lasting: 5 Thread: pool-1-thread-1\nFast Task! Task lasting: 6 Thread: pool-1-thread-1\nFast Task! Task lasting: 7 Thread: pool-1-thread-1\nFast Task! Task lasting: 8 Thread: pool-1-thread-1\nFast Task! Task lasting: 9 Thread: pool-1-thread-1\n\n(...)private void taskSchedulingLimitingByQueueSize() {\nvar scheduleExecutor = Executors.newSingleThreadScheduledExecutor();\nvar myTasks = new ConcurrentLinkedQueue<Runnable>();\nvar EXPECTED_INTERVAL = 500;\nvar SMALLER_INTERVAL = 250;\nvar QUEUE_LIMIT = 4;\nscheduleExecutor.execute(() -> logWithThread(\"Starting\"));\n\nscheduleExecutor.scheduleAtFixedRate(() ->\n ofNullable(myTasks.poll()).ifPresent(Runnable::run),\n 0, EXPECTED_INTERVAL, TimeUnit.MILLISECONDS\n);\n\n\nscheduleExecutor.scheduleAtFixedRate(() -> {\n if (myTasks.size() < QUEUE_LIMIT)\n myTasks.add(() -> logWithThread(\"Fast Task! Task lasting: \" + myTasks.size()));\n else\n logWithThread(\"I was rejected =(\");\n },\n 0, SMALLER_INTERVAL, TimeUnit.MILLISECONDS\n);\n\nscheduleExecutor.execute(() -> logWithThread(\"I'm NOT blocked =D\"));\nscheduleExecutor.execute(() -> logWithThread(\"Finishing\"));\n}Starting Thread: pool-1-thread-1\nI'm NOT blocked =D Thread: pool-1-thread-1\nFinishing Thread: pool-1-thread-1\nFast Task! Task lasting: 1 Thread: pool-1-thread-1\nFast Task! Task lasting: 2 Thread: pool-1-thread-1\nFast Task! Task lasting: 3 Thread: pool-1-thread-1\nI was rejected =( Thread: pool-1-thread-1\nFast Task! Task lasting: 3 Thread: pool-1-thread-1\nI was rejected =( Thread: pool-1-thread-1\nFast Task! Task lasting: 3 Thread: pool-1-thread-1\nI was rejected =( Thread: pool-1-thread-1\nFast Task! Task lasting: 3 Thread: pool-1-thread-1Conclusion
\nEfficient Testing - Automate Early
\nPlanning and reconnaissance
\nTest data preparation
\nPage Object skeletons
\n![](\"https://i.postimg.cc/tXm79NqD/image.png\")
Doubts?
\nIn real life
\nConclusion
\nLogging with MDC in functional style
\nIntroduction
\nUse case
\nMDC code drawbacks
\ntry {\n MDC.put(\"key1\", \"value1\");\n MDC.put(\"key1\", \"value2\");\n //some process\n log.info(\"very important log\");\n}finally {\n MDC.remove(\"key1\");\n MDC.remove(\"key2\");\n}method putCloseable(key, value) which returns AutoClosable object but it allows only one key-value pair and has to be assigned to a variable, which may look better for a single key but it is not perfect. IDE will complain about never used variabletry (MDC.MDCCloseable closeable = MDC.putCloseable(\"key\", \"value\")) {\n //some process\n log.info(\"very important log\");\n}Solution
\nLogContext.withLogKey(\"key1\", \"value1\")\n .andKey(\"key2\", \"value2\")\n .andKey(\"key3\", \"value3\")\n .execute(() -> {\n // some process\n log.info(\"very important log\");\n });LogContextSteps
\n@NoArgsConstructor(access = AccessLevel.PRIVATE)\npublic final class LogContextSteps {\n\n public interface ContextStep {\n ExecuteStep andKey(final String key, final Object value);\n }\n\n public interface ExecuteStep extends ContextStep {\n\n <T> T execute(final Supplier<T> action);\n\n default void execute(final Runnable action) {\n if (action == null) {\n throw new IllegalArgumentException(\"Action for execution cannot be null.\");\n }\n\n execute(() -> {\n action.run();\n return null;\n });\n }\n }\n}\n
\nLogContext
\npublic class LogContext implements ContextStep, ExecuteStep {\n private static final MDCLogContextSetter MDC_LOG_CONTEXT_SETTER = new MDCLogContextSetter();\n\n private final LogContextSetter contextSetter;\n private final Set<String> contextKeys = new HashSet<>();\n\n private LogContext(final LogContextSetter contextSetter) {\n this.contextSetter = contextSetter;\n }\n\n public static ExecuteStep withLogKey(String key, Object value) {\n return withContextSetter(MDC_LOG_CONTEXT_SETTER).andKey(key,value);\n }\n\n static ExecuteStep withContextSetter(LogContextSetter contextSetter){\n return new LogContext(contextSetter);\n }\n\n @Override\n public ExecuteStep andKey(String key, Object value) {\n contextSetter.put(key, value);\n contextKeys.add(key);\n return this;\n }\n\n @Override\n public <T> T execute(final Supplier<T> action) {\n if (action == null) {\n throw new IllegalArgumentException(\"Action for execution cannot be null.\");\n }\n\n try {\n return action.get();\n } finally {\n contextKeys.forEach(contextSetter::remove);\n }\n }\n\n interface LogContextSetter {\n\n void remove(final String key);\n\n void put(final String key, final Object value);\n }\n\n private static class MDCLogContextSetter implements LogContextSetter {\n\n @Override\n public void remove(String key) {\n MDC.remove(key);\n }\n\n @Override\n public void put(String key, Object value) {\n MDC.put(key, Objects.toString(value));\n }\n }\n}LogContext is our main class here. It:\n
\nLogContextStepsSetLogContextSetter interface and its implementation MDCLogContextSetter, as it would be hard to test static methods of MDC class.LogContext.withLogKey(\"key1\", \"value1\") which sets up our MDCLogContextSetter and invokes the andKey(\"key2\", \"value2\") method for the first time. Then we can chain next invocations of andKey where every invocation causes two things:\n
\nSet<String> contextKeys as only keys are needed to clear contextLogContextSetter::put method is invoked where implementation is: MDC.put(key, Objects.toString(value)) and at that moment key-value is stored in MDCexecute(() -> action()) which is classic try-finally block where try invokes our action and finally clears MDC iterating every through contextKeys and invoking LogContextSetter::remove where implementation id MDC.remove(key)Practical usage (filtering in Kibana)
\nMacBook with ARM chip and embedded-libraries problems
\nEmbedded-postgres problems
\nProblem
\n Factory method 'postgres' threw exception; nested exception is\n java.lang.IllegalStateException: Process\n [/var/folders/61/ls8bv20x4w3fsn3wpm8dlpfm0000gp/T/embedded-pg/\n PG-0c0585587b40695247cf72650cd42f92/bin/initdbSolution
\nsudo sysctl kern.sysv.shmmax=104857600\nsudo sysctl kern.sysv.shmall=25600\nsudo sysctl kern.sysv.shmmin=1\nsudo sysctl kern.sysv.shmmni=10240\nsudo sysctl kern.sysv.shmseg=4096\n\nexport LC_NUMERIC=en_US.UTF-8\nexport LC_MONETARY=en_US.UTF-8\nexport LC_TIME=en_US.UTF-8\nexport LC_ALL=en_US.UTF-8\nexport LC_COLLATE=en_US.UTF-8\nexport LC_MESSAGES=en_US.UTF-8\nexport LC_CTYPE=en_US.UTF-8\nexport LANG=en_US.UTF-8Embedded-redis problems
\nProblem
\njava.lang.RuntimeException: Can't start redis server. Check\nlogs for details.\n\nat\nredis.embedded.AbstractRedisInstance.awaitRedisServerReady\n(AbstractRedisInstance.java:61)\nat\nredis.embedded.AbstractRedisInstance.start\n(AbstractRedisInstance.java:39)\nat redis.embedded.RedisServer.start(RedisServer.java:9)\nat\nwkda.common.distributed.cache.redis.EmbeddedSingleRedisServer\n.before(EmbeddedSingleRedisServer.java:48)\nat org.springframework.test.context.junit4.SpringJUnit4ClassRunner\n.run(SpringJUnit4ClassRunner.java:190)Deep diving into problem
\n=== REDIS BUG REPORT START: Cut & paste starting from here ===\n30203:M 15 Feb 14:01:14.039 # Redis 3.2.4 crashed by signal: 10\n30203:M 15 Feb 14:01:14.040 # Crashed running the instuction\nat: 0x7fff20406440\n30203:M 15 Feb 14:01:14.040 # Accessing address: 0x305685000\n30203:M 15 Feb 14:01:14.040 # Failed assertion: <no\nassertion failed> (<no file>:0)\n\n------ STACK TRACE ------\nEIP:\n0 libsystem_platform.dylib 0x00007fff20406440\n_platform_memset$VARIANT$Rosetta + 108\n\nBacktrace:\n0 redis-server.app 0x0000000100a70a7e logStackTrace + 110\n1 redis-server.app 0x0000000100a70e4d sigsegvHandler + 253\n2 libsystem_platform.dylib 0x00007fff20403d7d _sigtramp + 29\n3 ??? 0x00000001091c1200 0x0 + 4447801856\n4 ??? 0x31207070612e7265 0x0 + 3539952935082291813Solution
\n\n
\nsysctl -a | grep hw.optional\n\n------- Result -------\n\nhw.optional.amx_version: 2\nhw.optional.arm64: 1\nhw.optional.armv8_1_atomics: 1\nhw.optional.armv8_2_fhm: 1\nhw.optional.armv8_2_sha3: 1\nhw.optional.armv8_2_sha512: 1\nhw.optional.armv8_crc32: 1\nhw.optional.breakpoint: 6\nhw.optional.floatingpoint: 1\nhw.optional.neon: 1\nhw.optional.neon_fp16: 1\nhw.optional.neon_hpfp: 1\nhw.optional.ucnormal_mem: 1\nhw.optional.watchpoint: 4sysctl -a | grep hw.optional\nhw.optional.floatingpoint: 1\nhw.optional.mmx: 1\nhw.optional.sse: 1\nhw.optional.sse2: 1\nhw.optional.sse3: 1\nhw.optional.supplementalsse3: 1\nhw.optional.sse4_1: 1\nhw.optional.sse4_2: 1\nhw.optional.x86_64: 1\nhw.optional.aes: 1\nhw.optional.avx1_0: 1\nhw.optional.rdrand: 1\nhw.optional.f16c: 1\nhw.optional.enfstrg: 1\nhw.optional.fma: 1\nhw.optional.avx2_0: 1\nhw.optional.bmi1: 1\nhw.optional.bmi2: 1\nhw.optional.rtm: 0\nhw.optional.hle: 0\nhw.optional.adx: 1\nhw.optional.mpx: 0\nhw.optional.sgx: 0\nhw.optional.avx512f: 0\nhw.optional.avx512cd: 0\nhw.optional.avx512dq: 0\nhw.optional.avx512bw: 0\nhw.optional.avx512vl: 0\nhw.optional.avx512ifma: 0\nhw.optional.avx512vbmi: 0protected void before() {\nRedisExecProvider provider = RedisExecProvider.defaultProvider()\n.override(OS.UNIX, \"redis-server/redis-server\")\n.override(OS.WINDOWS, Architecture.x86,\n\"redis-server/redis-server.exe\")\n.override(OS.WINDOWS, Architecture.x86_64,\n\"redis-server/redis-server.exe\")\n.override(OS.MAC_OS_X, Architecture.x86,\n\"redis-server/redis-server.app\")\n.override(OS.MAC_OS_X, Architecture.x86_64,\ngetRedisServerForAppleArchitecture());\n\n\nthis.redisServer = RedisServer.builder()\n.redisExecProvider(provider)\n.port(redisPort)\n.setting(\"bind \" + this.redisHost)\n.build();\n\nthis.redisServer.start();\nlog.info(\"Started Redis server at [{}:{}]\",\nthis.redisHost, this.redisPort);\n}\n\n\nprivate String getRedisServerForAppleArchitecture()\nthrows Exception {\nProcess process = Runtime.getRuntime().exec(\"sysctl hw\");\ntry (BufferedReader input = new BufferedReader(new\nInputStreamReader(process.getInputStream()))) {\nString line;\nwhile((line = input.readLine()) != null) {\nif (line.contains(\"hw.optional.arm64\") &&\nline.trim().endsWith(\"1\")) {\nreturn \"redis-server/amd64/redis-server.app\";\n}\n}\n} catch (IOException e) {\nlog.error(\"Error during parsing system process\");\nthrow new RuntimeException(e);\n}\nreturn \"redis-server/redis-server.app\";\n}The OpenAPI journey
\nThe situation
\nThe light at the end of the tunnel
\nDesign first, code later
\nThe ecosystem
\nRetrofitting OpenAPI
\nChallenges ahead
\nThe verdict
\nWhat is a Test Strategy?
\n\n
\nWhy do we create a Test Strategy?
\nHow do we create a Test Strategy?
\nScope of the testing
\n\n
\nRisks
\n\n
\nAutomation strategy
\n\n
\nRequired test data
\nSummary
\n\n
\nmy_gradle_plugin\n\n├── build.gradle\n\n├── gradle\n\n│ └── wrapper\n\n│ ├── gradle-wrapper.jar\n\n│ └── gradle-wrapper.properties\n\n├── gradlew\n\n├── gradlew.bat\n\n├── settings.gradle\n\n└── src\n\n├── main\n\n│ ├── java\n\n│ └── resources\n\n│ └── META-INF\n\n│ └── plugin.xml\n\n└── test\n\n├── java\n\n└── resources\n\n
\nGOAL 2 - As a user I want to see the result notification.\n<actions>\n\n<action id=\"GeneratePOJOAction\" class=\"GeneratePOJOAction\"\n\nicon=\"/icons/pojo.png\"\n\ntext=\"Generate POJO from JSON\"\n\ndescription=\"GeneratePOJOAction\">\n\n<add-to-group group-id=\"NewGroup\" anchor=\"last\"/>\n\n</action>\n\n</actions>import com.intellij.openapi.actionSystem.AnAction\n\nimport com.intellij.openapi.actionSystem.AnActionEvent\n\nclass GeneratePOJOAction : AnAction() {\n\noverride fun actionPerformed(e: AnActionEvent) { \n\n//TODO: Add your UI implementation here \n\n} \n}companion object {\n\nprivate const val BUTTON_TITLE = \"OK\"\n\nprivate const val DEFAULT_OPTION_INDEX = -1\n\nprivate val DEFAULT_ICON = null\n\n}\n\nfun onPluginExceptionHandled(exception: RoboPluginException) {\n\nMessages.showDialog(\n\nexception.message, exception.title,\n\narrayOf(BUTTON_TITLE),\n\nDEFAULT_OPTION_INDEX,\n\nDEFAULT_ICON\n\n)\n\n}12:00 Response.java was updated.\n \n12:00 POJO generation: Successcompanion object{\n\nprivate const val MESSAGE_SUCCESS = \"POJO generation: Success\"\n\nprivate const val GROUP_ID = \"RoboPOJO Generator\"\n\n}\n\nfun showSuccessMessage() {\n\nshowMessage(\n\nproject = ProjectManager.getInstance().openProjects.first(),\n\nmessage = MESSAGE_SUCCESS,\n\ntype = NotificationType.INFORMATION,\n\n)\n\n}\n\nprivate fun showMessage(\n\nmessage: String, type: NotificationType, project: Project\n\n) = NotificationGroupManager.getInstance()\n\n.getNotificationGroup(GROUP_ID)\n\n.createNotification(message, type)\n\n.notify(project)\n\n <extensions defaultExtensionNs=\"com.intellij\">\n\n<notificationGroup id=\"RoboPOJO Generator\"\n\ndisplayType=\"BALLOON\"\n\nkey=\"com.robohorse.robopojogenerator\"/>\n\n</extensions>The problems
\nHeadcount allocation
\nGoogle spreadsheet UI
\n\n
\nWorkflow process
\n\n
\nLack of automation
\nThe answer
\n\n
\n\n
\nHow it works
\nSo, how does it help us?
\nTech allocation
\n![](\"https://lh4.googleusercontent.com/EZIHgD1u6-uVAG_c0AW2Y4QEf6Hia0Wt1Y4QMRaOc5y31Qb1Qg2M6JuWvnwZwTBh1OoIzJ-7BhLJMF0hjRM767YP405F25mx0KF3k6OH2EOJzeKl_0TeKQIlOQDVo61qUjL9M7qD\")
Days invested
\nA few more benefits
\n\n
\n\n
\n\n
","fields":{"slug":"/TechOS/","tags":["auto1","engineering","projectmanagement"]}}},{"node":{"id":"dc3aa441-f1ec-5a7d-b881-e2c93b86ddfd","frontmatter":{"category":"DevOps","title":"Improving our CI/CD system performance with storage migration","date":"2020-09-21","summary":"Leveraging AWS Elastic Block Store for improved performance and faster build times.","thumbnail":null,"authorName":"Rafael Silva","authorDescription":"Rafael is a DevOps Engineer at AUTO1 Group.","authorAvatar":{"relativePath":"pages/storage-system-improvements/avatar.png","childImageSharp":{"resolutions":{"base64":"data:image/jpeg;base64,/9j/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhCY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2P/wgARCAAUABQDASIAAhEBAxEB/8QAGAABAAMBAAAAAAAAAAAAAAAAAAMEBQb/xAAVAQEBAAAAAAAAAAAAAAAAAAAAAf/aAAwDAQACEAMQAAAB0IK9eXdVyc/CGqD/xAAcEAACAwADAQAAAAAAAAAAAAABAgADEgQREyL/2gAIAQEAAQUCY9LSxJl92J7ZCPtLT9zjk4//xAAUEQEAAAAAAAAAAAAAAAAAAAAg/9oACAEDAQE/AR//xAAUEQEAAAAAAAAAAAAAAAAAAAAg/9oACAECAQE/AR//xAAcEAEAAQQDAAAAAAAAAAAAAAABAAIQESExQYH/2gAIAQEABj8CcczatsU9waXcGNvZ/8QAHBABAAMAAgMAAAAAAAAAAAAAAQARMRAhQVFh/9oACAEBAAE/IWXgdTa57OHBUur8SwRbZ9x2IyIB0x//2gAMAwEAAgADAAAAECAnvv/EABYRAQEBAAAAAAAAAAAAAAAAAAERIP/aAAgBAwEBPxAkcf/EABQRAQAAAAAAAAAAAAAAAAAAACD/2gAIAQIBAT8QH//EAB0QAQACAQUBAAAAAAAAAAAAAAEAESExQVFxgaH/2gAIAQEAAT8Qrrsti8xYDhdIOK+y5TBSrKnUFnZQl1zfsIcLGBs7kuV0QImCShbHhP/Z","width":50,"height":50,"src":"/static/2eae20fca46dd64af3b25077e9ded172/45876/avatar.png","srcSet":"/static/2eae20fca46dd64af3b25077e9ded172/45876/avatar.png 1x,\n/static/2eae20fca46dd64af3b25077e9ded172/eb85b/avatar.png 1.5x,\n/static/2eae20fca46dd64af3b25077e9ded172/4f71c/avatar.png 2x,\n/static/2eae20fca46dd64af3b25077e9ded172/9ec3e/avatar.png 3x"}}},"headerImage":null},"html":"Improving our CI/CD system performance with storage migration
\nPerformance improvements with EBS
\nReferences
\n
![](\"https://lh6.googleusercontent.com/-K5rLPtggaNeQpml856NbA9UyUU6_scnBUgUE_W-RA7MVORz_dYAzrQ_jg7a9vBfQJHqmdosoCH7Evd0dbTF8-kzH0dlygQPeoqQu47__E5Pky0GmeyhlcJ1UWNuQrC7j5s3MZvQhj_EoSgwBA\")
![](\"https://lh5.googleusercontent.com/qyj0MbKLCEPO9M3Q8kalZoXkgfgcxddnmxk6lYUu0DrbBHhT747lCyy1SFhZDHKZXOGwUqcnsDFDPM2_rWAhnWC5l5m58RVcpsWWrBmwHIZgd3tKxSmhC6aqZHsB016Z7MXAhT0EX7mnT_N3_w\")
![](\"https://lh6.googleusercontent.com/F4M8xRSQWe86JzTN8G5uPIc62Y_uNhPB-_YDLlhHtTpy0PseDIX7fb8_jh37YbpVQEIJiy4gE76vP0eqkU5jjHKOeac5h3tprc52Iz2oQvv0Ros5AHC00DqsW_YZ6H_hXWdJ0yPe6evaU3Ir7Q\")
![](\"https://lh3.googleusercontent.com/yvtgM7DEm071JAOlv7stZjfjb3j31gbUhlMFH7mdXrls0TMaBG7FlV8kU6hgo99AGZ6LxotbaGzkZjbD6EiYfjqhj2j4uEQmR3n0qE6rwFl0XbPOfVgpcMabcdn4Zvh-pQH8jOt9\")
![](\"https://lh6.googleusercontent.com/Cr_GOw3whsmE5QUmFqElFtGzwUYhAudHXrkpI5BBwgWSgsD6DI1C1IDgO9ImhQTXjaBbd13IUntuxNY7wRBvBw1wGpYl7rl5bfk39ICXz8e_vMFnghBi530Oou9unORSShG7dJ9f\")
![](\"https://lh3.googleusercontent.com/mQt3PeJM0OMd1UkEF_iYvz6LSyr7BWbafyqyjxHPaVyYfebMBD00VXmIM8R_acox5DKYEN4OAc-LRRu8feSl6ERgKxwYJGHIPAg1U7zUzYvmj6s-SSnA4DTT2ENnXvPiV_xA40GQ\")
![](\"https://lh6.googleusercontent.com/KyLHXVRSIowTRybMH7hAOgiCvdzGqNBqg57UYB9lQ4K-zskAPsVG_e7hoKVAaM3qJ4F3Xh8Yshx65yCF0e_n3LyM2AZ5MyPBnLuZFdyDfg-5JDRF9-24zXMSQyRrBel70VoGJJW7\")
![](\"https://lh5.googleusercontent.com/ET-G6wXxbo6O1YniBzp4lRQU6D7DAo9WPn0ugiHifyGVV3-E6KV3Gf-ETvwYYnE3MlTeQlIkPp3EtxxL8BSB-vgVjn0-34UBUE2C2_y_lCKLtgWQHdhEWAmQDOHqQX-BDZPYwpE8\")
As always, sign up on our community page on Meetup.com to stay up to date and be amongst the first to find out when our next event is going to be. And it might be sooner than you think ;)
","fields":{"slug":"/QA-meets-Product-Tech-Talk/","tags":["auto1","engineering","social","tech talks","product"]}}},{"node":{"id":"f3a0fb4b-eb2f-5624-a408-d63e3cee5184","frontmatter":{"category":"Coding","title":"Spring batch integration","date":"2020-02-07","summary":"Usage cases for spring-batch.","thumbnail":null,"authorName":"Artur Yolchyan","authorDescription":"Artur is a Senior Software Engineer at AUTO1 Group.","authorAvatar":{"relativePath":"pages/spring-batch-integration/avatar.png","childImageSharp":{"resolutions":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAIAAAAC64paAAAACXBIWXMAAAsSAAALEgHS3X78AAAEfElEQVQ4yz2O2VMbBQDGlzJQSylXIEc3F0eODYGEJAQI5GBzbK49kt0cm703CSRQqfQCB9taap1qgY61VXqoPZxxbKe2dWo7tY6d0RdHX/0HfPLRF991qTPO/OZ7+33fB+RDFjruKMWhcgwqwnYqaiVhKwXbiolRgZiuVxJ1LrsgEg25sFilFqrFBblQFXNVgajyBMCkxiuIs4yMMoiDSTiwoC3kc/hdVpdVPzFqRua9MpupS7mqmK9LVF0u1CVFzssCIXMYwKZcTGpMyWLUOe2yjoxAQyNO1YCutbV9f1tbe1u7dcRY47GaMiXuVVSFvMTjModLLApwaRefHqeibqNm4EBnb/+A1mo2T9kHcZ9tGR5LQocPvdFmNusEOqv8lPicxBESi4kstifzabeMuj1Wnba7i/Q71vDgJ/Xc4zXhyWrxq1pyG/eWvEMd+9umfWMLAiFWshKD/g8goROV5LjdBJa9ls9r2edr4svTjRenG8836o9WK7e46EXM5zbpNGoVX0qKdEqk00qFgkBnAGrOko+Nz1jA94iZhyvFZ8fZ707JLzaWft48/vJ08/6b5Y+K4azHph5QlbCIXE7yJYRXco8U4Ffvn7ZoAiPgRSp8vU59s9Z89s7RJ2fXtxerbxGpo5nIOWxaCLr1BhOZDUqlOF+ICyVEQSwnAcuBFmtHi8ekRT0OMjBZQyI3lvgduVCLzvGx0HJi9nw+WPTbJ4dNdSLMUTBXiAnF+GsSgKN7n62zxWnQVAIuOjCxEJnaxuevleMfkMjJzPxGcuZTPs4FoA0U3uHIIhHkqKgCr1CIAx6wBeptTY3ZTiRnzmPhbTp9gyFuc+hNBnm6Kj48tXy1Ri7Brs8WxTMVvITN8fkIT8I8GRXIKFCAR11g1wSo3WSIb9dXbojEnUb1C5m5XkJ+ePvI4/WVHSm3BE98SKNCZpbBg6xyntzz92QxN+U39XYBQDMdfbTWvCpiF/Kpyyy1Wy/fapS+XC5tcclq0JGdMOViHhYP/Sdzyn5+HuBR3+xwXwcABG1DNxvkOgqfLxR3q4vvoujFQvzeSuGymKV8w5C+m4p7GTTIYEE2F+b2iABcZnLW2tsNAPrOg5f4zJVyYgfH7vHibY76epm8eyR/BpuU0inPNBFwW6RcSPGVfQYPcbl5gM14Ex69/gDQvW8f7rHuyujtGnm3yT84Id45Sp8lw0dwZHPrqX0s3N/Xnwl56UyAI0KvCQN02lOIOcfV7erWFvBgOwwZj+VSm0LleDlfR+aOsfSDV3+yS1udHV2aAZNaBQ4aByddTjQ6VcGCAJv1wX472K9S96gOHeyZmkHoWJiJ+Jsxz9ax1Ve//33p3k86tVmnM2s0JgWtdlCrHdKDw5AVAoio+7DW2NOj6+lRazQj71/99crayY8b+P3rd3/5459Hv/017o7otENGo82gt5jNo0rq9cMGg0UPWoBZj7O3Dxzo1/f1alyT6OL645Xm2cvXflw+93Rz93tx6YJaZRocHDMYIKMRAg9bQHDYZIIMBrvZ7PwXcPlkRtKKCQsAAAAASUVORK5CYII=","width":50,"height":50,"src":"/static/dc9516b9327e627890a1f5c7f84c004a/45876/avatar.png","srcSet":"/static/dc9516b9327e627890a1f5c7f84c004a/45876/avatar.png 1x,\n/static/dc9516b9327e627890a1f5c7f84c004a/eb85b/avatar.png 1.5x,\n/static/dc9516b9327e627890a1f5c7f84c004a/4f71c/avatar.png 2x,\n/static/dc9516b9327e627890a1f5c7f84c004a/9ec3e/avatar.png 3x"}}},"headerImage":null},"html":"Intro
\nIn this article, we will take a look at spring-batch and how it could be used. We will walk through various configurations and we will create an application which reads from a CSV file & writes into a database with outstanding performance.
\nI used the following: Java 11, Spring 5+, Spring Boot 2 and Maven-based project.
\nCreate a Project
\nFirst, we need to create a Spring Boot 2 project. We recommend that you do so by visiting spring initializer, which is a useful tool to generate spring projects with required dependencies and configurations.
\nDependencies
\nWe need the dependencies below to run and test the project:
\n<dependency> \n <groupId>org.springframework.boot</groupId>\n <artifactId>spring-boot-starter</artifactId>\n</dependency>\n \n<dependency>\n <groupId>org.springframework.boot</groupId>\n <artifactId>spring-boot-starter-test</artifactId>\n <scope>test</scope>\n <exclusions>\n <exclusion>\n <groupId>org.junit.vintage</groupId>\n <artifactId>junit-vintage-engine</artifactId>\n </exclusion>\n </exclusions>\n</dependency>\n\n<dependency>\n <groupId>org.springframework.boot</groupId>\n <artifactId>spring-boot-starter-batch</artifactId>\n</dependency>\n\n<dependency>\n <groupId>org.springframework.boot</groupId>\n <artifactId>spring-boot-starter-data-jpa</artifactId>\n</dependency> \n\n<dependency>\n <groupId>org.projectlombok</groupId>\n <artifactId>lombok</artifactId>\n <version>1.18.10</version>\n <scope>provided</scope>\n</dependency>\n\n<dependency>\n <groupId>com.h2database</groupId>\n <artifactId>h2</artifactId>\n</dependency>\n \n<dependency>\n <groupId>org.springframework.boot</groupId>\n <artifactId>spring-boot-starter-test</artifactId>\n <scope>test</scope>\n <exclusions>\n <exclusion>\n <groupId>org.junit.vintage</groupId>\n <artifactId>junit-vintage-engine</artifactId>\n </exclusion>\n </exclusions>\n</dependency>\n\n<dependency>\n <groupId>org.springframework.batch</groupId>\n <artifactId>spring-batch-test</artifactId>\n <scope>test</scope>\n</dependency>\n\n<dependency>\n <groupId>org.hamcrest</groupId>\n <artifactId>hamcrest-all</artifactId>\n <version>1.3</version>\n <scope>test</scope>\n</dependency>spring-boot-starter-batch dependency includes all the configurations to run the spring batch application. Lombok is just a helper dependency to write the code faster and cleaner. H2 is used as an in-memory database. spring-boot-starter-test and spring-batch-test are included for test purposes.
\nBook Class
\nLet’s create a model class book, which will represent a book. This will just serve as a model class and will help us during implementation of spring batch.
\n@Data\n\npublic class Book {\nprivate String title;\nprivate String description;\nprivate String author;\n}Configuration
\nLet’s create a class called SpringBatchConfiguration. We will add all required configurations here. First, let’s annotate this class with @Configuration to be able to inject beans, and with @EnableBatchProcessing to enable spring batch processing. Additionally, we can add @RequiredArgsConstructor from Lombok which would help us to generate constructor with parameters. These parameters are the ones which are marked as final class properties. These properties will be injected as spring beans. Our class will be like this:
\n@Configuration\n@EnableBatchProcessing\n@RequiredArgsConstructor\npublic class SpringBatchConfigurationNow, in SpringBatchConfiguration class let’s add properties which need to be injected into the constructor:
\nprivate final JobBuilderFactory jobBuilderFactory;\nprivate final StepBuilderFactory stepBuilderFactory;jobBuilderFactory and stepBuilderFactory are declared in spring batch jar as spring beans so that we can inject them in any class we want.
\nFile Reader
\nNow, we need to declare and initialize spring beans to configure the batch process. The first bean which we will need will be responsible for reading from a file line by line. Spring Batch provides a default class for it. The class name is FlatFileItemReader. Similarly, spring has different default reader classes for reading from a relational database, mongodb and etc. However, if you need, you can create your own reader and implement it in a way you want.
\nLet’s now see what FlatFileItemReader injection will look like.
\n@Bean\n@StepScope\npublic FlatFileItemReader<Book> bookReader(@Value(\"#{jobParameters['filePath']}\") final String filePath\n) {\nreturn new FlatFileItemReaderBuilder<Book>()\n .name(\"personItemReader\")\n .resource(new ClassPathResource(filePath))\n .delimited()\n .names(new String[]{\"title\", \"description\", \"author\"})\n .fieldSetMapper(new BeanWrapperFieldSetMapper<Book>() {{\n setTargetType(Book.class);\n }})\n .build();\n}We are configuring that the bean reader should read data from the given file path, which should be a CSV file having rows with title, description and author respectively.
\nThe StepScope means to initialize this bean after each step, so file path could be dynamically set when the spring batch job is launched. We will come to that later, how to pass the file path later in this article.
\nItem Writer
\nNow, let’s create a writer class, which will take the data and write into the relational database.
\n@Bean\npublic JdbcBatchItemWriter<Book> writer(final DataSource dataSource) {\n return new JdbcBatchItemWriterBuilder<Book>()\n .itemPreparedStatementSetter((book, preparedStatement) -> {\n preparedStatement.setString(1, book.getTitle());\n preparedStatement.setString(2, book.getDescription());\n preparedStatement.setString(3, book.getAuthor());\n })\n .sql(\"INSERT INTO books (title, description, author) VALUES (title, description, author_surname)\")\n .dataSource(dataSource)\n .build();\n} In the writer bean, we are setting item processors and adding values inside preparedStatement accordingly, which book property should be inserted for each db table column.
\nStep Configuration
\nNow, let’s configure a step which will be executed in the batch process. In our case, the configuration will look like this:
\n@Bean\npublic Step step1(final ItemWriter<Book> writer, final ItemReader<Book> reader) {\n return stepBuilderFactory.get(\"step1\")\n .<Book, Book> chunk(100)\n .reader(reader)\n .processor((ItemProcessor<Book, Book>) book -> book)\n .writer(writer)\n .build();\n}In our scenario, we have only one step, but it's also possible to configure multiple steps. Here, we are creating a spring batch step with the name step1 and setting reader and writer accordingly. These are the readers and writers which we created as spring beans earlier.
\nWe are setting chunk as 100, which means the items chunk proceeded is 100. We can make this configurable too. The processor is for converting the current object to the one which the writer should proceed with. In our case, it is the same object.
\nJob Configuration
\nLast but not least, let’s configure the job which should be executed.
\n@Bean\npublic Job importUserJob(final Step step1) {\n return jobBuilderFactory.get(\"bookReaderJob\")\n .incrementer(new RunIdIncrementer())\n .flow(step1)\n .end()\n .build();\n}Here, we create a job with the name bookReaderJob. We add an incrementer RunIdIncrementer, which is an id generator for the tables which are specifically designed to store the details about job executions in the database. After each time the spring batch job is executed, it will save details about the execution. To check the schema structure for storing this data, take a look at this sql. It is for MySql, but other SQL scripts are available too.
\nAdditionally, we add flow by which the job should be executed. Currently, we have only one step in our flow, so we add it.
\nPlease also add this config: spring.batch.job.enabled=false in your properties config file so that spring batch job won’t be executed automatically with no parameters when the application is started.
Execution
\nTo execute the job, we need to declare JobLauncher and launch the job. To do so, we need to create the below class:
\n@Component\n@RequiredArgsConstructor\npublic class SpringBatchExecutor { \n private final JobLauncher jobLauncher;\n private final Job job; \n\n @SneakyThrows\n public void execute(final String filePath) {\n JobParameters parameters = new JobParametersBuilder()\n .addString(\"filePath\", filePath)\n .toJobParameters(); \n jobLauncher.run(job, parameters);\n } \n}Now, we can call the execute method from whenever we want, with the file path from which the data should be read.
\nAdditional Classes
\nThere are a few additional classes which you will need to execute your code.
\nCreate a class BookEntity so that spring data JPA will automatically create the book table for you. Then you can create repository.
\n@Data\n@Entity\n@Table(name = \"books\")\npublic class BookEntity {\n @Id\n @GeneratedValue(strategy = GenerationType.IDENTITY)\n private Long id;\n private String title;\n private String description;\n private String authorFullName;\n}Then create the interface BookRepository and extend it from JpaRepository. At the moment, we will need this only for testing.
\n@Repository\npublic interface BookRepository extends JpaRepository<BookEntity, Long> {\n} Testing
\nNo one likes a code which is not tested. So, let’s write a few test cases for our class.
\nHere is a code sample for test cases:
\n@Slf4j\n\n@SpringBootTest\nclass SpringBatchSampleApplicationIntegrationTest {\n\n @Autowired\n private SpringBatchExecutor springBatchExecutor;\n \n @Autowired\n private BookRepository bookRepository;\n\n @Test\n public void testExecution() {\n long initialCount = bookRepository.count();\n assertThat(initialCount, equalTo(0L));\n springBatchExecutor.execute(\"sample-data.csv\");\n long count = bookRepository.count();\n assertThat(count, equalTo(7L));\n } \n\n @Test\n public void testLargeData() {\n long startTime = System.currentTimeMillis();\n long initialCount = bookRepository.count();\n assertThat(initialCount, equalTo(0L));\n springBatchExecutor.execute(\"large-data.csv\");\n long count = bookRepository.count();\n assertThat(count, equalTo(60000L));\n long endTime = System.currentTimeMillis();\n log.info(\"executed in miles: {}\", endTime - startTime);\n }\n}The second test executes in ≈ 3500 ms in a machine with a 2.2 Ghz Intel Core i7 and 16GB ram. It proceeds 60K lines of CSV file, and saves it into a relational database.
\nYou can check out the working sample code in github,
","fields":{"slug":"/spring-batch-integration/","tags":["auto1","engineering","spring","code","java"]}}},{"node":{"id":"2bf7354b-946c-5b99-826e-3c9ebed6b92c","frontmatter":{"category":"Social","title":"How to build a data-driven unicorn - Niv Liran","date":"2020-01-23","summary":"Watch the full video of the first AUTO1 Group Tech Talk, featuring CPO Niv Liran.","thumbnail":null,"authorName":"Alex Stoicescu","authorDescription":"Alex is Tech Community Manager at AUTO1 Group.","authorAvatar":{"relativePath":"pages/how-to-build-a-data-driven-unicorn-with-niv-liran/avatar.png","childImageSharp":{"resolutions":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAACXBIWXMAAAsSAAALEgHS3X78AAACyElEQVQ4y4VUO2gUURR9mZmN8YcItoKVjeXuzsxu9jOzm92NkBBTqDEmjZAEgtqIpSgI1gp+uhS6kEI7wc7GQsFCLERiISGCaGHhF02yu+M5s/cujyC4cJY379573r3n3XdNvV51xsYiJ4rKbqlUyBj8wjAYyWazp4BVYB3YAraBDeAhMBcE/l76lkrFTLVachuNyCGXEbJMrVbx6ADnaWAtn88nvu8nWBMdQcJ9Auv3wCxjWq2aC9IMSF3DzCyyG1YAs9pSYkL2melmLpfT71tKGkUlz2iZJAuCgA5dEjGAwPoV0AbuAy+tfR7YkZjb5CiXR1OutEw5jWQdCfgCnEiSxNg/7LWAj+KTSiHSzBvrAtascrriPCmnDkP4AYQ0Em3TGPHf8P38ARpP/4PsHQ7aU69Hqdi4OJeI47JXLg9IX1tVbUuWCzSsygcJO+L0goGNRpySoB1colarerhEvcCn4tuxCB/TsC5ZdS3Ct2Ho75uZmRoigWbIbgCxt7Q0O8TLsgg17o2R2+JHzzJcV/1IoBlybel42SLsCcc3I6UqoaZ+lUHFYjjCzJSQa+4J4UVLKiX8ScOGVXJXDN+xd7SfZXFYS65U+n2Wz+cOw+ezHadSkfCRdVJiZdlmMG9ZtHMpgWR3Z0eMSvWExjmrbXoCbZ951dIim7Yk6u1IYtlwavChW51Pp01tXOwf01eC9RHs/Rbbnx2Hf4IUh/Q5zdol8H3KG22Pj9edOK54LF1876pd37TELhqdZ+J4MwxDHUvXgDOFQrB7YqLpjI4WdhG8GLYNbCeBK/1+TWNWRG+Pfy5Hj5Dek3IXzX9+8DkL/AIeLC/PDU1NHXdSQk5altNsDkjPAT+ArzKyFnK5bB2IxbYik4hanmfM5GTL6Q/Y2DUc25y0HLToubR8TI39cL4APJOxr/35AXgOXEJnHKQvepP6eiQj119kDrZjqLo8HAAAAABJRU5ErkJggg==","width":50,"height":50,"src":"/static/26a7a327ccc4b335712e5a7086f2b26d/45876/avatar.png","srcSet":"/static/26a7a327ccc4b335712e5a7086f2b26d/45876/avatar.png 1x,\n/static/26a7a327ccc4b335712e5a7086f2b26d/eb85b/avatar.png 1.5x,\n/static/26a7a327ccc4b335712e5a7086f2b26d/4f71c/avatar.png 2x,\n/static/26a7a327ccc4b335712e5a7086f2b26d/9ec3e/avatar.png 3x"}}},"headerImage":null},"html":"Back in November 2019, we had the pleasure of hearing from our Chief Product Officer, Niv Liran, about the makings of a data-driven unicorn. This event, the first in a series of events meant to promote local growth and accelerated learning, is now available as a video, along with the slides from the presentation.
\n\n