In this interview we speak with Daniel Deichfuß, a Frontend Engineer who joined Delivery Hero 1.5 years ago as a Working Student. He shares his journey from Working Student to Mentor and his learnings along the way.

Hey Daniel, when did you decide to pursue a career in tech and what inspired you to do so?

If you asked me what I wanted to do when I finished school, I never would have told you I wanted to become an engineer, not in a million years! Music was my only passion. I studied musicology and toured Europe with my band. Later I worked for a record label in Berlin. Around that time, I slowly started gaining more and more interest in programming, specifically in web development, since it was something that was very useful to me as a musician. My best friend, who also happened to be the singer in my band, was a freelance Web Developer/Designer for many years and played a very important role in me pursuing a career as an Engineer.

Why did you decide to work for foodora/Delivery Hero?

During my time at the record label, I realised more and more that I really loved programming and everything that surrounded it. To top that off, my career in the music industry wasn’t going anywhere ;). As a result, I decided to get a second bachelor’s degree in Computer Science & Media at the Beuth University in Berlin. Though I believe you don’t need a degree to become a good developer, I do believe it was the right decision for me at the time. It helped me to find my passion in this huge field and to better understand the bigger picture.

As it turned out, my studies also somehow lead me to Delivery Hero. One of my classmates was working here. When the time came for me to leave the music industry for good, I began looking for contacts. He was the first person that popped into my mind. I felt quite insecure about my abilities at the time and was intimidated by all the job requirements in the job ads. Moreover, I couldn’t find many entry level positions that I could pursue while finishing my studies. As you can imagine, I was extremely grateful to have someone on the inside who could give me advice and guidance through this stressful time. He was also the one who got me my interview with Delivery Hero…and the rest is history!

How did you develop your career at Delivery Hero?

I started at Delivery Hero as a working student, which means I worked part time while finishing my studies. I’m very thankful for the trust Delivery Hero put in me and how flexibly I could manage my time as a Working Student. I almost immediately got my own tasks to work on and after a few short months working together with another Frontend Engineer, I soon joined a new squad where I became the sole engineer responsible for Frontend. Right after finishing my studies, I joined as a full time employee.

In all that time, I had the greatest mentor who invested so much time into answering every silly question I asked. He became one of the most influential people in my professional development. Today I’m a mid-level engineer and have the privilege of mentoring an entry-level engineer.

Tell us about your current team structure and culture?

At Delivery Hero we work using the Spotify Model, which means I basically have two teams. One team is the Squad, an interdisciplinary team. This is the group of people that I spend most of my time with. This team works together on a specific topic, in my case, it’s Growth. The Growth team works at the intersection of marketing and product development. Our focus is on getting more people to use the platform and to ensure that they always want to return.

The other team is the Frontend Chapter, where all the Frontend Engineers come together. In the Frontend Chapter we focus on knowledge sharing, how to improve our applications and how to best work together in order to achieve our goals. The chapters focus more on the technical improvements, while the squads focus on delivering features and enhancing the product itself.

One of the greatest things about working at Delivery Hero is the multicultural team. I feel this creates a wonderfully vibrant and open culture, which I love. Since I started here I have always been stunned by the amount of trust that has been given to me, allowing me to develop and implement my ideas. Delivery Hero’s trust in me has allowed me to take ownership over my projects, which has impacted my personal and professional development hugely.

What is the biggest accomplishment your team at DH has achieved?

My team and I have accomplished a lot together, such as implementing a subscription feature as a Micro Frontend. However, I have to say that the biggest accomplishment for me is not a technical one. It’s how we have been able to grow as a team, creating a culture of openness. I love how we can share our opinions, have passionate discussions and how we can be fully transparent about the things we don’t know or we need to improve.

What exciting projects are you currently working on?

One of the most exciting things we have worked on is adapting a Micro Frontend architecture for our new applications and developing a whole new Micro Frontend for our new Subscription feature (read more about Micro Frontends here). Besides that, I’m also very excited to be mentoring an engineer who just joined us. It’s a very eye-opening experience, seeing somebody going through the same stages I went through when I first joined. I hope that I’m able to be as helpful as my mentor was to me back then and make his journey as rewarding as possible.

What can a new team member expect to learn in your team?

There are many things a new team member could expect to learn on our team. We provide scalable solutions to complex problems, while always keeping the end user in mind. We work in a massive company on a product that is being used by millions of people all around the globe. Every developer is working in self-organised agile teams to deliver exciting new features. As developers, we are responsible for our features from inception to production and beyond. We act as partners to the Product Owners to deliver the best solutions to our business stakeholders and our customers. Finally, we contribute towards the technical growth of the chapter by sharing ideas, being open to discussions and championing new ideas.

What kind of new team members are you looking for?

The most important traits we are looking for in our Engineers is that they are smart, focused, and of course a team fit. There are two questions we ask ourselves after every interview: “Do I want to work with this person?” and “Will this person be successful at Delivery Hero?”. If you are interested in learning more about our interviewing process, have a look at this article.

When interviewing Frontend Engineers, we focus entirely on the underlying technologies. We rarely ask any questions about frameworks or tools. We believe that frameworks continuously evolve over time and are also easy to learn on the job. However, really understanding how things work under the hood will make you a much better engineer.

What is your advice to people who want to pursue a career in Frontend Development?

Candidates often struggle in interviews when they focus on shiny new frameworks, instead of deeply understanding the underlying technologies. I know this is especially hard in Frontend, as we have new frameworks every other week and new trends emerging constantly.

I remember vividly how confused I was with what to learn first (to be honest, that is often still the case). My number one advice is to focus on the basics, like the ins and outs of JavaScript. Don’t forget about CSS, how a browser renders a page, clean code, good design and how to make a website run faster. Since our field is complex and ever changing, it’s also ok not to know everything. However, we believe it’s very important to be transparent about what you do and don’t know, and to never stop learning.

Apart from that, I think it’s also incredibly helpful to find someone who is already working in the industry, someone who can guide you. Some of the best places to find someone like this are Meetups and initiatives, such as Code on Wheels.

I’m hoping that through this interview, we have provided a little more information and guidance for students and graduates who are at the beginning of their careers.

Are you interested in starting your career at Delivery Hero as well? Take a look at our Associate Software Engineer position.

Originally published at https://tech.deliveryhero.com on October 2, 2019.

My Journey from being a Working Student to becoming a Mentor in Frontend was originally published in Delivery Hero on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Mathias Nitzsche

Are you interviewing at Delivery Hero, or are just curious about our tech interview process? Then read on — we want to be transparent about what to expect so you feel well prepared and ultimately, have a positive candidate experience. Our VP Engineering has broken down the various stages of our technical interview process, with many tips, links and insights to help you feel prepared and ready to do your best!

What are we looking for?

To answer this question we very much follow Joel Spolsky (the creator of Stack Overflow) who wrote: “ In principle, it’s simple. We are looking for people who are 1) Smart and 2) Get things done.”

On top of these two criteria, and this should be quite obvious, we are also looking for people that fit into the team and who we would enjoy working with. We want to hire engineers who we believe will be successful at Delivery Hero and who help create a work environment where everybody looks forward to coming back every day.

In a nutshell being smart, getting things done and caring for each other, are three major attributes that we value.

You might have noticed, that these three points focus less on hard skills, which we think can be learned, but instead put more emphasis on traits that are hard to teach. They are also aligned with the Delivery Hero company values:

The Interview Process

You will usually go through the following steps during the process:

1. Initial call with a recruiter (30min)
2. First tech interview (~1h)
3. Second tech interview (~1h)
4. Final bar raiser interview with a senior engineer from another platform (~1h)

Depending on your seniority, role and location there may be additional steps involved. One of the two technical interviews will usually be with a future colleague (Senior or Principal Engineer), the other one will be with a future supervisor (Engineering Manager or Director). The final bar raiser step is performed by a senior engineer/manager from a different part of the Delivery Hero organisation to ensure that people are hired according to the same standards and criteria throughout the company.

We aim to perform all three interviews within a two week period either via phone or if possible, in the office at our Delivery Hero HQ.

When the interview process is finished you can expect an offer and feedback within 1–3 days.

Prerequisites for Technical Interviews

If you have been invited to an onsite interview at our Delivery Hero HQ, here are some of the things to consider:

• Come early enough to allow for yourself to be checked in at our front desk.
• Bring your laptop with you so that you feel comfortable and to avoid having to code on a whiteboard or probably even worse, using a foreign keyboard layout. 🙂

Remote interview via video call (usually Google Hangouts):

• Have a solid internet connection.
• Be in a quiet environment, ideally using a headset.

Structure of our Technical Interviews

Each interview contains several sections, for which you can prepare for.

Interviews usually start with a brief introduction to get to know each other better and to understand your current situation and your motivation. It is also quite common to discuss projects you are interested or currently involved in.

As we are all passionate about engineering, every interview (for all levels, from internships all the way up to our most senior roles) will involve approximately 30 minutes of live coding.

For the remainder of the interview, broader and more in-depth engineering knowledge and experience will be explored. We want to find out what you know and your way of thinking. In this section, topics like architecture, design patterns, technology choices, decision making or development processes are likely to be discussed.

Of course, towards the end of the interview you will have the opportunity to ask any questions that might have been unanswered.

Tips for Live Coding

First of all, it’s important to point out that we know that simple coding tests are not perfect. They cannot 100% accurately predict how you would work on a huge codebase within an international cross functional team, developing a complex feature for millions of daily users. Nevertheless, they have been proven again and again to be helpful in assessing intelligence, communication and problem solving skills — all things that are quite relevant for being a good engineer.

Interviewers want to enjoy discussing and solving an interesting engineering problem together. To do so, please consider the following hints:

• coderpad.io will be used to code together. You could try it here prior to get used to the IDE.
• Use the programming language you feel most comfortable in! We want to test your problem solving and fundamental computer science skills (theory, algorithms, complexity, data structures, etc.) and not check frameworks or language specific knowledge. Rare exception might be if the position specifically requires a certain skill.
• Talk to the interviewer about what you are doing throughout the live coding, share your thought process. Take your time to think and feel free to ask questions. If you need to be quiet to think, that’s also fine — just let the interviewer know. Listening to other interviews might help you as well: interviewing.io/recordings
• Get things done! In the end, we can only evaluate the code you write. If you can think of multiple solutions discuss the preferred approaches with the interviewer, if not just start with a straight forward simple solution and explore how to improve it afterwards.
• Avoid Trial-and-Error coding. During the development you should not execute your code ongoingly, but rather wait until you think it’s good to run it. And if there are bugs, that’s not a problem at all but a good chance to show your debugging skills.
• Practice! Even experienced senior engineers can get a little rusty at quickly coding an algorithm solving a small math problem, as this is not what you or engineers at Delivery Hero do on a daily basis. Therefore we recommend to spend some time on sites like careercup.com, projecteuler.net, hackerrank.com or topcoder.com to get yourself comfortable with solving problems under time constraints. To practice daily you can subscribe to the newsletter dailycodingproblem.com. If you prefer a good book, check out Cracking the Coding Interview.
• Complexity of algorithms might come up. So quickly read up again what O(nlogn) means.
• And last but not least “You are not your code!”. Even if the process might not be successful this time, you will hopefully have met great people and learned something. In any case we will always treat you fairly and with the highest respect, hoping that we can work together in the future.

Further readings

If you made it until here you should already have all the information necessary for a successful interview process. If you want to know more about our Delivery Hero culture, we highly recommend checking out the following links:

And last but not least, if you are interested in becoming a hero, have a look at some of our open positions!

Originally published at https://tech.deliveryhero.com on September 18, 2019.

Preparing for your Technical Interview @ Delivery Hero — By Mathias Nitzsche was originally published in Delivery Hero on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Alexandros Kechagias

Having experienced various forms of agility — ranging from companies who only use Scrum ceremonies as a reporting mechanism, to companies who actually live the agile mindset, get the philosophy behind it and have a shippable product after every iteration and everything in between — I have to say that Delivery Hero understands the agile mindset.

Let me introduce myself — my name is Alexandros, I’m a Golang (Go) Backend Engineer working in the Growth squad here at Delivery Hero. Over the course of my career, I have gained a significant amount of experience working in various agile teams and today I’m going to share my Delivery Hero story with you.

Let me start by saying that every team has their own working style — depending on the squad members, so what I am about to share with you doesn’t necessarily represent how every team at Delivery hero operates.

Always sprinting!

According to Scrum.org, the term “ sprint “ comes from Scrum, it’s basically a “time frame of one month or less during which a “done”, usable, and potentially releasable product increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.”

A sprint always starts with a “planning session” and ends with a “retrospective”.Our sprints always result in a shippable product and create business value. Always. You can’t call yourself agile if you don’t meet those criteria.

The “Why” aka product/customer view is always the center focus of every ticket and discussion we have. We are continuously self-reflecting on each new iteration and trying to improve ourselves and our process.

Of course, not everyone agrees on everything, but we all commit to finishing the sprint and making our product better (Amazon-style). I strongly believe that the agile mindset has to not only be lived by each team member, but also by management and beyond. At the end of the day, we are all here because we want to reach one common goal — and that is to satisfy the customer.

Let’s begin by breaking down the sprint process:

Standup

A Standup in Scrum is basically a short (~ 15 minutes) alignment meeting that we have every day while standing in front of our whiteboard. The purpose is to keep ourselves updated and focused on everything sprint related, with the main goal being to discuss and remove obstacles.

I noticed that there are a few things that we do differently during our Standups here at Delivery Hero:

Conductor

The first unusual thing that I have never experienced before, was that we have a conductor for all of our Standups. The basic idea is that every team member is leading the team throughout the Standup by:

1. Pointing to the board item

2. Reading the title/description out loud

3. Actively asking the team about its status and if any blockers are in the way and how to go about solving it as a team.

4. Writing down any daily action required to unblock those items.

I think this is a really cool and refreshing idea that helps us stay focused and starts the day in an exciting and positive way. Not to mention the sensation that you get when the ticket that you’ve have been ever so diligently working on moves over to “Done”, of course, followed by applause from your teammates. This will make your day, believe me. I love it.

If you are interested in reading more about how to spice up your Standup by adding the Conductor’s role, check out the article that we posted a few weeks ago here.

Everything analog

The second unusual thing I noticed is that on top of having a physical and digital board — all tasks are handwritten by a team member at the start of each sprint from the digital board (Jira) into Post-its, which we then stick onto a whiteboard. Previously, I have only been used to working with digital boards with touch screens during my development years, where we directly move the tickets in JIRA.

That seems to me like a huge overhead! I remember asking our Scrum-Master, Ivan when I joined Delivery Hero if he knew that we could just print all tickets. He told me, it was mostly because of the psychological effect it has — we tend to give the tickets more value when they’re handwritten and we can better identify with the tasks.

Although I have mixed feelings on this, especially about the fact that we have to keep two boards updated and those post-its constantly falling off, I think it makes sense and adds a personal touch to each ticket.

Board layout

The third unusual, yet interesting thing, is the board layout.

A sprint is successfully finished, when tasks have been moved from “pick me” to “done”, nothing new here, I think the lanes are self-explanatory.

What I found interesting, are the side lanes:

Sprint Improvements: Every sprint, the conductor asks us about the action points we agreed upon in our Retrospective and goes through each one of them. That’s an effective way of reminding everybody about our action points. In my previous experiences, the team always forgot about these items during the sprint, now it’s a concise decision, that we all discuss.

Previous Improvements: Reminds us of all the successfully implemented improvements.

Daily Actions: Are actions we have to take in order to resolve an issue that is currently blocking somebody or something.

Conductor: A list of all team members that are taking turns conducting the Standup, having a different team member each standup.

Retrospective

One of the essentials of the agile mindset is self-improvement and continuous learning from the whole team. The retrospective meeting is the place to express your constructive feedback and identify how the squad and each member of the squad can improve the process, product and approach in the next sprint.

Some of the questions we try to tackle are:

How we can help each other? How we can achieve more? How we can have more fun working together? It is also the place to talk about all the good things that we experienced and celebrate our successes.

I found the retrospective to be shorter here at Delivery Hero than in my previous companies, but nonetheless effective. Our team mostly uses the timeline format, where we place all the things that happened during a sprint and once everything has been mapped out, we cluster them into relevant segments.

Goal: Share what was great in the previous sprint and what we enjoyed. Create an action plan on what we should do differently in the next sprint and going forward. What will help us to work in a more productive and comfortable way?

In conclusion, I’ve really enjoyed the way we work here at Delivery Hero. It’s fun, engaging and the team is laser focused to deliver solutions for our customers. Because at the end of the day, that’s the reason we are all here.

This is the beginning of my multi-part blog series on a developers perspective of Delivery Hero. Stay tuned for more content and if you’re interested in becoming part of the team, have a look at some of our open positions:

• (Senior) Engineering Manager — Internal IT Systems (f/m/d)
• Senior Backend Software Engineer — Java (f/m/d)
• Backend Software Engineer (Golang) — Consumer (f/m/d)
• Senior Node.js Engineer — Restaurant (f/m/d)

Originally published at https://tech.deliveryhero.com on September 4, 2019.

A Sprint in the life of a Hero — Part I — By Alexandros Kechagias was originally published in Delivery Hero on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Delivery Hero we are committed to invest in areas where automation, AI and advanced analytics can boost our business performance. One of the key applications for these techniques is marketing — for example we can automate the creation and execution of many of our marketing initiatives and forecast the impact of marketing campaigns, allowing our marketing teams to spend their time and money in the most efficient way.

The Delivery Hero Marketing Team’s main goal is to promote our global brands by highlighting our unique selling points — variety, speed, affordability and our seamless ordering experience. If we’re successful in creating demand, new users will order. Once new users place their first order, our communication evolves — meaning, we start segmenting our customers to contextualise and personalise our communication with the ultimate objective of providing an amazing delivery experience.

To achieve these objectives, the Marketing Tech Team supports our Marketing Teams in the following ways:

1. Integrating customer data to leverage data signals and decide what is the best content to send to a given customer for a given time and channel;
2. Translating data insights into improved decision making and marketing performance by creating technology that allows us to better assess our marketing campaign’s effectiveness and optimise live campaigns;
3. Creating a marketing management platform that enables setting up marketing campaigns across different channels and communication types — imagery, video, text ads, etc;

Improving customer relationships

One problem our business deals with is negative user experience caused by various operational constraints such as platform, logistics or restaurant issues. In these unfortunate cases, customers have their orders cancelled. This has some obvious negative effects on the business:

1. The probability that the customers may never return increases.
2. Contacts with customer care increase, which impacts operational costs.

The solution

One of the key marketing functions is to manage the relationship with our customers (CRM). So, if a customer has an unsatisfactory experience such as a cancelled order, it is crucial to engage with him/her as quickly as possible, showing them we care and are determined to find a solution tailored to the issue they’re facing.

In order to create an automated system, we started by evaluating the signal of what happened to the customer — a cancelled order. We then built a system that processes these signals and decides, in real-time, what communication, and possible compensation, we can send to a customer based on the different data we have available at the time.

Below you can see a diagram of how the system works:

System Architecture & Technologies

In order to create this automated process, we use a lightweight Django web application hosted on Appengine, which receives details about cancellations that happen from another service (via Amazon SNS subscription). Then, it generates asynchronous events processed with Cloud Tasks which will analyse the data and extract information necessary for the next steps.

For our decisioning system, we use Cloud Functions, while the data we process is stored along the way in PostgreSQL (hosted with Cloud SQL) and BigQuery. The results of the processing are then pushed to various external services in order to credit and notify the user of their compensation.

Finally, we use Google DataStudio dashboards to visualise statistics and track performance. We decided to make use of the tools in the Google ecosystem since they work well with one another, and provide a flawless integration and increased scalability.

Future strategy

We are aware of other incidents that create a negative order experience for our customers impacting their relationship with our brands. Examples are unexpected delays or unsatisfactory items flagged post delivery. We will always strive to optimise from the operational side, to minimise these events occurrence, but we can also proactively reach out to our customers and show them we care to provide the best possible customer experience. Hence our customers will have a positive and quick solution to their problem and order with us again in the future.

If you’re interested in creating these solutions for our customers among other interesting projects within Delivery Hero’s Marketing Tech, we’re hiring!

• Senior Product Manager
• Senior Backend Engineer (Python)
• Senior Data Engineer
• Senior Frontend Engineer

Originally published at https://tech.deliveryhero.com on August 21, 2019.

Developing Marketing Technology to Improve our Customer Relations through Automation was originally published in Delivery Hero on Medium, where people are continuing the conversation by highlighting and responding to this story.

Agile methodologies (such as SCRUM or Kanban) have Inspect and Adapt loops as one of their core ideas. One of the smallest formal representations is the ceremony known as the Daily Standup. In this article, the concept of “rotating servant-leadership” in this context will be introduced.

In this ceremony, most of you have probably used the well-known “ 3 questions format “:

What did you do yesterday?

What will you do today?

Are there any impediments in your way?

This format works well for many teams, but sometimes anti-patterns appear: feeling like it is a reporting session, disengagement of individuals when they are not the ones answering these questions, boredom because it feels like items are not moving forward, or lack of spirit of camaraderie or support.

Luckily, some talented people before us came up with an alternative format, known as “ walking the board” or “ story-focused stand-up “.

How does it work?

In our experience and context, this format is much more effective at fostering a shared feeling of ownership for every item on the board by enabling the team to focus on how to collectively solve issues that get in their way.

Still, there was ( and always is) some room for kaizen. We regularly wrestle with multiple conversations happening at the same time. Sometimes people feel tempted to move “their” items by themselves even during the meeting, which can create a lot of noise. To improve the team’s focus we have introduced the role of the conductor.

The Conductor Role

Just like an orchestra has only one conductor, in this format of Daily Standup, the same principle is followed: each day a different member of the team assumes this role. They lead the standup, going through all of the items on the board — starting on the right-most column closer to DONE, moving from top to bottom (following priority), applying the steps below:

1.- points to the board item

2.- reads out loud the title/description

3.- ASKS the team about its status and if any blockers are in the way and how to go about solving it as a team.

4.- writes down any daily action required to unblock those items.

So there’s one very important observation here: the conductor doesn’t need to know all the details of everything: as mentioned in point 3, she or he doesn’t provide answers or solutions, doesn’t assign tasks; only ASKS the team and reflects the daily plan to solve blockers.

Lastly, in order to avoid the stand-up turning into a reporting session, the team leadership roles (Product Owner, Scrum Master, Tech lead if appointed…), are kindly suggested not to take the role and let others lead.

Bonus point:

In our case we also made a list of team members that take turns sequentially taking the role. This way we even avoid the mental power required to remember who conducted yesterday and decide who can do it today.

In summary, this format of Daily Standup is an example of rotatingservant-leadership: each day, a different conductor helps the rest of the team to organize themselves, providing a focus on how to collectively move work items forward, according to the previously agreed priorities.

Give it a try, you wont regret it!

Originally published at https://tech.deliveryhero.com on August 7, 2019.

Spice up your Daily Standup! Walking the board with a Conductor was originally published in Delivery Hero on Medium, where people are continuing the conversation by highlighting and responding to this story.

By The Global Salesforce Team

Salesforce is one of many global services that Delivery Hero provides to its different global entities. Delivery Hero entities like Talabat (MENA), Yogiyo (Korea), PedidosYa (LATAM), ClickDelivery (LATAM), Foodpanda (APAC), Mjam (Europe), Online Pizza (Europe) and Pizza Online (Europe) are already onboarded to the platform. Users from our Sales, Customer Contact Centers, Finance, Legal and Partner Operations departments uses Salesforce, making it a major tech platform for Delivery Hero. The goal is that all entities will use Sales Cloud, Service Cloud and many other platform features offered by Salesforce. This article shows how we have been rolling out the Salesforce Lightning Experience for Service Cloud to three out of the seven entities during the past months.

Why did we switch to Salesforce Lightning?

Especially for our daily users of Salesforce, it was time to change to the Salesforce Lightning UI as it improves their everyday work, by removing multiple clicks and showing more information at one glance, for example. This allows our users to work much faster and efficiently.

Our priority was to rollout the Lightning experience to Service Cloud users (our users from Global Contact Centers, such as our Customer Care agents and their supervisors). Our users were very excited to be part of the journey by helping with testing and training fellow colleagues during our pilot program. Due to the high volume of orders each day, our contact centers had many opportunities to actually try out the new design.

How did we make it happen?

In order to get a better understanding of how ready our Salesforce instance was, we used the Readiness Tool provided by Salesforce. The tool generated a report in PDF format for both the Sales and Service Cloud. The report consists of the readiness of users and the suggested Salesforce features to switch. The majority of issues that were reported to us were on custom buttons, links, urls, visualforce pages and components that come with app exchange products such as New Voice Media.

Challenges — Testing — Solutions

Our first Lightning transition process looked relatively simple based on the outcome of readiness check report. We had to create Lightning pages for objects in use, create a trigger to handle case from chat creation, create several custom Lightning components to support business processes, and make sure to replicate email template automation. During this process we encountered three different technical implementation challenges.

Technical implementation Challenges:

Challenge 1: Standard Send Email Functionality

The standard send email functionality on case object became a big issue due to the email template section based on each entity (brand), country and type. In addition to selecting the right template, support agents have to pick the correct email address and use the correct sender email address. Our contact center team heavily depends on this feature. In Classic Salesforce this was done with a url hack, where you create a custom button giving all the parameters in a url which is picked up by the system and applied. Lightning design doesn’t support the solution, hence we needed to come up with a new solution. We developed a quick action based solution by overriding “Default Handler for Email Action” with dynamic custom, although it took us several iterations.

Challenge 2: Case Reason component

A custom Lightning component was developed to help the customer care agents traverse through a three-level dependent picklist from a bottom-up approach instead of a standard top-down approach. An auto-complete search bar is provided to the agents to select the appropriate Case Reason Level 3 out of 300+ picklist values. The respective Level 2 and Level 1 is selected automatically based on the selected Level 3.

If needed, they can still select the data in a hierarchical manner, i.e, Level 1, Level 2 and Level 3. Additionally, there is a feature to navigate through and select the options from the search results through arrow keys.

Challenge 3: Create a case dynamically for every incoming chat

For every incoming chat we are creating a case through dynamic flows for better tracking, sharing purpose and follow-ups if required. The field mapping and default values to create a case are developed using trigger and configurable values for each entity. So, it is more agile and dynamic to support complex processes around the case object.

Testing Challenges:

The main challenge that we were facing during the testing phase was the testing of real-time scenarios in a dynamic environment. Moreover, we had to test Case Reason Dependencies while delivering a high quality application in a short amount of time.

These are standard Salesforce functionalities which you would assume all work out of the box. However, on second sight it wasn’t that easy after all.

In order to overcome these challenges and as part of our user rollout strategy, we gave only access to a few, selected users (champions), that were eager to try out a new Salesforce design and were able to switch back and forth from the Lightning to the Classic design during the testing phase. This helped us a lot, since these users were not afraid to try out the new technology and were still able to use Salesforce without any problem for their daily tasks. This was very important, especially to our customer support team, since they have to be very responsive and can’t allow even a few minutes of downtime.

The champions were power/super users who were the first ones to be trained on new features and then acted as brand ambassadors to support their fellow colleagues. As their feedback was extremely valuable to us, we engaged them as early as possible in the testing. We really appreciated their positivity throughout the rollout of the project despite some internal changes in the business structure.

Here we can show some examples of the Classic Salesforce interface versus the Lightening experience.

Salesforce Classic:

Salesforce Lightning:

Feedback from Stakeholders

From the beginning of this project, all users (agents/supervisors/stakeholders) were involved in the process. It was important to us to work closely with them to guarantee not only a smooth transition from Classic to Lightning but also to make sure that they have a better user experience that helps them to work more efficiently.

During the implementation, the product was constantly improved by taking into account the suggestions and needs of our champions. Hence, our end users were satisfied with our results during the rollout. A major improvement for our customer service agents now is that they have all necessary information they need to file a ticket in our system on the same page as their chat with their customer. This helps them a lot to react faster and solve the issue of a customer more efficiently.

The overall feedback from the end users is positive. They are happy with the new user interface as it is more intuitive and improves their daily work a lot.

In addition to the great user experience, they mentioned that the support throughout the project from our Salesforce and Global Contact Center team was a decisive factor that contributed to the successful implementation.

Aside from the good feedback, we also received improvement requests. While some aspects are already done in production, others will be worked on during the upcoming quarter. These are some examples of what we still have to work on:

• Service agents will have all necessary information readily available in a single page to improve average chat closure time with customers, instead of them having to navigate through different pages/applications to view required data to respond.
• Add on the Chat page: “log a call” which is the possibility for an agent to submit a note about a call on the case record and to introduce a field to indicate the case owner.
• Adding a search box for case reasons that are not case sensitive.
• Add a close chat tab when the chat is ended.

Recognition from Salesforce

Not only did we get great feedback from our stakeholders, we also received an award from the Salesforce Service Cloud Customer Advisory Board for having turned the most agents into Customer Service Heroes!

Future road map

This was a great beginning! The future road map looks very exciting for us. As mentioned initially, the Lightning experience enablement is one of many interesting features to rollout. We have identified many more new features that we would like to implement and that synchronize perfectly with the Lightning experience. These are our upcoming goals:

• Rollout Lightning experience to remaining regional contact centers.
• Ready for a bigger challenge — Lightning experience rollout plan for Sales Cloud users.
• Provide a more intuitive UI to customer care agents for quick case resolution.
• Ensure support for Salesforce Classic throughout the transition — expect the unexpected!
• Ensure new features like contract document generation, e-signature, mail and calendar events synchronization with the Lightning experience.
• Guarantee all future onboardings of new entities/countries only with the Lightning experience.

We are looking forward to it!

If you are interested in joining our Salesforce team, have a look at our current positions:

Salesforce Tech Lead — Sales Cloud (f/m/d)

Salesforce Tech Lead — Service Cloud (f/m/d)

Salesforce Release Engineer (f/m/d)

Salesforce Administrator (f/m/d)

Salesforce Administrator — Contact Center (f/m/d)

Salesforce QA Engineer (f/m/d)

Salesforce Developer/Engineer (f/m/d)

Originally published at https://tech.deliveryhero.com on July 23, 2019.

The Migration from Salesforce Classic to the Lightning Experience — Service Cloud was originally published in Delivery Hero on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Özgür Kara & Editorial Team

Banabi is a grocery shopping feature within the Yemeksepeti application that allows users to order more than 2,000 market products and deliver their orders within 15 minutes, with the use of dark stores, along with any other food orders — saving them the time and effort of grocery shopping, cooking and preparing food. Read more about our journey and how we developed this app within three months.

Hi, my name is Özgür Kara and I’m working as a Software Architect at Yemeksepeti, an online food ordering company based in Turkey and in Cyprus. Yemeksepeti is the first and the strongest online food ordering app in Turkey, with more than 20 thousand restaurants in 69 cities!

As a software architect, my team and I have been responsible for constructing and implementing a new software into our current food ordering app, Yemeksepeti, which we called Banabi — allowing us to explore the new vertical of grocery deliveries.

In order to efficiently carry out this new feature, we are very excited to present the concept of ‘dark stores.’ For those of you who are not yet familiar with this concept: dark stores are similar to your conventional supermarket, containing groceries and other items.

However, not open to the public, these stores are located in areas that are preferred for good road connections, enabling our riders to efficiently pick up other items, such as groceries, that were ordered along with lets say a conventional food order.

The Banabi project has been released for iOS and Android and is currently being developed for desktop. In this article, I will take you through our journey and go over the various methods we used to bring Banabi live.

How did we start?

We were introduced to the idea during one of our kick-off meetings, where we received the first bits of information regarding the project. To our surprise, we learned that we only had three months to complete the project, before going live.

We had built an asynchronous microservices architecture for Yemeksepeti before the Banabi project.

Our initial thoughts were that we could use a similar structure to the current architecture we were using for our Yemeksepeti application already due to the limited time we had.

The only issue with this was that at the time, Yemeksepeti was currently in the process of being re-coded, meaning it would not be up to date. The idea of building the Banabi project on the outdated Yemeksepeti system did not make sense to our development team and we figured Banabi should be its own independent project with it’s own features, requirements, code quality standards and time estimation.

What was the game plan?

As the Platform team, we distributed the different services amongst us. So, we created nine different services we started working on, these include:

1- Order API

2- Basket API

3- Marketing API

4- Product API

5- User API

6- Internal API

7- Manager API

8- Admin API

9- Cron API

In order to better keep track of our progress, we created the following five categories as ‘definitions of done’ to align on when the development of each service was completed.

1. The test coverage of each service must be greater than 90%.
2. The completed development must be sent to SonarQube, where it is tested for various bugs and its vulnerability.
3. At least two developers have to review the code for all pull requests.
4. The development should be in accordance with the standards of the example project.
5. API requests should have maximum latency of 100 ms without cache.

Which tools did we use?

Despite only having had a limited amount of time to develop our new software, we still wanted to use various popular technologies and tools to make sure we did it right from the start.

In the following, I’ll explain briefly which technologies, software and tools we used and why.

.NET Core & Golang: All services are developed with .NET Core Web API. We were really satisfied with the performance of .NET Core. So, we decided to develop with restful standards. It reduced our job of writing documentation for the API to create a particular URL. We decided to develop the image-resizer project in Golang. Using AWS Lambda, S3 and Go we were able to avoid problems and major headaches.

Fluent Validation: Having already employed Fluent Validation in previous .NET Core projects successfully, we decided to use this framework again.

AutoMapper: We decided to use AutoMapper in more than five different property matches, since it’s a simple reusable component which helps you to copy data from object types.

MediatR: A very successful and popular framework, our developers pushed the SOLID principle which gave us better quality and more time to complete the project.

Swagger/OpenAPI: A very popular specification to speed up integrating with an API. Our mobile developers were able to quickly and easily execute their implementations by using Swagger.

Serilog: It’s a great portable and structured logging framework that helped us to integrate many log libraries.

Hangfire:We have been happy to use Hangfire because it simplified our background processes.

XUnit: Even though we had never used xUnit before, everyone adapted to it and it increased and facilitated unit testing speed through some of its features.

Redis: As an in-memory data structure project, it was our first choice and using it was a no brainer for us.

What have we accomplished?

In order to be able to publish the project three months later, we had to complete the services as a backend team in two and a half months, which we successfully achieved. In addition to that we consistently maintained our code development standards and quality throughout the process and the performance of our API’s ran smoothly. In the end, all services were published with only a few minor bugs. Since we were a newly created team, our biggest achievement was to produce the product within the given time frame, allowing us to grow together as a new team.

Final improvements

Despite our test coverage goal of at least 90%, we had to lower our expectations for some projects in which we only reached 80%. Moreover, we were not able to reserve enough time for testing. If we would have had an additional two months for the implementation of the project, we would have implemented further load and integration testing and improved the code quality.

Conclusion

We are thrilled to announce that Banabi is now up and running. The project is running successfully in Istanbul and continues to work exponentially with the number of orders each new day. With the growth we are experiencing, we soon plan to expand this service to additional cities in Turkey.

Despite all the hard work and time pressure, it was a very rewarding and exciting project to be a part of. We are looking forward to see our project grow and expand around the globe.

I’d like to thank my team for making this possible in the short amount of time we had.

Originally published at https://tech.deliveryhero.com on July 5, 2019.

Banabi — How we developed a new grocery ordering app within three months? was originally published in Delivery Hero on Medium, where people are continuing the conversation by highlighting and responding to this story.

You must have been living under a rock if you haven’t heard the Kubernetes (k8s) hype over the last few years. It has quickly become the platform of choice for running applications for many modern tech companies and Delivery Hero is one of them. What is unique about DH, is that some of our tech teams are very isolated, sometimes even on different continents, speaking different languages, with different applications trying to solve different problems.

While this broad diversity in technology can have its challenges, it has also allowed us to collectively try various approaches to solving common problems. In this article, I will share some of this collective experience and detail on how using a few tools can solve some common problems while running k8s at scale:

1. Managing many k8s resources without headaches
2. Managing k8s resources in a stateful way
3. Preview changes to k8s resources before applying
4. Dealing with sensitive data in k8s

When our teams first started using k8s, like most people, they started with a bunch of YAML files. While this is great in the beginning, once you have multiple clusters and many applications in many environments, simple YAML files can quickly become too difficult to manage, due to the number of files required. Consider what resources you might want for a common application: Deployment, Service, Ingress, ConfigMap, Secret, HorizontalPodAutoscaler and maybe a CronJob or two. With all these files, you will end up with a tonne of duplicated code and it can be tricky to keep values in sync across multiple files. In the beginning, some of our teams have solved this problem with some simple shell scripting or automation, such as using sed or envsubst to manipulate YAML files, or some more advanced templating solution like Sprig or Jinja. But fast paced k8s ecosystem has quickly converged on a single tool for this…

Helm

Helm charts allow you to package your application in a common way with text templating and some basic programmatic functions such as booleans and loops. Almost every team in DH is now packaging their applications in Helm Charts. And with the public charts repository, Helm is also the go to solution for installing cluster level tools, such as cluster-autoscaler, nginx-ingress, metrics-server and many more. DH engineers have even created some of these public charts, for example the cluster-overprovisioner.
Once you become a convert to the religion of Helm, some problems become apparent. What charts are installed on what clusters? What version of the Prometheus chart is running on the staging cluster? How can I install and upgrade multiple charts together and programmatically? This is where the second tool comes in…

Helmfile

Helmfile lets you specify your charts in a file, with Helm values files, associate them with a specific kubectl cluster context and then allows you to sync them to the cluster in a single command. Here’s an example for some applications:

context: eks_staging

releases:
- chart: charts/apps/event-processor
  name: staging-event-processor
  values:
  - chart/sapps/event-processor/values/staging/values.yaml

- chart: charts/apps/delivery-manager
  name: staging-delivery-manager
  values:
  - chart/sapps/delivery-manager/values/staging/values.yaml

Then we can sync these charts to the cluster eks_staging:

helmfile --file helmfiles/staging.yaml sync

Helmfile is also a great tool to bootstrap a fresh cluster after creation. For example, we have a standard set of charts we install on every cluster: cluster-autoscaler, fluentd, nginx-ingress, metrics-server, external-dns, oauth2-proxy, prometheus, cluster-overprovisioner and node-problem-detector. We specify these charts and pin them to specific versions in a separate Helmfile and place this file in git. This allows us to track and upgrade charts across multiple clusters in a safe way, for example testing newer chart versions on non-live clusters first.

So now we have our applications neatly packaged into charts and we manage the charts in a stateful way using Helmfile, but how can we be sure what’s going to happen when syncing our charts? Helm just sends the data to the k8s API and often it’s not clear what is going to happen. Here we use a Helm plugin…

helm-diff

helm-diff gives you a colour coded diff output of the changes Helm will apply. Very handy! This allows your workflow to be a little more like Terraform, another tool we are using every day here at DH. Here’s an example showing a change in a configmap for nginx-ingress:

$ helmfile --selector name=ingress01 --file helmfiles/staging/infra.yaml diff
exec: helm diff upgrade --allow-unreleased ingress01 stable/nginx-ingress --version 1.0.1 --values nginx-ingress/staging/values.yaml --kube-context eks_staging
default, ingress01-nginx-ingress-controller, ConfigMap (v1) has changed:
  # Source: nginx-ingress/templates/controller-configmap.yaml
  apiVersion: v1
  kind: ConfigMap
  metadata:
    labels:
      app: nginx-ingress
      chart: nginx-ingress-1.0.1
      component: "controller"
      heritage: Tiller
      release: ingress01
    name: ingress01-nginx-ingress-controller
  data:
    enable-vts-status: "true"
    log-format-escape-json: "true"
    proxy-next-upstream: error timeout http_502
-   proxy-next-upstream-tries: "3"
+   proxy-next-upstream-tries: "2"
    use-geoip: "true

So no we now have a nice workflow for dealing with k8s resources, but how can we handle sensitive data in our Helm charts? Like API keys and credentials?

helm-secrets

The 4th and final tool we will look here is also a Helm plugin: helm-secrets

How many times have you seen API keys or passwords in clear text in git? Or used some painful custom encryption tool based on GPG or similar? Or had to separate sensitive data entirely from Helm charts? There are many different tools to solve these types of problems, but few I have seen that integrate so well with the workflow covered in this article. The helm-secrets plugin integrates with Helmfile so encrypted chart values files are seamlessly decrypted locally using a key from AWS/GCP KMS service, applied to the cluster using Helm and then deleted. This has some significant benefits:

• The encrypted values files can be safely stored in git
• The encrypted values files are not stored unencrypted at all
• Authentication to your cloud provider is required for decryption
• The YAML keys in the values file are left unencrypted so pull request diffs still make some sense while still obfuscating the sensitive values
• Encrypted values in the Helm chart can be used like any other key/value

Here is an updated Helmfile entry from before, but with an encrypted values file added:

context: eks_staging

releases:
- chart: charts/apps/event-processor
  name: staging-event-processor
  values:
  - charts/apps/event-processor/values/staging/values.yaml
  secrets:
  - charts/apps/event-processor/values/staging/secrets.yaml

And the secrets.yaml file might look like this on disk with some of the meta-data removed:

secrets:
    API_KEY: ENC[AES256_GCM,data:xxxxxxxxx=,tag:xxxxxx==,type:str]

You will also need to add a .sops.yaml file somewhere so helm-secrets knows what KMS key to use. Once this is in place and you have access to the KMS key in your cloud provider, you can simply sync the chart in the same way as normal and the values in secrets.yaml will be decrypted seamlessly.

Conclusion

The benefits of k8s can be quickly outweighed by management overhead if you are not careful. But by using some simple tools we can make life easier, changes safer and data more secure.

If you enjoyed this article and enjoy working with Kubernetes, then perhaps you would be interested in the following role, where you would be using Kubernetes on a daily basis to run our discovery and recommendation system.

We also have a variety of other exciting positions, feel free to check them out here.

Originally published at https://tech.deliveryhero.com on June 21, 2019.

Kubernetes at DH: A journey from YAML headaches to Helm bliss was originally published in Delivery Hero on Medium, where people are continuing the conversation by highlighting and responding to this story.

by Yann Landrin-Schweitzer

At DeliveryHero, we build for scale. With an objective of 10M orders a day, in more than 30 countries worldwide, being able to scale our operations, in a sustainable and cost-effective way, is the primary driver of our engineering practices. DevOps is one of the methods and behaviors which allow us to achieve scalability.

This is the first instalment of a series of blog post looking in detail at the relationship between data, AI and DevOps.

What is DevOps?

“DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes.” (AWS: What is DevOps?)

In short, DevOps is a practice (ideally, not a team or a role!). Software engineers who practice DevOps not only code, but also are responsible to maintain and support their applications.

This practice emerged to enable high-velocity, high-quality and highly predictable delivery of software applications.

DevOps principles

DevOps principles assume that the majority of costs, failures and inefficiencies in the design, delivery and operation process of software are due to its human component.

For this reason, it tries to minimize direct human intervention through the automation and optimization of all possible deployment, testing, monitoring, configuration and repair tasks.

By doing this, it also incorporates a number of more targeted practices that focus on automation, such as Continuous Integration and Deployment, Test Automation, Infrastructure as Code or Service Reliability Engineering.

“Typical” DevOps perspective often assumes that the two components of interest are software and infrastructure. It asserts its scope on infrastructure provisioning, scaling, failure management, application and infrastructure monitoring, as well as the deployment and orchestration of the software applications that run on these.

In that context, data is often regarded as an ephemeral characteristic of the application. It is assumed to evolve in a synchronized manner, through the same set of processes, and to require no special treatment. Specific focus on data as a distinct entity with distinct management is relegated to very “waterfall-ish” traditional database administration approaches.

So what changed?

Applications rely on and manipulate increasingly larger and more frequently changing datasets. These datasets evolve with markedly different rhythms and drivers from application logic, and have business impacts that vastly survives their production, transformation and use in a single application version.

In that context, the same velocity and quality limitations that existed for software start becoming an issue for data, with amplified consequences due to the cost of acquiring valuable data.

Models of different datasets get out of sync, releases cannot be completely tested or rolled back because their data has moved on, the complexity of testing and validation for all data cases make frequent iterations impossible. In the end, the gains of applying a DevOps model to the software part are negated by the effort to keep data valid and correct in such a rapidly changing environment.

So teams are tempted to switch back to a more planned, waterfall-ish model, where ensuring data health is easier. But surely, there is a better way?

Can DevOps principles apply to data?

Extending DevOps principles to being applicable to data brings in a major increase in complexity. It requires investment and focus in a number of “new” topics that generally had received no attention up to that point: data generation, data testing, data versioning and data automation. “Old” topics also need renewed focus, and a much higher standard of accuracy and quality: the ability to test in production-replica environments, the accurate specification and documentation of business processes, the tracking and lineage of data flows in the organization, the discoverability and visibility of business logic in and to all parts of the organization.

In all these areas, most organizations that have not focused on data agility before have low maturity, therefore making “DevOps for data” a large and scary investment.

What about DevOps and Machine Learning?

Machine Learning, and more generally Artificial Intelligence, are increasingly used in applications to provide “smart” features (i.e. very adaptive to the context and the needs of the user) in software applications. Simply put, it processes historical data to detect patterns, generalize them into models, and apply them to new data to predict future situations.

AI and ML techniques therefore contain many “gray” or “black” box components, these patterns that have been learned from data. Adding them to the system landscape adds several extra dimensions of complexity to the application lifecycle. Not only it is even more critical than before to know what data has been used in each of the many different stages of learning, but it is also more difficult to control exactly what logic is running in an application.

In addition to configuration, code, and now data, models also need to be taken into account. And models generated from data and training algorithms are particularly complex to manage. They are:

• costly to generate (requiring massive data movement and processing), therefore changing and re-training models needs to be done deliberately and in a controlled fashion;
• usually at least partially opaque (difficult to understand by “reading” them), therefore difficult to test in an isolated manner;
• and critically dependent for meaningfulness on both source data and feature generation code, therefore much more complex to reproduce exactly.This challenges the original DevOps assumption that delivery is essentially limited by its human component.

In other words, the AI component itself becomes a major source of cost and unpredictability.

Originally published at https://tech.deliveryhero.com on June 12, 2019.

DevOps for Machine Learning — What does this mean, and why do you need it? — Delivery Hero Tech was originally published in Delivery Hero on Medium, where people are continuing the conversation by highlighting and responding to this story.

by Akanksha Sharma

You are all probably familiar with the most common problem of having one big platform — It’s too big to handle, it is hard to understand, it can be tricky to deploy new features and it can be a pain to onboard new engineers. In my team at Delivery Hero, we decided to tackle this issue by using Docker. In this article I will explore how we use Docker for frontend and how it helps us to make all our lives easier.

Why should you use Docker?

In the past, when a business needed new applications, their DevOps team would go out and buy a server without knowing the performance requirements of the new apps. This would involve a lot of guesswork as well as waste of capital and resources which could have been used for other apps.

Enter virtual machines (VM). They allowed us to run multiple apps on the same server. However, there was also a drawback. Every VM needed an entire OS to run. Every OS needed CPU, RAM etc. to run as well. This required patching and licensing, which lead to increased costs and resiliency.

A container model basically means that multiple containers on same host use one host, freeing up CPU and RAM which could be used elsewhere.

But how does it help us developers?

It ensures that the working environment is the same for all developers and all servers i.e, production, staging and testing.

Anyone can set up the project in seconds; no need to mess with config, install libraries or setup dependencies.

In simple terms Docker is a platform that enables us to develop, deploy, and run applications with containers.

Let’s take a step back, what does container system actually look like and how is it different from VM?

As you can see, a host and it’s resources are shared in containers but not in Virtual Machines. With that out of the way, let’s dive in!

How to use Docker?

First off, we need to familiarise ourselves with certain terminology.

Docker image: An executable file which contains cutdown operating systems and all the libraries and configurations needed to run the application. It has multiple layers stacked on top of each other representing a single object. A Docker image is created using Dockerfile.

Docker Container: A running instance of a Docker image. There can be many containers running from the same Docker image.

Containerize a simple Node.js App

We would try to containerize a very simple node.js app and create an image:
Let’s start by creating folder my-node-app,

mkdir my-node-app 
cd my-node-app

The next step is to create a simple node server in index.js and add the following code:

//Load express module with `require` directive
var express = require('express')
var app = express()
//Define request response in root URL (/)
app.get('/', function (req, res) {
 res.send('Hello World!')
})
//Launch listening server on port 8081
app.listen(8081, function () {
  console.log('app listening on port 8081!')
})

and save this file inside your my-node-app folder. Now create a package.json file and add the following code:

{
"name": "helloworld",
"version": "1.0.0",
"description": "Dockerized node.js app",
"main": "index.js",
"author": "",
"license": "ISC",
"dependencies": {
"express": "^4.16.4"
}
}

At this point, you don’t need express or npm installed on your host, because remember, the Dockerfile handles setting up all the dependencies, libraries and configurations.

The Dockerfile

Let’s create the Dockerfile and save it inside our my-node-app folder and then add the following code:

# Dockerfile
FROM node:8
WORKDIR /app
COPY package.json /app
RUN npm install
COPY . /app
EXPOSE 8081
CMD node index.js

Here is an overview of what is happening:

FROM node:8 - It pulls a node.js docker image from docker hub, which can be found here.

WORKDIR /app - It sets the working directory for our code in the image and is used by all the subsequent commands such as COPY, RUN and CMD.

COPY package.json /app - It copies our package.json from the host my-node-app folder to our image in the /app folder.

RUN npm install - We run this command inside our image to install dependencies (node_modules) for our app.

COPY . /app - We communicate to Docker to copy our files from my-node-app folder and paste it to /app in the docker image.

EXPOSE 8081 - We expose a port on the container by using this command. This is done because in our server index.js is listening on 8081. By default, containers created from this image will ignore all requests made to it.

Build Docker Image

# Build a image docker build -t <image-name> <relative-path-to-your-dockerfile>
docker build -t hello-world .

Now it’s show-time! Open the terminal, go to your folder my-node-app and type the following command:

This command creates a hello-world image on our host.

-t is used to give the name hello-world to our image.

. is the relative path to the docker file. Since we are in folder my-node-app, we used dot to represent the path to the Docker file.

You will see an output on your command line like this:

Sending build context to Docker daemon  4.096kB
Step 1/7 : FROM node:8
 ---> 4f01e5319662
Step 2/7 : WORKDIR /app
 ---> Using cache
 ---> 5c173b2c7b76
Step 3/7 : COPY package.json /app
 ---> Using cache
 ---> ceb27a57f18e
Step 4/7 : RUN npm install
 ---> Using cache
 ---> c1baaf16812a
Step 5/7 : COPY . /app
 ---> 4a770927e8e8
Step 6/7 : EXPOSE 8081
 ---> Running in 2b3f11daff5e
Removing intermediate container 2b3f11daff5e
 ---> 81a7ce14340a
Step 7/7 : CMD node index.js
 ---> Running in 3791dd7f5149
Removing intermediate container 3791dd7f5149
 ---> c80301fa07b2
Successfully built c80301fa07b2
Successfully tagged hello-world:latest

As you can see, it ran the steps in our Docker file and the output is a Docker image. When you try it for the first time it might take a few minutes. If you are repeating it more often, it will start to use the cache and build much faster and the output will be as shown above. Now, try the following command in your terminal to see if your image appears:

# Get a list of images on your host 
docker images

It should have a list of the images in your host similar to the one below:

REPOSITORY    TAG      IMAGE ID      CREATED         SIZE
hello-world   latest   c80301fa07b2  22 minutes ago  896MB

Run Docker Container

With our images created, we can spin up a container from it.

# Default command for this is docker container run <image-name>
docker container run -p 4000:8081  hello-world

This command is used to create and run a Docker container.

-p 4000:8081 - This is publish flag. It maps host port 4000 to container port 8081 which we opened through expose command in dockerfile. Now all the requests to host port 4000 will be listened to by container port 8081.

hello-world - This is the name we gave our image earlier when we ran Docker-build command.

You will receive an output similar to this:

app listening on port 8081!

If you want to enter your container and mount a bash terminal to it, you can run:

# Enter the container
docker exec -ti /bin/bash

In order to check if the container is running, open another terminal and type:

docker ps

You should see your container running like this:

CONTAINER ID    IMAGE        COMMAND                  CREATED
<container id>  hello-world  "/bin/sh -c 'node in…"   11 seconds ago

STATUS              PORTS                    NAMES
Up 11 seconds       0.0.0.0:4000->8081/tcp   some-random-name

It means our container with id <container id> created from the hello-world image, is up and running and listening to port 8081.

Now our small Node.js app is completely containerized. You can run http://localhost:4000/ on your browser and you should see this:

Voilà, you have containerised your first app.

If you are interested in joining our team, have a look at our open positions:

• Senior Frontend Engineer (f/m/d)
• Fullstack Engineer (f/m/d)
• Senior Frontend Engineer — foodora/foodpanda (f/m/d)
• Frontend Engineer — Angular (f/m/d)
• Frontend Engineer — React (f/m/d)
• Frontend Engineer (f/m/d)

Originally published at https://tech.deliveryhero.com on May 23, 2019.

How to use Docker for Frontend Developers — Delivery Hero Tech was originally published in Delivery Hero on Medium, where people are continuing the conversation by highlighting and responding to this story.