Have something to share about engineering practices, architecture or DevOps?
Become a speaker now


BOF: Kubernetes operators: What? When? How?

This BOF session is devoted to very hot topic in Kubernetes community – operators. Group of Kubernetes professionals will discuss what operators are, when and how to use them and does every team need to implement their own operator. Come and join this hot discussion!

Lego from Containers

Containers, microservices, cloud read applications – every developer heard about them. We know how to build services to be container ready, how to manage Docker/Kubernetes and so on.

What is often being missed is a composability aspect of containers. There are thousands of ready to use images which, when properly composed, can solve the problems that are usually solved by writing code.

In this talk Serhiy discuss few design patterns based on containers, that allow to reduce the complexity and time to market for your services.

100 deploys per day

At Preply we have adopted the culture of quick iterations as a central part of our delivery process. The approach impacted both developers’ culture and organization’s ability to deliver value to the end customers.

This talk will be focused around the evolution we went through with our delivery approach, and the benefits and challenges daily releases have thrown up. We will also discuss tooling around daily releases(CI/CD tools, logging, monitoring), infrastructure(k8s, aws) and the best practices(feature switchers, architecture, ab/testing).

We will also share insights on the role of the performance optimizations to make daily releases viable.

What we’ve learned once processed first 150k production incidents

We develop a software which helps multiple companies worldwide to work with IT incidents. Our daily routine is to talk with them, learn about their incident management and process their data. I’ll tell about insights we’ve got on such a scale. How different companies and teams do it and what works for them.

Need for testers is a lie

It is a widespread conception that QA resources in the team are a necessity and vast majority of projects place them in their teams – both functional and automation testers. I’ll try to debunk this by presenting examples of two successful projects of different size, domain and using different methodologies that succeeded without having a single tester on the team. Finally, we will discuss a few hypotheses attempting to explain why QA presence is so prevalent and what we could learn of it.

DataKernel : Mastering Ukrainian highload framework

Creating a full-stack Java framework from scratch is a comprehensive and challenging task on its own. But creating a framework which outperforms Spring, Vert.x and Javaspark may sound even above attainment. Yet, the new DataKernel framework proves it is possible. We want to share our experience, and speaker will tell how you about the results were achieved and will bolster them with numerous benchmarks and implementation insights.

Build optimization mechanisms in Gitlab and Docker

For each tool, I’ll describe available optimization mechanisms that help to reduce build times. I’ll analyze their trade-offs, provide guidance on which & when to use, mention common pitfalls and workarounds. The talk is aimed at developers who already use Gitlab / Docker and want to learn lesser-known facts in order to achieve faster builds.

How to build a large clusters in GKE/On-Prem

Topics which we’ll discuss:

1. Typical issues within designing a large Kubernetes cluster on GKE/On-Prem.
2. Pitfalls and possible tricky areas in elaboration.
3. Consider existing solutions consistent with real-life and best practice cases.

30 minutes to Prod

This talk is about Engineering Practices and engineering transformations during the last 3 years in Infra R&D department and company in general. Infra is a core department, which handles core services and infrastructure for all Playtika games.

– Deployment time decreased 100 times.
– Incident ratio decreased 10 times.
– The number of deployments increased 10 times.
– Strong, productive and happy teams.

Playtika DNA, small teams (triplets) which correlate with microservices architecture, gatekeeper institute: 24/7 support.

Effectiveness tips from Kubernetes trenches by Captain Obvious

Nowadays almost everybody knows about Kubernetes, some teams are using it and some are only dreaming about it. Despite the popularity, Kubernetes is not simple and there are so many ways of abuse this peaceful technology. In this talk I would like to present quite obvious set of tips, based on failures and ineffectiveness at different companies I have worked with during last several years.

Site Reliability Engineering: How-to

Site Reliability Engineering is an approach for DevOps pioneered by Google. This talk focuses to share Yegor’s experience in building SRE organization inside EPAM. The presentation is a road map for architects, managers and developers to introduce and transform DevOps culture and processes based on real world example using modern cloud-native technologies.

Saga about distributed business transactions in microservices world

Most of people nowadays think microservices architecture is a great way to build any system. They visit conference talks, read books and review tutorials, where ‘hello world’ applications are built just in several minutes using microservices approach. But the reality is not so wonderful and one of the biggest pain is hidden inside distributed business transactions. In monolith application this topic is almost completely covered with DB level transactions. In distributed world you have to face many issues trying to implement reliable and consistent business logic.

In this talk we will review different types of problems related to distributed business transactions, popular SAGA pattern, frameworks and techniques to simplify your life without compromising quality of the system.

Discovery on Terra Incognita

This story is about engagement of a Solution Architect into absolutely new and complex business domain – life science, where a client wants to modernize his legacy platform, which itself is a unique technological offering on the market. Sounds challenging already? Let’s have a look on how a Solution Architect can be successful in such project.

The value of observability in production microservice ecosystem

Today system observability is a much discussed term, which is often treated as “nice to have” during development, but becomes crucial once your system gets into production. It becomes even more important in case of distributed systems, where one can’t just spin up a local server and debug it end-to-end.

I’m going to share a experience of a development team, working in production microservice ecosystem, providing 24/7 support for the owned services, and how observability best-practices helped us to survive. We’ll touch the holy triad of observability: monitoring, log aggregation and distributed tracing, discuss some general best practices of how to make them work together and look at how we attempted to apply those best practices to real life.

The Zen of logging. How to face the worst day of your life.

Action! Where do I begin to tell the story of how your architecture is done, you have a logging framework, you know where to store logs. Where do you start writing it clear and useful?

Put the matter another way, during my talk I will try to share my’ experience with the audience on the following subtopics:

– What are logs in common and wherefore.
– Stuff you should never see in logs.
– Patterns and AntiPatterns.
– Logs within a distributed chaos.
– What to do to spend minutes and safe hours while surfing through a considering amount of data.

After all, I do not guarantee that your worst day ever will never happen. You’ll have a log at least. Don’t panic and carry a towel. Always!

Kubernetes vs DCOS

Kubernetes is the most popular orchestrator for large microservices system. It provides possibility for automating application deployment, scaling and management. But does it really a magic wand, which may solve all your problems, or it would be better to use another solutions? We will compare two giant players in the orchestration and clusters building area: DC/OS (aka. Mesosphere) and Kubernetes from the developer point of view. Can you predict who will win? So, let the fight begin!

The authors of this “battle” have come a long way from DC/OS to Kubernetes and will try to convey their experience to the audience.

Building a security program at Grammarly. Integrating security in product development.

You are a software developer or engineering leader in a typical internet product or service company. You have web, mobile, or native apps for different platforms, and your backends run in the cloud. You embrace test-driven development, rapid iterations, infrastructure as code, continuous delivery, and monitoring.

But what about security? Someday your users, your clients, or your CEO will ask this question. Maybe there is another breach in the news. Or someone has sent you a vulnerability report to security@yourcompany.com. Wait—do you even have security@yourcompany.com mailbox?

In a big enterprise, someone takes care of security for you. In a growing product internet company, you must implement it from scratch.

In this talk, I’ll show how to begin focusing on practical things that worked for us at Grammarly. We will talk about:

– How much “security” is enough?
– When to build a security team and how to establish roles and structure.
– Working with external consulting and penetration testers.
– How to launch a bug bounty program and make the most of it.
– How a security team interacts with development teams in a non-blocking way.
– What if your DevOps (or NoOps) teams release features and experiments multiple times per day?
– Infrastructure, tools, monitoring, and automation for DevSecOps.

Premature automatization

Automatization is an obviously good, right? I’m not so sure. It can be premature and harmful. It can take your time, harm processes and other teams. I want to share some examples from private practice and overview some trends in premature automatization and optimization.

Practical GitOps on Kubernetes with ArgoCD

We’ll talk about the pros and cons of using GitOps approach on Kubernetes, with an evaluation of major open-source players on the market to eventually come to ArgoCD with practical use cases and real-world demo.

Running MySQL on Kubernetes

Running databases in Kubernetes attracts a lot of attention today. Orсhestration of MySQL on Kubernetes is no way a straightforward process. There are several good MySQL based solutions in the open source world, made by Oracle, Presslabs, and Percona. Having common base, they differ in self-healing capabilities, multimaster and backup/restore support, etc. So let’s make a fair comparison to figure out the pros and cons of their current state.

Consul: Service Mesh

Dynamic infrastructure and microservices is good, but with them come many challenges that can be fixed in many ways. For choose best way we deep dive into causes of problems and understand how we can fix it.

In search of Domain-Driven-Design in the world of microservices

Every team has concerns about using the domain-driven design (DDD). What kind of benefits does it offer? Why is it better than everything they used before? What if we want to use microservices architecture right now or we plan to migrate to microservices architecture any time soon? How Domain Driven Design can help to find answers on all of these questions? Does DDD have anything available out of the box that helps us to deal with microservices and components in our architecture? What about bounded contexts and aggregates and some other options available in DDD? And finally, if we are well prepared right now and use all of the best practices from DDD, how can I migrate to microservices architecture when it is needed? What kind of anti-pattern all teams can face in their journey to Domain Driven Design?

As one of the key drivers of this process, an architect must be able to answer any questions coming from developers, business analysts, and even Scrum Masters. Architects must be ready and well prepared for any type of questions.

I will help you find the best answer to all these questions. I am going to share my team’s journey with DDD from the very beginning of a project and outlines the many problems we faced. I will also cover some anti-patterns to be afraid of and how to deal with them, DDD best practices, and how DDD and microservices ideas can leave together.

I am testing my micro-services and let others test theirs

Today it is very common to hear that micro-service architecture is a way to solve all problems. Scalability, fast release cycle, controllable code evolution, testability etc. Micro-services are well known to be a heaven for developers, QAs, PMs, and business owners. However, those who have already worked with such architecture usually are not that doubtless of the statement. Moreover, when it comes to the real thing – each company has to overcome enormous amount of technical challenges to make it work.

I would like to shed light on testability aspect. How we (at Wix) are testing integration of our micro-services, why it works, and what do you need to know before dive into it.

Pain of ops. Designing for operations.

Operations engineers still complain about the unsupportable applications: it takes forever to move apps to kubernetes; is this app dead or alive?… But developers don’t see the problem. I was on opposite sides of the barricades. This talk is about lessons we learned and how to push the best practices for developers.

Fault tolerant event-sourcing With RDBMS

Have you ever expirienced the situation, when you’ve already persisted data in some popular RDBMS datastore, tried to send message to a message broker, but it’s unavailable at the moment? Sure, you can try to code your own infrastructure – store messages somewhere, wait for the message broker availability, etc… But in such approach you squander money of the project) In this talk I will show you more cheap and robust, in terms of development, approach for fault tolerant event sourcing with examples in C# – so you could focus on the domain of your app.

Observability – the good, the bad and the ugly

We like to collect metrics, possible traces, logs, but there is a lot of failures and anti-patterns in this way. How large enterprises made it wrong and right? How to avoid common pitfalls and how to adapt machine learning to your monitoring.

First secret delivery for modern cloud-native applications

In this talk we’ll see how Authentication and Secrets delivery work in distributed containerized applications from the inside. We’ll start from the theory of security and will go through the topics like Container Auth Role, Static & Dynamic secrets, Env vars/volumes for secret delivery, Vault & K8S secrets. After this talk you’ll get an understanding how to securely deploy your containerized workloads.

The movement steps to the high-load tolerant and scalable infrastructure based on the AWS and Kubernetes

How to move to the scalable and high-load tolerant architecture from the almost monolithic based environment. For the past almost 2 years I have been working as a head of engineering and during this time my company attracted 2 rounds of investments, grew from 30 to 150+ employees, our product covered most of the EU and the infrastructure of course changed a lot too. I want to share a practical experience how to build reliable, scalable and what is even more important – manageable cloud based infrastructure. Ansible, terraform, kubernetes and many of the AWS services are our current reality. This topic is really huge and I think that it may take much more than one conference session to uncover it, but even the concept can be very helpful to those who are at the beginning of their journey.

Low Latency Data Processing in the Era of Serverless

We have entered the Era of Serverless. Do you want to spend time on growing the complex infrastructure and its administration or you focus on validating your hypothesis and delivering what’s needed right here and right now? This is a question you should ask yourself in 2019. Effectiveness is the answer. In this talk, we will see how easily you can build a low-latency processing layer for the Lambda Functions using the Hazelcast Cloud – a fully managed Hazelcast IMDG service.

Cowboy dating with Big Data or evolution of data platform in action

Story of one project where people used big data with no idea how to cook big data. We will run through pitfalls and bad practices to find right path.

Why startups need SRE practices

In Prisma we process more than 500k photos per day on the server. I would like to present why SRE practices are needed in a small company, how to implement them without pain, why it pays off, and how we reduced the number of incidents.

Seven Cloud Sins of DevOps

Cloud computing is widely used by industry for more than a decade. There are many patterns, best practices and tools around it including DevOps, despite that, they do not prevent from shouting yourself if misused.

This talk is a summary of practical experience and observations about top-most misuse of DevOps practices when applied to cloud software engineering and operations. AWS Cloud provider is used for cases examples.

Self-healing in prod do you really need AI for that?

When you deal with production, idea of self-healing sounds really attractive, or maybe your VP is claiming that all his peers already doing AI, and we should do the same.

Doesn’t matter what is the reason – but there are big chances that you don’t need AI/ML, did you consider “control theory” already? Do you already have closed loop controllers and PID-controllers?

After the this talk you will get an idea of why AI is not really necessary, and in some cases it can even harm.

Support as a service for development. United we stand.

True story of the year-long successful applying “Support as a service for development” strategy in Product company with split US/UA teams. It is not surprising, that most significant part of the success story was understanding of the problems in relationships between the teams and finding the root causes to fix it. Almost like with the bugs. 😉

Hiring support-minded persons, understanding the main values and goals, building T-shape communications will de also covered. I will share my experience with the tools used to provide constructive feedback to developers. Pain points and insights during the journey are included.

Javatar declarative pipeline for continuous-delivery – Jenkins pipeline shared library

Build quality into your µServices with jenkins declarative pipeline. Session has lots of demos with open source jenkins shared library, that aims to help you with quick setup of your project delivery lifecycle.

Attendees will learn how to build open source and free of charge CI/CD pipeline that could help many projects to speed up CI/CD integration using Jenkins. Pipelines works fine with different build tools & languages, from npm (angular, viewjs) to maven/gradle (java). Javatar declarative pipeline is Jenkins shared library that ease integrates securely with your infrastructure.

How to build & support high load REST API

I would like to tell the story of our experience of building the HighLoad REST API that has the following parameters:

* Intuitive.
* Scalable.
* Fault tolerant.
* Protection from attack.
* Perceptive.
* High bandwidth.

Also I would like to describe:

* how we did LoadTesting;
* how we survived a lots of DDoS attacks;
* how we did deployment without downtime.

The following list of technologies were used: .NET Core 2, ASP.NET Core 2, Consul, Fabio, Orleans.NET, Kafka, RabbitMQ, Serilog, xMetrics, Grafana, ELK.

Tracing for Java Developers

You are already using logs and metrics to monitor your applications. Why should you be adding tracing or Application Performance Management (APM)? This talk gives a hands-on overview of:

* What you can (not) do with tracing.
* How you can easily add tracing to your Java applications.
* What OpenTracing (or soon OpenTelemetry) adds to the landscape.

The demo is using the open source Elastic APM agent with its OpenTracing bridge, so the general concepts widely apply.

Zero-downtime deployment with Kubernetes, Spring Boot and Flyway

Kubernetes allows a lot. After discovering its features, it’s easy to think it can magically transform your application deployment process into a painless no-event. For Hello World applications, that is the case. Unfortunately, not many of us do deploy such applications day-to-day.

You need to think about application backward compatibility, possible rollback, database schema migration, etc. I believe the later is one of the biggest pain point. In this talk, I’ll demo how to update a Spring Boot app deployed on a Kubernetes cluster with a non-trivial database schema migration with the help of Flyway, while keeping the service up during the entire update process.

Changing The Game: Leveraging Game Theory to Transform Your IT Organization

As organizations begin the process of digitally transforming they will often struggle after initial efforts at automation (the dreaded J-curve). In this session we’ll discuss why the J-curve phenomenon occurs and define the concept behind the Pareto Inefficient Nash Equilibrium through a game show called “Golden Balls”. In this entertaining segment we’ll discuss how you can introduce this concept to effectively change the game and push past the low-end of the J-curve.

The journey doesn’t end there, as organizations begin shipping changes more often, introducing new features, services, and dependencies complexity begins to rise. This often results in teams forming centers of excellence around reliability and availability. We will talk about how Site Reliability Engineers enable organizations by accelerating into the upper end of the J-curve through leveraging observability to effectively establish error budgets, SLOs and SLIs. We’ll discuss how SRE teams can leverage distributed tracing aggregates, system metrics, and log analytics to effectively measure “all the things” and the value this measurement brings to engineering teams through visibility, communication, and accountability.

Joining the Mob

Software engineers historically have largely worked alone and in a vacuum on key projects. This has caused problems with transparency, creates knowledge towers, increases technical debt, and stifles innovation. Mob Programming has given Clearlink solutions to all of those problems and created benefits that have been unforeseen during our first two years of adopting the practice. From our experiences, we outline some best practices that will be beneficial to all those who wish to also adopt this technique.

Complex Application Design

It is pretty simple to design a back-end API, a demo UI for the API or wrap an existing web app into a mobile app. However, building a complex consumer solution requires much more. In this talk we will walk through the steps of design of such complex solution based on real-life examples from personal experience. This will be a no-code session. We will be focused on the work of an architect in the life-cycle of the product, spanning to various areas that should be covered in order to gain success.

Securing applications and infrastructure with Vault

Making sure our systems are secure has become a huge priority for companies but not everyone actually dedicated the time to making it happen.

In this session, Paul will demonstrate examples of how to secure infrastructure and applications to have end to end TLS using Vault.

He will be able to prove to attendees that by investing a little time upfront, we can ensure that our development and production environments have TLS throughout and will allow us to not get surprised when our systems go to production.

Can TypeScript really make infrastructure management easy?

In this talk, Paul will demonstrate why TypeScript is a great language of choice for infrastructure management. Pulumi is an open source tool that allows users to write their infrastructure code in TypeScript, Python or Go.

TypeScript allows infrastructure code to have integrated testing, compile time checks as well as being able to create infrastructure APIs. This will show why a real language is more suited to infrastructure management than DSLs, JSON or YAML. In addition, he will cover how to build infrastructure that manages Serverless, PaaS and IaaS systems across multiple cloud providers.

Think Big, Start Small, Learn Fast: from small R&D to Cutting Edge, implementing Continuous Innovation

Long story short, every work has its begging and the end. Every project begins with something and ends up at some point. In case we don’t want to follow the stream, – we should create innovations and start new directions. Let’s make a journey and reach all the checkpoint we need to make the continuous innovation happen. Step by step we will solve different cases in the state of uncertainty to achieve our goal being the leader of innovations.

Kubernetes CI-CD Frameworks Case Study

A set of flexible and comprehensive operation principles to cover all stages of a modern application life cycle.

Almost any Customer wants the Setup to be compatible with existing infrastructure. It assumes a Bare Metal, Private or Public Cloud. In special cases even offline setup, for example, Airports, Fintech sector or Telecom operators. The main requirements are: Scalability, High Availability, Security Compliance, Professional Service.

So, we should cover all three tiers: Infrastructure, Control Plane and Application Plane. Market leaders are Drone, Argo and Knative. And our story we called Cloud Flex Framework.

Learning the Three Types of Microservices

Microservices is a popular, but vague term. And — it turns out — definitions of microservices can vary, depending on what you want them to accomplish and how you want them to communicate with each other. So, just what are the three types of Microservices, what makes them unique, and when do you deploy each of them?

In this wide-ranging talk, you’ll learn the difference between Stateless, Data-Centric, and Aggregator microservice models, how to identify which one you need to build, and the challenges to keeping each of the up and running in a complex distributed system. You’ll also learn how to apply Nygard’s Stability Patterns (from his book, “Release It!”) to ensure your Microservice components are stable and resilient throughout the software lifecycle.

Whether you are new to Microservices or a veteran, a software developer or enterprise architect, this talk will help you get a handle on how to design and build successful Microservice components for you organization.

Continuous API Management

A lot of work is required to release an API, but the effort doesn’t always pay off. Overplanning before an API matures is a wasted investment, while underplanning can lead to disaster. This practical guide provides maturity models for individual APIs and multi-API landscapes to help you invest the right human and company resources for the right maturity level at the right time. How do you balance the desire for agility and speed with the need for robust and scalable operations?

Based on the newly-released O’Reilly book “Continuous API Management”, this talk covers :

* Learn which API decisions you need to govern and how and where to do so
* Design, deploy, and manage APIs using an API-as-a-product (AaaP) approach
* Examine ten pillars that form the foundation of API product work
* Learn how the continuous improvement model governs changes throughout an API’s lifetime
* Explore the five stages of a complete API product life cycle
* Delve into team roles needed to design, build, and maintain your APIs
* Learn how to manage your API landscape—the set of APIs published by your organization

CI/CD Infrastucture as a Code

This talk is about how we integrate Jenkins with LDAP, Nexus, Nginx, Docker Swarm, Terraform to bring re-usable self-service CI/CD development platform delivered strictly from sources and why we use this set as a single point of integrations. Some insights on our open source project “DJEG”: https://github.com/shalb/djeg.

DevOps Types and Anti-patterns

This Topic is based on true story and originates from a number of circumstances that served the birth of what we call devops today.

In June 2009, at the O’Reilly Velocity conference, John Allspaw and Paul Hammond presented the speech “10 Deploys a Day: Dev and Ops Cooperation at Flickr.”

The presentation had a amazing effect. Allspaw and Hammond in roles play a controversial interaction between design and operation. The usual deployment scene of application deployment with all the stuff like, “This is not my code, these are your servers!”.

Only rational way forward is when application development and operation are seamless, transparent and fully integrated. Over time, this presentation has reached legendary status and is historically regarded as an important moment that brought to the IT industry the methods that we now know as DevOps.

In 2013, Matthew Skelton presented us the work of web.devopstopologies.com. This is a kind of collection of anti-patterns and best practices for building communication in teams.

I offered to grant the right to use the materials and make a report adapted to Ukrainian realities and my personal experience. Matt kindly agreed.

Speech format was made more interesting than just a set of slides and a retelling of the source: graphics and characters from Ukrainian artists, javascript animation, high-performance http server in pure assembler, Kubernetes cluster on Raspberry Pi. I hope you will enjoy it.

Sustainable system testing with Chaos

Chaos Engineering is methodology that experiments on a distributed system in order to build confidence that the system will work well in production. Essentially, we experiment by trying to break our system to uncover system weakness.

In this talk, Paul will cover the basics of Chaos Engineer, give some case studies of companies that currently do this in production and give an introduction to some of the open source tooling that currently exists so that you can maybe try this at your company. Paul will also show that, by following good infrastructure management practices, that you can recover and scale the system when necessary, easily!

DIY Kubernetes identity provider. The Hard Way with Dex and LDAP.

The idea is to help Kubernetes users to understand basics of authN and authZ, OIDC flow, mechanics under the hood, and to show how to build production-ready identity management and audit log of Kubernetes clusters, combining tools from both worlds – the old one (LDAP) and the brave new one (Dex, dex-k8s-authenticator).

On the road to 6.9k. How to succeed in technical interview.

The talk about the technical knowledge that is required for modern DevOps and SRE engineers. It’s based on more than 100 technical interviews performed last year. The questions and answers that could be useful to identify experience on each technology field. What is the “required minimum” in each stack? What books blogs and articles should be studied to become DevOps professional?

Good Service: Detect and avoid errors in the world of microservices

Nothing is worse for your service’s reputation than being unwittingly down.

The developers at FINN.no are building and operating four hundred microservices to power Norway’s largest online classified ads site. There is no dedicated operations team, yet almost every major incident is limited to a few minutes of reduced service.

After a long road filled with adjustments and various initiatives to introduce monitoring across teams and domains, we have found a solution that works for us.

Learn how FINN.no builds nuanced real-time monitoring into a fleet of several hundred services; what to measure, and how to detect and isolate errors within seconds; and how to respond when something goes wrong.

BOF: Web Security. Level Up^

With exponential growth of internet usage and impact it has for our lives nowadays the importance of security becomes extremely more and more valuable, especially if we take into account number of users with closed to zero experience in IT and with limited knowledge in security.

That means we’re as engineers who create modern applications should take responsibility to make them more robust and secure.

In this talk I’m going to explore security topic for broader developers audience and share simple but yet useful strategies, tactics and techniques to help to make applications we create more secure.

DevOps ICU: Improving DevOps Results by (Correctly) Integrating UX

UX is driving you crazy, a black throwing off timelines and killing ideas. UX doesn’t seem Lean or Agile. Can’t anybody make wireframes? Can’t we circumvent or exclude these people?

DevOps is about so much more than how developers connect with IT, how infrastructure is managed, and how frameworks can be improved. It’s about recognizing how many teams are truly involved in the software development process and finding better ways to make sure everybody is at the table.

This session will explain how the UX process fits into Agile; saves companies money; augments DevOps goals; and increases customer satisfaction.

BOF: Building the search engine: from thorns to stars

In the company I have built search engine based on ElasticSearch and distributed system of data import. I would like to share my experience and speak about the following topics:

– What the search engine is and why it’s needed?
– What platforms exist to choose from?
– ElasticSearch and its capabilities.
– How to ensure continuous data flow?
– Maintenance of data consistency.
– Reduce to a minimum effort needed for search extension.
– Lessons learned.

BOF: Myths and truths about Dependency Injection

It’s 2018 and DI is a well-known and established technique on all major platforms and languages. So why can’t we still have a clear answer to the questions like ‘is DI/IoC container a mandatory thing to apply DI?’ or ‘what is a true way to implement DI in language/platform X?’ or ‘is it even a good/useful thing?’. Let’s find those answers together and refresh our memory on the initial goals and targets of DI and its surrounding design patterns.

Service Mesh – Why? How? What?

Service Mesh. What does it mean? We have already learned Microservices and can develop complex distributed applications. Is Service Mesh something we need or is another fancy buzzword?

This talk, will give an idea of what a Service Mesh is, how it is applied to existing architectures and will help you to understand if you really need it.

Why you should not start an Agile transformation

Agile is a buzzword these days. Everyone wants to become Agile. And vou la your company is already in the middle of an Agile transformation. Why? Well. All articles/talks/rumors say how awesome it will be there.

But I would like to share another story. One that is hard to hear. The dark and the sad one. What downsides you will experience on that journey. How it will negatively affect your business. What will be your losses. And how not to make this situation even worse.

I do not want to blame Agile here, instead I want honestly to take a look at the dark side of the Moon. Forewarned is forearmed.

Continuous Delivery with Jenkins declarative pipeline

When you start your journey with µServices, you should be confident with your delivery lifecycle. In case of mistake, you should be able to navigate to appropriate tag in vcs to reproduce the bug with a test & go though pipeline within 3 hours to production with high confidence of quality.

We will discuss set of tools that could help you to achieve this within 3 months on your project. It does not include system decoupling suggestions. And in the same time, if you decide to break down monolith, it is better to do with dev & devOps best practices.

Demo examples will include among best practices some code: jenkins pipeline code is written on groovy, µServices is on spring boot, Dockerfile, mesos configurations, angularjs SPA. Tests: unit, integration, component, system (or selenium in case of UI), performance (Jmeter extended on fly with java & groovy code, with grafana dashboards that used influxdb), database backward compatibility testing, rest contract testing.

Also will be covered practices how to do Continuous Delivery for UI SPAs without harming each tenant,
customer may decide later what version of UI he want. Cloud configuration will have this information & on the fly will be ready to change behavior for the customer.

All these practices will help you deliver a lot without a harm 😉

Ultimate journey towards real-time data platform with 2.5M/s

The story is about pain and enjoy or how we built realtime data platform with 2.5M events per second. What challenges we faced and which lessons were learned. Step by step we will introduce technologies we use like Spark, Presto, Kafka, AWS and EMR and best practices we come up to like monitoring, deployment and scaling.

Bid for Your Instances!

Amazon EC2 allows you to bid for and run spare EC2 capacity, known as Spot instances, in a dynamically priced market. On average, customers save 80% to 90% compared to On-Demand prices by using Spot instances. In this session, we dive into how to design scalable, cloud-friendly application architectures can leverage new Spot features to realize immediate cost savings while maintaining availability. Attendees will leave with practical knowledge of how, via well architected applications, they can run production services on the Spot instances.

Events Processing up to 1.6 M/sec

I’ll talk about evolution of our event-processing system. Will cover details of initial implementation on Spark + Hadoop, overview it’s problems, and tell about benefits we’ve got by replacing it with ClickHouse.

Immutable Database. Safe Way to Migrate Large Data Stores.

Relational database schema migration is a procedure familiar for everyone: add a new field, create transformation script, run it, several seconds of waiting and done!

But what if the data volume is bigger than 1 TB or even 10+ TB? How to guarantee high availability of the storage? How not to miss the updates? What if something goes wrong during migration? Who wants to be responsible for the downtime of a 24х7х365 system?

In this talk, we’ll take a deep dive into an approach for safe large-scale data migration, that we use in YouScan to evolve multi-terabyte Elasticsearch cluster. You will understand what role do DevOps culture and Immutable Infrastructure principle play in this approach and what additional benefits it could bring.

DevOps applied: survival guide

Practical success story for building DevOps culture in Product company within classical development team from scratch: growing t-shaped skills, knowledge sharing practices used, tools to build efficient delivery ecosystem.

How we tried Kubernetes and how we are now rewriting our application

The recipe for transition of functionality blocks from monolith to microservices: take Kubernetes, add the microservices, season with DevOps metrics and culture and get an excellent transformation of the architecture of your application.

We’ll talk about how we got Kubernetes, what problems we solved “out of the box”, practices on the choice of strategy for moving monolith blocks, how the DevOps culture changed in the development teams within this transition.

We will share the experience of interaction between the architectures of multi-tenant and single-tenant solutions that appeared in the process of changes. How teams created metrics for new services and how, consequently, the work processes changed.

Does one need to react to such metrics and how soon? What should not one take out into microservices? Why did we decide like this and why we don’t want to? We will tell about the experience of using such services in production, share success stories and experience in supporting such solutions.

XP practices implementation for large product development team

We want to share our experience in implementing a wide range of XP practices within the generated product and how they influenced the development processes and the functional quality. We will:

– compare the practices that gave the greater result and those that were less successful;
– consider the difficulties in implementation at different stages and which solutions were applied;
– describe what tools were chosen and what changes the platform underwent to enable the use of any of them in all development branches;
– tell how and where we increased the competence in the use of different approaches and how we scale knowledge to the entire development department;
– speak about the changes in the release of functionality processes and team work planning;
– share our plans and impressions why, in our opinion, it is worth going through the hard way of XP transformations to anyone who is engaged in the software development.

Conway’s transformation for legacy product

The talk is about a real experience of organization transformation with 15 years old legacy monolith project into DevOps oriented, microservice-based modern company. On our way, we have grown from 40 to 80 engineers for the last two years. We have x20 increased delivery of the old main project and implemented CD for projects and processes.

Azure way: from PaaS to Containers.

Azure is a mature cloud provider, offering many deployment options for your services. Clients can choose between them according to their scalability, maintainability, availability and pricing needs. In this talk Serhiy will share the evolution of deployment models used by small software development company for different custom project. We will discuss pros and cons of each, and how to proceed to the next level without pain.

The art of data engineering

As the the data space has increased, data engineering has emerged as a separate and related role that works together with data scientists. Usually data scientists focus on finding new insights from a data set, while data engineers are concerned with the production readiness of that data.

In this talk I’ll show you how to gather and collect the huge amount of data, stores it, does batch processing or real-time processing on it, and how to build data pipeline using Airflow for processing billion of records per table.

Also we will discuss what is big data, and why it’s important to be able to process it so quick.

Serverless design patterns

Join Yan in this talk to see how you can implement architectural patterns such as pub-sub, push-pull, cron, saga and decoupled invocations, and understand the trade-offs of each event source so you can use them to your advantage!

The motivation for this talk is two-fold: 1) to show the audience to some common design patterns that they can quickly adopt, but perhaps even more important 2) to expose the audience to a framework of thinking about the tradeoffs and failure modes with their choice of event sources for Lambda – eg. SNS creates a concurrent execution for Lambda for each message, which makes it a great choice when you want to maximise parallelism, but a terrible choice as a queue between services (to amortise spikes in upstream traffic).

Serverless in production, an experience report

In this talk I share my experience of migrating an existing monolithic architecture for a social network to AWS Lambda, and how it empowered a small team to deliver features quickly and how they address operational concerns such as CI/CD, logging, monitoring and config management.

This sessions draws on my experience leading a team that transformed our entire architecture in under 6 months, where we also managed to cut cost by over 90%, and increased production deployments from 4-6 per month to 80-100 per month. We did that whilst coming up with solutions to those common operational concerns to ensure we not only run a serverless architecture in production, but we do so responsibly.

Scaling data ingest to 20 billion messages/day with GDPR requirements

I’m a DevOps engineer at Anchorfree. We collect a lot of data from our servers and clients since we have one of the most popular VPN services. Recently we faced a challenge to apply GDPR cleaning on our data, while at the same time we had to scale up to 20 billion messages/day (2TB of gzip-compressed per day). These requirements led us to major architectural changes after many iterations of prototypes and benchmarks. So I’d like to share my experience in the mentioned scope, good and bad architectural decisions under requirements of high load and GDPR.

Infrastructure under test in Openshift

This talk will cover the usage of REST API in Kubernetes and Openshift for test automation.

Main points:

– Kubernetest base concept if it will be needed.
– Radanalytics.io.
– Benefits of Openshift.
– Automation of deployment in Openshift.
– Fabric8-kubernetes-client, XTF, radanalytics-utils as libraries for Java.
– Demo of Java code for deployment and management application under test, in the Openshift.

Function as a Service in private cloud

In my talk, we will have a look at Function as a Service in Alibaba private cloud. FaaS gives our developers a freedom from the DevOps world. Now they are spending time exactly on development. Serverless also significantly reduces the number of microservices in our deployment.

We will go through the difficulties that we’re facing developing and optimizing the platform. We’ll talk about how to provide the most comfortable and effective environment for the functions’ developer. I will overview the point of choosing Kotlin for such a solution and the most valuable language features.

How to write Terraform code which will not scare you in half-year?

Many of us know and use Terraform already but there are no best practices, and each team has to invent their solutions.

An infrastructure almost always starts with few resources and few developers. As time goes, it grows in all possible directions. You found your ways around grouping resources into Terraform modules, so what can go wrong? (famous last words)

After three years of maintaining an open-source collection of Terraform AWS modules and long-term usage of Terraform in production, I want to share my experience and explain how to write Terraform code which will not scare you in half-year… (or when Terraform 1.0 is out)

This talk is best for people who have already read official documentation, use Terraform and have practical questions.

How to build Performance Testing solution of Blazemeter level for Free

Performance testing analysis, as well as application/server problem investigation, have never been easy and quick. However, here in Thomas Cook, we were able to improve and simplify the given above processes. Just through some modification/configuration of open-source solutions such as JMeter and ELK-stack tools we able to build performance testing reporting framework which can do the following:

– Easily find Bottlenecks on Script level, Business transaction and request level.
– Get to raw request-response trace of failed transactions just through several clicks.
– Get separate statistics for business transactions spread among several scripts.
– Visualizing in a representative way.
– And much more…

Join our talk to look at everything listed in action!

Microservice Testing With Ease Like A Breeze

In this talk I would like to share deep knowledge and experience about Microservices testing approaches that work in Thomas Cook organization. We will talk about business and technical background, Microservice testing in release pipeline, types of verifications, tools used, typical problems, responsibilities within team, Test automation and performance. General understanding how to do Microservice testing from A to Z.

Event-Driven Systems With MongoDB

MongoDB is popular choise for data persistence which had no support for ACID transactions up until v4. Even having such support, transactions incurs higher performance cost and can lead to deadlocks.

In this talk I will explain challenges of achieving data consistency in systems that does not support AСID transactions, how to communicate state changes in a reliable manner and the approach to ensure eventual consistency of data with examples in C#.

How to setup TDD in a service company

TDD is a brilliant technique which is easy to understand but hard to implement as a part of SDLC, especially in the world of C/C++ development outsourcing.

At a product company meetup I attended several years ago, the general outlook was that it’s impossible to use the TDD technique in outsourcing. The technical interviews held at our company tended to confirm that as well.

Since then, we have persistently tried to rectify that and seem to have finally found an exciting way we’d like to share with the community. Hopefully, we are going to start a discussion and even provide some ideas for making the process of developing a better software more straightforward and enjoyable.

Cloud Migration. Lift-and-shift. Really? Don’t be naive!

I will talk about how we tried to move our products from Rackspace Cloud to AWS in the least disruptive way and about the hindrances and disillusionment we experienced trying the lift-and-shift strategy.

CI/CD on pure AWS

In this talk I will show you how to build a CI/CD pipeline in AWS with, static code analysis in Sonar, tests and continuous deployment of a dockerized service through several environments by using pure AWS services like CodeStar, CodeCommit, CodeBuild, CodeDeploy and CodePipline. I will do a demo of such CI/CD to reveal all guts of tools and services integration and implementation. So you will see how a commit will be going through all those steps and tools to get production environment.

SLA, SLO, SLI, Error budgets, or how to keep calm and do your job

Those who have read SRE book, noticed those abbreviations, but mostly nobody actually started using on a daily basis. At AnchorFree, we have several thousands of nodes, and hundreds of services, we have 3 SRE teams dealing with all of this with reasonable success.

In this talk I’m going to describe how Core SRE team implemented SLO and error budgets on practice, what where our pitfalls, and how you might try to do it yourself. Should you even bother?

DevOps checklist or how to understand where is your team in DevOps landscape

DevOps is a hot topic during last several years. Some companies, teams and products have achieved quite impressive results in this area making cultural changes, transforming their processes and practices, introducing new roles, tools and techniques. At the same time there is no common approach for measuring achievements and understanding “how DevOps” the current team/company is. In this talk I will provide attendees with basic checklist to start with and some reliable tools/techniques to monitor progress of “DevOps transformation”.

Continuous static analysis or how to keep your code healthy without waste

Frequently we have a deal with “legacy code”, full of bad smells, anti-patterns and potential defects. We gather and manage Technical Debt to get rid of such code where possible or at least improve it somehow. This is usually very wasteful process, because knowledge is lost as time passed, context of changes is unclear and code is not protected with reliable tests. In this talk we will go through more efficient approaches, supported with appropriate tools and practices, to make code care a continuous process achieving controlled balance between speed and code quality.

Live Kubernetes Debugging with the Elastic Stack

Your Kubernetes app is down. Your users start ranting on Twitter. Your boss is standing right behind you. What do you do?

This talk walks you through a live debugging session without panicking:

* What do your health checks say?
* Where does your monitoring point you?
* Can you get more details from your application’s traces?
* Is there anything helpful in the logs?
* What the heck is even deployed?

We are using the open source Elastic Stack in this demo with a special focus on its Kubernetes integration with metadata enrichment and autodiscovery in combination with APM/tracing, metrics, logs, and health checks.

Official Docker Images – Lessons Learned

If you want to be taken seriously, you need to provide containers to your users. It’s easy — everybody is uploading containers to Docker Hub, right? Unfortunately, reality is never as easy as it sounds at first. This talk gives an overview of Elastic’s ongoing journey to providing official Docker images:

* Docker Hub: What “official” really means and why we are using our own registry.
* Base image: Just use Alpine — it is small and the perfect fit for containers. We tried that and reconsidered…
* Release policy: What do you actually get in a specific tag and how are we releasing our images?
* Support: Combine two complex systems like Elasticsearch and Docker — and you will get a lot of questions.
* Orchestration: Our current approach for orchestration and how we are treating feature requests.

Bots on guard of SDLC

One of the most boring thing in software development in large companies is following a bureaucracy. Tons of developers were melted down by that ruthless machine with its not always obvious rules. That’s why we decided to delegate all the boring work to machines instead of humans and the talk will cover the achieved results.

Continuously delivering infrastructure to the cloud

Building infrastructure in the cloud is a different paradigm to that of physical data centers. The infrastructure we deploy today has no guarantee to be there tomorrow. You therefore need to change how you design infrastructure.

In this talk, Paul will look at some real world examples of how to deploy infrastructure to the cloud that self heals and is scalable to withstand 3rd party provider outages. This should help you think about ways to avoid that 4am pager alert.

Continuous Delivery Adventures in .NET

There is a lot of tools to build the continuous delivery solution. Most of them are universal, some are platform / technology specific. Serhiy has been building and supporting various CD solutions for .NET web applications for the last few years. For a number of reasons different tools, products and approaches were used. It was a good experience that Serhiy would like to share with you.

In this talk we will review different options for code review, CI, versioning and deployment. We’ll discuss pros and cons of each, take a look at corner cases and non-obvious features. And finally we will try to choose an ideal (or close to it) set for .NET applications.

Continuous Delivery with Drone

Hi! My name is Vadim and my presentation will cover a rather young but very promising Continuous Delivery platform named Drone. I will also share some experience of using the platform in our company. The project has already outranked Jenkins on GitHub and is currently under active development. The main features of the platform, that are available out-of-the-box include the following:

* Each build step is completely isolated and is executed in a separate Docker container;
* Pipeline as a code approach (no need to install dependencies and configure CI-server manually);
* Language-agnostic plugins to extend the platform functionality.

Technical backlog for non-functional requirements

Usually, business focuses only on features, as result only functional requirements are defined. Development team should be more proactive with non functional requirements, because business don’t have required knowledge and expertise. For it is better to use an additional tool such as technical backlog.

Transformation practices

When the team is shifting to product development style, leader (or manager) faces typical problems. And for many years of building and transforming teams, each leader compose sets or frameworks of practices that allow him to succeed. I want to talk about typical problems and practices of their solutions: about product mindset and design thinking, about mentality and legacy, about evolution or revolution of development processes, about architecture and refactoring, about testing and delivery, coding and support. With each of these areas the leader lives every day in “cheek to cheek” mode and solving transformation problems. Hope my experience will helpful for you.

Docker as a key to success in deployment of large-scale IoT environment

I would like to share our story and experience in deployment process migration of hundreds IoT devices from semi-manual to fully automated with Docker. In addition I will demonstrate some useful open-source projects, that could help you remotely monitor and interact with applications inside Docker containers.

Top-10 fails on real highload project

In this talk I’m going to present experience, that I have achieved together with my team through pain on real highload project with millions of users. I will cover 10 hot stories:

– wrong selection of id algorithm, that almost led to closing of project and wasting of 2 years of development;
– fighting with over, over, overloaded MySql servers when turning replication on kills server;
– cleaning of partitions in MySql that caused server outage;
– HTML coder that changed design and instigated downtime for 4 hours;
– lack of knowledge of internal logic of Redis costs $50k;
– adding and removing servers from Memcahced pool starts full cache invalidation;
– fix of test and millions lost emails after that;
– release of one projects crashed another project;
– the biggest fail in design of message broker.

Your tests will ask you to repeat. Scalable immutable Selenium infrastructure.

Once any company get WebDriver tests, or applications utilizing the WebDriver protocol, engineers of this company should think about stable Selenium infrastructure. But usually setting of scalable and really stable Selenium Grid becomes a nightmare for months. More than that, this process usually can’t be reproduced in local environment. This talk will be about the tool, named Selenoid, which brings ability to setup scalable immutable Selenium infrastructure utilizing containers even on your laptop.

Move Fast and Consumer Driven Contract Test Things

At SoundCloud, we’ve found that teams move faster when we’ve moved away from a monolith architecture to one based around microservices. Unfortunately, this new type of architecture has been prone to cascading failures when breaking changes go unnoticed in one of our services’ API’s. These failures have had a devastating impact on our system’s uptime, but we’ve found that we can mitigate some of this risk by introducing consumer driven contract tests.

Consumer driven contract tests allow each consumer service and client to define their expectations and interactions with each provider service upstream, and for provider services to verify all of these contracts as part of their build pipeline. Breakage avoided.

In this talk we’ll go through SoundCloud’s process of breaking the monolith into microservices, then see how PACT-based contract tests were introduced, and discuss some of the challenges of adopting such tests in an already-established microservices culture.

Microservice resilience testing with Docker & Pumba

In addition to brief overview of well known approaches for resilience testing Oleksii will share his own experience along with practices, methodologies and tools, that Oracle UGBU applies for resilience testing of Java microservices.

Docker and Pumba will be used for live demo session. Following topics will be covered in details:

– how to do an automated testing of self-healing ability of the distributed system;
– how to analyze the behavior of the system when certain nodes are not available or latency has increased.

Building with Terraform

Waisting your time with Configuration Managers? Bored with Ansible or fucked up with Chef? Try new DSL… yaml, yaml, yaml.. Terrrrrific Terraform! Describe what you want and this stuff will bring it on! Spend your time on porn, not on building environments! 😉

FRP: What does “declarative” mean

Despite the fact that programming has been improved dramatically for last years, we’re still experiencing the same problems as 10 years ago.

Modern garbage collectors, smart pointer, thread dispatchers have made developer’s life much easier… Almost made…

Although the deadlocks, race conditions, memory leaks and random crashes occur less often than ever before, the time we waste on solving each issue is getting more and more.

In my talk, I’ll introduce different (very old actually) look at programming: the declarative paradigm. And it’s not about “how to use it properly and get the problems above rid off”. It’s about “how to think to use it properly”.

On real examples, I’ll explain how we can interpret imperatively written code into “Graph of dependencies” and then convert it to declarative FRP style. It’s not only about the “states”. It’s about sequences of operations also. I’ll introduce some patterns of asynchronous programming like Future and Stream (aka Signal) and explain how effectively they may work.

Metrics: howto (for ops and dev)

From this talk you will understand what metrics are important, how to create perfect alerts, why do you need to spend your time on building metrics. Also we will review in this talk some math, visualizations and cross team communication hacks.

Think in events

Tired of fancy abstractions without actual down to earth implementation? In this talk we will go through some benefits of having event-sourced model on a real example. This is full-time live coding and we will start from a simple Spring Boot based OOP application and turn it upside down with events. Basic knowledge about DDD and/or OOP is welcome!

Fighting with Waste Driven Development: Lean Thinking for Software Developers

As developers, we often complain about the efficiency problems we face while working. We work hard but produce so little that our whole development life turns into a hamster wheel at some point. One of the biggest reason of such a common problem is working in waste. Waste is in everywhere, in our source code, in the office, in our processes and even in management. In this session, we will cover all technical aspects of software development, including code, tests, deployment strategies, coding standards, automization points, code comments, bug fixing procedures, living with technical debt, etc. I will talk about all the wastes we produce while developing software and how we can remove to make our development life leaner.

Git Anti-Patterns: How To Mess Up With Git And Love It Again

Git is one of the most powerful tool in developers’ toolbox. If you use it correctly, it dramatically increases productivity of developers and eliminates the waste products continuously. Developers cultivate a development culture on top Git most of the time.

It’s powerful but its power is untamed. Many teams fall into several traps of misusing commands and therefore feel uncomfortable while using Git. We mess up Git history, the codebase and the whole preferred branching strategy in seconds. We use branches, merge/rebase strategies, creating commits in wrong ways. Even we never take committing paradigms into account while using Git.

As a software craftsman, I’ve been using Git for years and I’ve already educated Git to hundreds of developers in all levels. I’m so lucky; I had a chance to experience huge amount of anti-patterns in time. In this talk, I will talk about what those anti-patterns are and what should we do in order not to fall into them.

Cloud Cost Optimization Techniques and Hacks For Enterprise Apps

The promise of “the cloud” is that you can get as much as you want, when you want it, and only pay for what you use. But is that the reality? The reality is an inconsiderate usage that leads to exorbitant costs is more common than you think. That is why in this session you will see techniques and even some hacks that bring the promise of the cloud to reality.

This presentation is a practical look at real world Cloud stories that will answer many of the questions people have about moving to the cloud and getting the best configuration for optimal performance at the lowest possible cost.

Can you keep a secret?

Every enterprise system has tons of sensitive data like database passwords or third-party API keys. Quite often people store this data openly in internal repositories, continuous integration pipeline or configuration managements systems. The bigger company the stricter security rules. It is more complex and important when you have thousands of different applications and each one has its own secrets. In this talk I am giving an overview of my personal experience on Vault technology and will show by example how you can build your own policies and move your secrets to the Vault.

Teaching Elephants to Dance

Feeling bludgeoned by bullhorn messaging suggesting your monolithic behemoth should be put down (or sliced up) to make way for microservices? Without question, ‘unicorn-style’ microservices are the super-nova-hot flavor of the day, but what if teaching your tried and true monolith to be a nimble, fast-dancing elephant meant you could deploy every week versus every 6 to 9 months? For most enterprises, weekly deployments (or something close) would fundamentally transform not only operations and business results, but also the inherent value of developers willing to step up to lead the dance lessons. See beyond the hype to understand the deployment model your business case actually demands, and if weekly deployments courtesy of a dancing (or flying!) elephant fit the bill, love the one you’re with as you lead the organization’s journey to digital transformation!

Origins of Serverless

Serverless is new trend in software development. It’s confusing many developers around the world. In this talk I’ll explain how to build not only crop images or select data from DynamoDB, but build real application, what kind of troubles are we should expect, how to make decision is your task fit into serverless architecture in Python or may be you should use, general approach. How fast serverless applications and more important how to scale it.

Collaborative Development: The Only CD That Matters

In today’s increasing business need for more deployments, continuous testing, and better quality code, one thing that is not explicitly discussed is a strategy for how software teams should collaborate across their company. Before you invest all your time and energy into Continuous Integration or Continuous Delivery, make sure you have a solid foundation of Collaborative Development. In this talk, we’ll look at some collaboration patterns that have had success, why they’re important, and how you can adopt these patterns within your own software development teams to build software better tomorrow.

ChatOps: How to Enhance Your DevOps Workflow

Have you been told that your company is moving to a more DevOps development culture, but you have no idea what that really means? Everyone wants to run a more productive and agile engineering team by balancing the competing priorities of rapid releases and stable systems. DevOps is a movement that everyone is either wishing they had, talking about setting up, or getting ready to implement. But how does your company chat client fit into this and how can it help speed things up?

In this talk we’ll look at ChatOps and how it can bring GitHub and many core DevOps tools and philosophies to developers’ fingertips for everyone’s benefit. We’ll also see what other tools can plug into a chat client to optimize development workflows, and what immediate results we can expect to see as we start implementing integrations. By the end of this session, we will have outlined clear steps to ship code faster and safer today.

Go-ing there and back again

This talk is another reminder that tests are code too and need care and feeding. It describes an experimental spike that we ran on a complex Go project to make the integration tests faster and more readable. We showed how not to rely too heavily on the testing framework and to refactor test code to represent the domain better. We also showed that teams have to move at their own pace, and that teams have to take into account the “House Style” of coding.

A better approach for testing microservices: introducing test kits in practice

Micro-services are the new black; everyone is using them. Alas, when your system is composed of many micro-services, testing becomes more challenging. The straight-forward approach for E2E testing no longer suffices and for integration tests it doesn’t even exist. A better way to test in this kind of an environment would be to work with a test kit of the micro-service you are interacting with.

By the end of this talk, you will learn how to create a test-kit that covers your micro-service. Testing this way will grant you a much higher level of confidence, and will portray a more accurate picture of your assumptions vs. reality. Overall it will make any integration between micro-services easier, thus benefit your colleagues and make your company progress faster.

DevOps: Modern Trends

A pragmatic overview of the ‘old-but-current’ and ‘new-and-uncommon’ processes, methodologies and practices in the DevOps/Release Management area. Implementation of Continuous Delivery, Value Stream Mapping, Delivery Pipeline, Continuous Testing, Infrastructure as Code, Test-Driven Infrastructure, Developer Self-Service will be reviewed. Advantages and disadvantages of cloud platforms for the DevOps process will be briefly reviewed. The second half of the talk will be focused on software upgrade strategies and the correct approach to database schema update.

Feature Branching is Evil

Feature branching is gaining in popularity due to the rise of Distributed Version Control Systems (DVCS) like Git and Mercurial. Mostly because proponents of DVCSs rely on feature branching to sell DVCS. And because of the success of branching models like GitFlow and GitHub Flow.

Like all powerful tools, there are many ways you can use DVCSs, and not all of them are good. Although the creation of feature branches became very easy with DVCSs, it does not mean cheap in the long run. It comes with a certain cost which impacts the stability and speed of your software delivery process.

During this session we will explore some of the reasons teams are using feature branches, what problems are introduced by using feature branches and what techniques exist to avoid them all together. In conclusion we will explore what is evil about feature branching, which is not necessarily the problems they introduce. But rather the real reasons teams are using them for.

The key takeaway will be an appreciation of a different branching strategy and how it relates to Continuous Integration.

The target audience is anyone using version control systems in a Continuous Integration and Delivery context.

Monitoring of reactive systems

Nowadays most of the new systems are distributed and use network as communication layer between their runtime elements. Reactive nature of the network and growing trend of brining reactive priniciples into applications themselves allow to organize systems which can process more user requests with less amount of resources. The main tradeoff for such approach is complexity, which basically brings more challenges to monitoring of such systems and tuning their performance.

During the talk speaker will share the experience of dealing with described problem. Journey will start from the basic monitoring priniciples to align everybody before diving into the world of modern monitroing tools. The capabilities of Dynatrace and OpsClarity are going be presented to demonstrate what information can be used during preproduction and production usage of the system. In the end of the session lessons learned will be shared collected while bringing big reactive distributed system into production.

360° Monitoring of Your Microservices

“With microservices every outage is like a murder mystery” is a common complaint. But it doesn’t have to be! This talk gives an overview on how to monitor Spring Boot applications, since they are increasingly popular for building microservices. We dive into:

* System metrics: Keep track of network traffic and system load.
* Application logs: Collect and parse your logs.
* Uptime monitoring: Use Heartbeat to ping services and actively monitor their availability.
* Application metrics: Get the information from Boot’s metric and health endpoints, store it, and visualize it.
* Request tracing: Use Sleuth to trace requests through a distributed system and Zipkin to show how long each call takes.

And we will do all of that live, since it is so easy and much more interactive that way.

Designing of REST API automation tests in Kotlin

Let’s imagine the REST API with N endpoints and PostgreSQL with Mongo DB under the hood. And yes, it is possible to automate it in a really non-trivial way using the cutting-edge technologies and frameworks: Kotlin, Spring Boot and Cucumber BDD. After this session, you’ll likely change your mind about design approaches of test frameworks.

Experimenting on Humans’ (or, ‘everything you want from an a/b testing system’)

How do you know what 100 millions users like? Wix.com is conducting hundreds of experiments per month on production to understand which features our users like and which hurt or improve our business. At Wix we have developed our 3rd generation experiment system called Petri, which was open sourced. Petri helps us maintain some order in a chaotic system that keeps changing. We will also explain how it works and what are the patterns in conducting experiments that have a minimal effect on performance and user experience.

Future of Serverless

4 years ago, mid 2013, we have identified a gap in the cloud echo-system. The landscape of IaaS, PaaS and SaaS provides solutions for VMs, Container and Networking, platforms of different types for backend developers, Backends for mobile developers and ready made software for individuals and enterprises. What is missing in the middle is the platform for web-sites and web-apps.

4 years down the line, with the emergence of Serverless, there are still no players in this gap. We will talk about what makes a platform for web-sites and web-apps. Things frontend optimized javascript, SEO, visual builder, web methods & backend javascript as well as request time container boot.

We have built Wix Code over the last 4 years targeting this exact gap – a serverless platform for website and web applications, and so …

Wix is taking the risk of predicting the future of serverless computing and where it should be 4 years from now.

Migrating huge monolith to microservices. How we did it in details.

This session is about migration from a huge monolith to microservices. I will tell you about our experience, not theory. The session depicts prerequisites to start a monolith separation, problems I bumped and obstacles that were overcome. In my presentation I will shortly depict problems with the monolith, show appearance of business and framework modules separation, describe necessity of internal and external API, depict certification of libraries and microservices and touch other questions like branching/release strategies.

Safer Refactoring with The Mikado Method

Have you ever had that sinking feeling after embarking on what seemed like “an easy change” that it is slowly spiraling out of your control ? What about the feeling of despair when critical technical debt is yet again ignored because it’s sheer size and complexity make it too daunting to know where to start?

I used to have these feelings a number of years ago until I discovered The Mikado Method, a technique formalized by Ola Ellnestam and Daniel Brolund in 2014.

I’ll give an explanation of the main steps of the method and share with you how I started using the method to make sure my refactorings were not soul destroying trials of fire, and eventually how we started using them in teams to tackle big refactorings that were going to require multiple sprints to achieve.

Application Architecture – Inside/Outside Thinking With Hexagons

The traditional layered architecture has been around for a long time, and for equally as long has been often implemented naively with little to no regard for the direction of dependencies, who is coupled to whom and who is causing change to whom.

I will discuss the Hexagonal Architecture approach first written up by Alistair Cockburn and how it provides a clear way to think about your application and it’s most important pieces, namely the boundaries between different responsibilities and how to keep them from become entangled.

I’ll also show some concrete examples of how I’ve implemented various adapters in .NET for incoming (commands / use cases) and outgoing (persistence / notification etc…) ports.

A Crystal Ball to Prioritize Technical Debt

Most organizations find it hard to prioritize and repay their technical debt, and the main reason is the scale of modern systems with million lines of code and multiple development teams; No one has a holistic overview. So what if we could mine the collective intelligence of all contributing programmers and start to make decisions based on data from how the organization actually works with the code? This session introduces one such approach with the potential to change how we view software systems.

In this session you get an introduction to techniques that help us uncover both problematic code as well as the social dimension of the teams that build your software. The techniques are based on software evolution and findings from various fields within psychology. This combination lets you prioritize the parts of your system that benefit the most from improvements, detect organizational issues and make practical decisions guided by data. Each point is illustrated with a case study from a real-world codebase. This is a new perspective on software development that will change how you work with code.

Improving Your Organization’s Technical Prowess With Legacy Code Retreats

In his book “Understanding the Four Rules of Simple Design”, Corey Haines is talking about good design principles and teaching us how to practice them using Code Retreats. Unhappily, many of us have to do with legacy code in our daily lives, and find ourselves frustrated when we try to make legacy code better. JB Rainsberger has started a variation on Corey Haines’ code retreats, making them more practical for legacy code practitioners. I’d like to be able to use this legacy code in Java often.

For the duration of the master-class, we want to learn the classic Michael Feathers dance of:

      1. Identify change points
      2. Find an inflection point
      3. Cover the inflection point (break external dependencies, break internal dependencies, write tests)
      4. Make changes
      5. Refactor the covered code.

We also would lay out the practicalities of having a legacy code retreat: Who comes? How should they pair? When do the pairs switch?

The hard way to production

In this talk, I am going to tell a real story of the project that has made a hard way, from developers computer to production environment within a year. I will drag through painful moments with infrastructure, development, Ops and QA. Participants will see how QA team became a driving force and joined Devs and Ops guys to achieve the project goals.

Designing Functional Programs

Functional Programming promotes immutability and the use of higher order functions. For those of us who have designed and architected applications using imperative style of programming and the object-oriented paradigm, this largely appears like a strange idea. We often ask, how is it practical to apply these ideas, realistically to build practical applications. It turns out it’s highly practical but we have to change how we design and how we model our systems. Come to this presentation to think about functional style and how to start viewing design to make better use of this way of programming.

Speed without Discipline: a Recipe for Disaster

The demands on applications have never been more intense. The users on the web, combined with mobile devices, ask for highly responsive applications. Our customers, thanks to open competition and perceived agility, expect tomorrow’s features be delivered today. “Are you done yet” are the dreaded words of the corporate grind.

Tools have risen to address those demands for speed. While that’s wonderful, speed in the absence of discipline is hard to sustain. In this keynote we will discuss the practices that can help alleviate the pains while helping us cope with the demands, the reasons to do so, and the approach we can take to achieve that.

Everything as a Code

Development process is not finished with coding phase completion. We also need to write some kind of documentation, think about verification procedures, make sure availability and other non-functional requirements are satisfied.

We usually do things with the most familiar approach, even if it contains much manual work and not so efficient. But what if there is another radically different approach? Could we formalize all our activities and structure them as a code? What tools and practices could be used for this purpose?

In this talk Alexander is going to present his personal experience in automation of different aspects of development process.

Rapid Development With Microservices

Microservices is not a buzzword anymore, it influences our development process as well as our organizational structure. But still, when we start a new service, we want to move fast. Can we move fast while architecture our system correctly?

After developing a number of services in Wix, I want to share some of my experience with developing and architecting systems while keeping a high velocity.

Chatbot in just 30 minutes

In this live-coding session, Eduards will show how to build a production-ready, interactive chatbot for Slack. After the session, you’ll have a firm understanding how to build your own chatbot using open source toolset. No fluff, just code!

Lessons from automating Crash Reports handling at Unity

To be one of the leading tools for game developing industry with reach functionality and target platforms from desktop and mobile to VR/AR while having more than a million of registered users worldwide puts enormous pressure on QA and Support teams to deliver highest possible quality and smooth user experience.

Every software happen to have bugs, especially such complex ones like Unity.

Imaging trying to manually process around 6000 of user submitted bug reports per month! Your first reaction is to put more resources onto it, then you realize it stops scaling well and you start looking for other solutions.

In this talk we will discuss challenges we faced and solutions we made in order to build internal tools to help automate handling of crash reports (from collecting callstacks for both native (C++) and managed (C#) code, to infrastructure for submitting and storing reports, to online processing and decision-making services) which made everyday’s life of testers, developers and release managers at Unity much easier while providing our users with better feedback and quicker solutions to their problems.

Code Review tool for personal effectiveness and waste analysis

Usually it is hard to analyze personal effectiveness and detect wastes in development process because developer’s work decomposition is not transparent and available for analysis. As a good sample of ineffective process imagine developer, who spends 1 day on task implementation and then reimplements it several times according to code review notes during next 2 days. Or another developer, who is waiting for code review during 2 days, switching context to other tasks, finally gets notes and switches back to initial task, trying to refresh all details in his head. And so on and so forth…

Code review tool usage helps to aggregate lots of useful information about any code change at any stage (static analysis, code review, rework, acceptance, integration into main branch). In this talk I’m going to demontrate how this information could be used for detailed analysis of development effectiveness and wastes detection. Based on mentioned analysis you could implement many improvements for your development process and then measure their success.

Funny stories and anti-patterns from DevOps landscape

During last several years DevOps became strong buzzword used almost in every project, team and company. But almost everywhere it is used in very funny and strange context. For example, existing ops guys are renamed to DevOps just to sell them to the client for more money. Or DevOps is used as new job title for some magically powerful person who is able to operate cloud environment and modern infrastructure related tools, leading team of old school ops and participating in management meetings. In this talk I’m going to review all different anti-patterns and bad practices in DevOps landscape using stories from my personal experience as Delivery Manager and independent consultant.

Evolution of the delivery system in evo.company

Evo.company serves few big marketplaces in Ukraine and USSR, the biggest one is prom.ua. We are running several hundred of bare metal servers in six data centers in four countries. Currently, we are in the process of migrating our applications from the traditional setup of ubuntu packages and pythonic virtualenv to containers and our own orchestration system.

This work includes setting up continuous integration and delivery pipeline, containers, monitoring, logging. And as usual, the biggest challenge is to train our colleagues to use new stuff, to prove that it’s not a waste of time and allow more people to know how to keep systems running. In this talk, I’ll discuss both the technical and organizational challenges we are facing and how we cope with them.

DevOps guide for awesome quality assurance

The practical story telling how Devops changed the culture of quality in the Bank. Recently Devops became mainstream topic. But only few people have a deep understanding how to apply it to the process of software quality assurance. Some believe that the Devops kills manual testing.

I will talk about changes it makes to the role of QA engineers themself. The discussion main point is NOT about tools or technologies. It’s NOT about the “silver bullet” for your problems with the quality of products.

Instead, I will show you an integrated approach which we used for quality assurance. It allowed us to significantly reduce the cost of finding and fixing defects. This approach has also accelerated the development and delivery value to our customers and made the whole process more transparent and predictable.

Engineering at TransferWise: the story of Service Discovery

Rather than traditional departments, TransferWise is organised into several highly autonomous teams, each focused on solving a specific business or customer problem. It’s the very essence of a lean approach – effort invested is justified by quantifiable impact.

Why do we work this way? How did it change over time? What does this mean for engineering? How does this affect our practices and our culture?

Answer can be found in this talk.

Track quality of your code with SonarQube

It is not to complicated to keep new project with good code quality for half year. Maybe for one year. But what if team works on some project for years? Or even “”better””: you need to support and grow large project after another team. Presentation describes Continuous Inspection, main measures of code quality that will make your life better, and how to cook it with SonarQube.

Continuous Learning using Application Performance Management & Monitoring

When an application has been released to production or a new feature is done we know that our work is not over. With your application being used by real users, now is an ideal opportunity to collect valuable data.

In this presentation Igor will show how easy it is to instrument your app and get ambient monitoring out of the box, with almost zero effort. Also Igor will demonstrate how you can quickly build monitoring charts, dashboards, alerts and configure diagnostics logs to get a 360° view of your application. This presentation unlocks the best practices and the essentials based on real world stories from his practical experience to find performance bottlenecks, random exceptions, usage patterns of end users, availability and so on.

During a session Igor will give you a sense of metrics importance through the possibilities of New Relic and Application Insights tools and show few interesting stories.

Metrics at Scale@UBER

Metrics @UBER is a first class citizen. Mantas in his talk will cover metrics collection, presentation and alerting based on metrics. It is all about how they deals with the scale in incredibly fast growing company. He will include details on the tools Uber currently uses, as well as their painful migration path from graphite based solution. The speaker will show their build-in-house query language based on tags they are using to query metrics. Mantas will share his experience building, migrating and supporting metrics system at the fastest growing startup in the history.

Идеальный релиз

Описание тренинга

Если вы устали от FDD (fuckup-driven development), практикуемого в вашей компании – предлагаю рассмотреть историю трансформаций продуктовых команд под моим управлением, которые смогли выйти из замкнутого круга, повысили скорость и качество разработки, начали получать удовольствие от работы и построили изумительные процессы разработки.

Опыт перехода от “FDD” (не путаем c feature-driven наше все development) к нормальной разработке подсказывает, что большинство проблем связано с зашоренностью взгляда, неправильной расстановкой приоритетов и неумением пользоваться вытягивающими принципами, которые и обеспечивают те самые 20/80. А попытки бессистемно внедрить различные позитивные (или хорошо рекламируемые) практики часто приводят только к незначительному улучшению, а достигнутый результат быстро деградирует. Иными словами – типичные проблемы трансформации.

Набив немало шишек, пришло понимание, что нужно менять подходы в строительстве процессов и мышление. Был сформирован подход проектирования фич от бизнес-целей, расписан жизненный цикл и расставлены точки принятия решений и всевозможные триггеры, которые позволили действительно заняться ранним управлением рисками. Принципы многоуровневого мышления и решения проблем позволили замедлить деградацию внедренных практик и процессов и не только сохранять достигнутую связку производительность – качество, но и улучшать ее.

Я расскажу о процессах, системе ценностей, подходах в мышлении, которые мы взрастили. О смешных и грустных историях ошибок и неудачных экспериментов. И если вы готовы к циничному препарированию проблем вашей команды – рассмотрю их вместе с вами и предложу решение, опирающееся на вышеописанный опыт трансформаций и на богатый опыт продуктовой и заказной разработки.


  • Знакомство, синхронизация целей и ожиданий
  • История и проблематика трансформируемых команд, веселые и грустные примеры факапов
  • Теоретическая часть: дизайн процессов разработки и управления рисками жизненного цикла фичи
  • Теоретическая часть: практики решения задач по дизайну процессов, метрики
  • Пример жизненного цикла фичи: от требований и их тестирования до принятия обязательства (стоимость-качество) на разработку
  • Пример жизненного цикла фичи: от начала разработки до релиза
  • Пример жизненного цикла фичи: от релиза до смерти фичи, защита процесса от эррозии
  • Сбор проблемных кейсов участников, отбор 3х наиболее актуальных для участников проблем путем голосования, разбиение на рабочие группы
  • Выработка решений проблем в группах и их защита
  • Подведение итогов, вопросы и ответы, литература

Что вы получите

  • Познакомитесь с практиками дизайна процессов разработки и решения управленческих задач.
  • Детально рассмотрите процесс разработки, успешно применённый к трансформации 2х совершенно разных команд, ставших успешными.
  • Получите обоснование принятых решений и перечень учтённых рисков для каждого этапа разработки и сможете спроецировать на свои собственные процессы и проекты.
  • Попробуете применить знания о полученных практиках дизайна процессов к решению ваших текущих проблем.
  • Познакомитесь с практиками принятия решений, обсуждения, приоритизации и модерации.
  • Смешные и грустные жизненные истории из более чем 18 летнего опыта тренера по разработке софта за деньги 🙂

Continuous Delivery in .NET

О чем тренинг

Несмотря на то, что практики Continuous Delivery далеко не новые, не всегда они применяются даже на коммерческих проектах. Это происходит, с одной стороны, из-за недооцененности их ценности, а с другой – из-за банальной нехватки знаний и опыта.

Еще одной причиной отсутствия внедрения называют нехватку времени. Но в большинстве случаев это просто маскировка двух вышеупомянутых. Наш тренинг поможет решить их обе. Мы расскажем о преимуществах использования практик Continuous Delivery, рассмотрим техники и инструменты, применяемые для .NET проектов и покажем их в действии.

Мы не обещаем что после тренинга вы сможете сразу же внедрить у себя все, о чем мы расскажем – тут многое зависит исключительно от вас. Но, как минимум, вы значительно сэкономите ваше время на изучение описанного материала. И вам будет значительно легче начать внедрять практики, к тому же вы сможете их правильно продать вашему руководству и другим участникам процесса принятия решений.


.NET разработчики любого уровня, технические менеджеры.


  • Что такое Continuous Delivery и зачем оно нужно (1 час)
    • Стандартный процесс разработки
    • Циклы обратной связи
    • Элементы Continuous Delivery
    • Continuous Delivery vs Continuous Deployments
    • Особенности для .NET платформы
  • Работа с кодом (1 часа)
    • Стандартный цикл написания кода
    • Системы контроля версий
    • Навигация по исходникам с помощью VS / Resharper
    • Рефакторинг с помощью Resharper
    • Запуск и отладка
  • Тестирование кода (2 часа)
    • Уровни тестирования (unit, integration, acceptance)
    • Инструменты и фреймворки для тестирования .NET кода
    • Требования и правила написания юнит тестов
    • Покрытие тестами
    • Как покрыть тестами легаси код
    • Приемочные тесты, подходы и инструменты для .NET
  • Ревью кода и парное программирование (1 час)
    • Коллективное владение кодом
    • Зачем нужно просматривать чужой код
    • Инструменты и подходы для ревью
    • Подходы к парному программированию
  • Статический анализ кода (1 час)
    • Что это и зачем нужен
    • Обзор инструментов для .NET (fxcop, stylecop, sonarqube) и их интеграция
    • Разбор типичных ошибок
    • Настройка sonarqube для .NET проектов
  • Continuous Integration (1 час)
    • Подходы к сборке .NET проектов (декларативный vs императивный)
    • Обзор fake (F# make)
    • Построение Delivery Pipeline на основе TeamCity
    • Тактики и инструменты развертывания
  • Test Driven Development (1 час)
    • Зачем нужно и когда стоит применять
    • Правила написания кода по TDD
    • Инструменты для создания “живого кода”

JIRA journey to cloud

How do you take a huge java monolith application and put it into Cloud? How do you provide independent continuous deployments of OSGi plugins and make sure everything was well tested together? How do you keep track of 1000 moving parts and still stay sane?

I will tell you the story how JIRA team answered those questions, what were the biggest challenges and easy wins. Presentation will be full of examples how we do things in JIRA like testing, branching, releasing and deploying, what tools we use and how we use them, how we keep our code in good shape and deliver it to almost 80,000 JIRA instances.

This will be continuation of story presented by Wojciech Seliga on XP Days in 2014. If you are interested what changed since then (even more tests and completely new challenges) I will gladly have you in the audience.

Fear and Loathing after Production

Remember situation when on the next day after successful release your system goes crazy as well as your stakeholders? Endless meetings with angry customers when you have no idea what is wrong with your system. You either have no logs or they are full with useless messages giving no any glue to the root cause. Your monitoring either does not exists (was planned for the next release – yeah!) or shows that everything is OK. Remember all that? I bet every developer was in similar situation or at least heard of it.

In this talk Serhiy will tell how to avoid such unpleasant life experience. What and how should be logged. Where logs should be stored. What monitoring should be in place. How codes should be written. Tools, practices and so on. Basically speaking, things that should reduce your stress and make your life happier.

Interested? Come to my talk then!

Building better CI using Jenkins pipelines

This talk is about improving CI practices building pipelines. It will cover old practices and how they can be enhanced using custom DSL, code review and SCM.

The Sane way to Apps in the Cloud

Did you know that Netflix has now fully transitioned to the cloud. Ever wonder how you could do the same or sell it to your boss/clients/your pet? Do you often wonder how to chose the best provider out of all the different players in the market.
Well wonder no more. Join Paul as he guides you through how to build infrastructure on 2 different platforms. Watch as he uses both AWS and Azure to show you easy it is using the principles of infrastructure as code.

By the end of this session, you will have enough guidance and confidence to start automating your own infrastructure and be less afraid of that big bogeyman VENDOR LOCKIN.

Engineering Excellence in large service company

This talk is aiming to answer the following questions: What makes contractor-engineers of a vendor service provider to be different and competitive on a global IT market? How to incorporate all the technology diversity and successfully deliver high quality, enterprise level complex solutions? What is the nowadays startups and how to foster right engineering culture to enforce it? Deliberate practice and continuous learning as a technology agnostic approach in mastering engineering craft.

In this talk I’m going to share a story about implementing Engineering Excellence (ENGX) department in a large outsourcing company. I’m going to present a number of show cases of ENGX integration for a different clients and describe what didn’t work well and how we struggle with it. I will also present a few things that we managed to implement and successfully integrate into internal company’s process, such as mandatory onboarding training – Bootcamp and Dojo platrom that can help engineers in hardening their technical capabilities.

From Continuous Integration to Continuous Delivery with TeamCity

In early 2006 JetBrains decided to create its own solution for Continuous Integration – TeamCity.

We will start with preconditions of this decision and main concepts of the product. Then we’ll discuss common problems that we and our customers have faced over the decade, trends and plans for the future.

Finally, we’ll look into installation that builds all Jetbrains products and find out how TeamCity continuously delivers itself every day.

From monolyth to SOA – baby steps

Implementing a new architecture into existing project doesn’t have to mean a “feature freeze”. By checking a success story we will see, that in may be a transparent process, that won’t harm, neither slow down the development process. Additionally, we will learn how to prepare your code to move to microservices and reactive microservices architecture in future.

Interview in DevOps style

Engineers like to be interviewed at Grammarly, and many of them say it was the best interview they ever passed. So they ask me to share my interviewer experience. I tried to make that topic interesting not only for DevOps\SRE hiring managers but for every engineer. DevOps\SRE interview will be just an example how you can make your interviewer skills better.

Common sense DevOps… or how we evolve in 4 years

All of us would like to keep our infrastructure as simple but smart as it is humanly possible. Simplicity is required so we understand and can support it. However, it has to be smart enough to keep complex things under the hood. Moreover we do want to forget about its existence and focus on other tasks. So do I.

I would like to share my experience how we build our infrastructure from scratch with the challenges to overcome as well as the evolution of the view on the infrastructure after 4 years of real experience.

A lot of scripting, silly mistakes, and great achievements which can help you to survive in a hostile environment of bloody enterprise.

Continuous delivery for mobile (building your own pipeline)

This talk covers how Hootsuite enabled continuous delivery for its native iOS and Android apps. We will examine what tools we used to build our own automated pipeline, how we built it iteratively, and what features proved most valuable. We will share lesson learned and also some of the things we’re thinking about adding next.

Building Continuous Delivery Pipeline In Azure – Infrastructure, Tools and Processes

This talks covers the setup and turning the Continuous Delivery process in Microsoft Azure cloud.

It includes organizing delivery pipeline with GitFlow branching model, Visual Studio Team Services (former Visual Studio Online) as CI tool and Octopus Deploy as Release Management tool, organizing the dev/test environments in Azure leveraging Azure Resource Management API. Lessons learnt includes:

1. Organizing CI builds for branching, segregation of Ci and Deployment tools
2. Configuration and Parameters management. Testing deployment configuration.

The talk is based on my presentation on AzureDay in Kyiv, but will be reorganized a little bit to bring more practice and deep dive.

Twelve Ways to Make Code Suck Less

We all have seen our share of bad code and some really good code as well. What are some of the common anti patterns that seem to be recurring over and over in code that sucks? By learning about these code smells and avoiding them, we can greatly help make our code better.

Core Design Principles for Software Developers

Writing code is easy. Writing good quality code is an entirely different story. How can we measure quality of design? How do we know we’re doing the right set of things that will leads us to a better design? In this session we will learn about some core software design principles that help programmers everyday. Instead of talking about theory and what we could potentially do, we will take on multiple examples, discuss the solution, pros and cons, and bring out key design principles that have an impact on the outcome.

Effective pair-programming across skill: lessons learned from pairing up

Many technical teams consider pairing their junior developers with more experienced colleagues to be an effective way to upskill new team members. My team at www.net-a-porter.com followed the same approach when I joined over two years ago. My experience as a junior developer, who paired with experts on almost every story, showed that simply assigning two engineers with different skill levels to a single task is not enough for a successful pair-programming experience.

The topics I will share in this talk include:

– pair-programming as a social skill, how varying levels of expertise can affect behaviour and decision-making of the pair
– what I learned about the needs of junior and senior developers when pairing
– what our team found to be most beneficial in pairing novices with experts
– which aspects of pair-programming across skill proved to be ‘pain points’ to the team
– a recipe for success: what we did to overcome challenges of pairs with the experience gap, and what we can do to improve further

I have published a paper on the topic with Springer Open in Lecture Notes in Business Information Processing. I also presented the talk at XPRoLo meet up at Unruly Media House in London, at XP2016 Conference in Edinburgh, and internally to technical forum at YNAP. Both the talk and the paper received excellent feedback from industry pioneers as well as novices.

CI is essential but not sufficient for an effective delivery

Continues Integration is essential, but is it enough to have Jenkins or TeamCity? Unfortunately no – we need tools and methods to get efficient delivery workflow. Three stones, such as monolithic code + test suites + deployment pipeline should be faced.

We will speak about Test Pyramid and Trunk based development. Why may automated tests does not work in reality? Do we need Manual testing and in which step? What about Acceptance and Capacity test? How to put all of this in one deploy pipeline?

Use experiments to replace your backlog

Of the original XP practices, the one that seems the most difficult to get right is the on-site customer. In the original XP team, this was an actual end-user of the, internal, system that was being built. How did the Product Owner turn into a project manager working down a long, predefined backlog?

The Product Owner role quite often has devolved into a step in a waterfall process. A gateway, or proxy, sometimes a firewall, towards the rest of the organisation. But customer feedback is a fundamental basis of any Agile process.

I will discuss how we can use clear goals, captured in actionable metrics to guide our teams in growing the software necessary to reach those goals.

I’ll show how to get development teams to demonstrate their progress based on business metrics, not just features completed. To strategically align development with the rest of the company. And how this allows you to really use the brightest minds in your organization for innovation.

Testing in a Continuous Delivery World

Hey, do you remember when everyone was asking what the role of the tester would be in an agile team? It’s happening again!

And things are changing again. A team that takes on the challenge to release their every commit certainly will take testing seriously. It will need to evolve new ways of testing. It will have new dynamics of testers working with developers. It will find new ways of of interacting with customers, stakeholders and product owners.

In this talk we’ll look at how continuous deployment changes the dynamics of an agile team. How quality moves even more to the center of the stage. How that changes the role of the tester once again. How it changes the role of developers, too. How this practice allows you to put the customer center stage again. And how that, too, has testing competencies at its core. And we’ll not forget DevOps, and how monitoring can be a continuous testing strategy.

Continuous Integration for Microservices with Jenkins 2.0, Docker and Kubernetes

What is necessary for CI for microservices? Jenkins 2.0 with pipelines looks like a good option for that. But is it enough? Let’s add Docker for containerization. We think it could be even better with Kubernetes. The presentation will provide you how to build CI for microservices from scratch with those tools and describes some best practices applicable for Microservices CI.

DevOps: The Harmonious, Polygamous Marriage

DevOps is not simply building a continuous delivery pipeline and many people feel that they’ve been ‘doing’ devops (or trying to!) for many years. So why, exactly, has the term received so much attention? What really is it? In this talk, Helen explores the devops trend, its roots and history and its purpose as a transformational, evolutionary movement to make better software, faster and more safely. She will discuss its relationships with Agile, Lean and ITSM and review how organisations have successfully, and not so successfully, used devops to elevate the way their business delivers innovation to their customers.

Perfect release

Let’s imagine a perfect release of feature(s)? What development process is needed? How organize life-cycle stages in terms of decision-making points? How to reduce risks and bottle necks impact? What about the team properties? What can you change in own project or product right now?

I will try to answer for all these questions. All answers based on my long-year development (sometimes rapid 🙂 experience of complex fintech projects/products.

DevOps for A Busy Developer

Our minds are bright, our thoughts are clear, our eyes are lit with passion, but we’ve got no time!

We thought frontend churn was terrible but DevOps space is so much worse! What tools to use? Which direction to take? What movement to follow? Every single day new tools emerge with a promise to solve the challenges we have and the ones we don’t know we have! We don’t have enough time to learn to use them properly, and each time we try them they either don’t work as expected, or do so inconsistently. Yet at the same time we face tight deadlines and have work to do!

The task at hand is clear: we’ve got a pile of code, and we want to run it on a bunch of servers. I will show you how I do it with as little sweat and tears as possible.

Cloud based Deep Learning infrastructure at scale

Presenting the infrastructure work that we did to support the launch of The Roll, our smart camera roll app.

We’ll give a brief overview of deep learning at EyeEm, and how we use it to build our products. This includes how we use it for both search, image captioning and aesthetic ranking.

We needed to build a system, exposed through an API and tracked through a data pipeline that could run our deep learning models on uploaded images, return a variety of data to the users (keywords detected in the photo, photo scores) and track all the data for later analysis.

We’ll talk about how we optimized for throughput by load testing memory pressure on the GPUs we used on AWS instances, and how we go from training a model to putting it in production.

On launch day, we were expecting to have to process around 500 photos/sec. In reality, we peaked at around 850 photos/sec, without any impact on performance.

Design for Testability: What, Why and How

“To be tested a system has to be designed to be tested”
Eberhardt Rechtin, “The Art Of System Architecting”

Testing is one of the main activities through which we gather data to assess the quality of our software; this makes testability an important attribute of software – not only for development, but also for maintenance and bug fixing. Design for testability is a term that has its origin in hardware design, where the concept was introduced in order to make it easier testing circuits while reducing the costs of doing so.

In this talk I’ll show how to translate this concept to the software domain along with the consequences on various aspects of the development activities, both from the technical point of view (e.g., design, code quality, choice of frameworks, etc.), and the product management point of view (e.g., management of team dependencies, delivery time, costs, etc.).

I’ll provide examples based on real world experience, both for the technical and the management aspects. Last but not least, there will be code!

Creating An Incremental Architecture For Your System: What, Why and How

Experience taught us that creating an architecture for a system with a big design upfront is a bad idea as, usually, we don’t have all the necessary information to design the system at the very start—even in moderate sized systems requirements tend to change significantly, often making the initial design unfit for purpose.

On the other hand, no upfront design can be just as bad—the code tends to become unmaintainable pretty quickly, and system qualities like performances, scalability, security, latency, etc., can be very difficult, if not impossible, to retrofit.

In this talk I’ll show a different way to create a software architecture with just the right amount of design that can be incrementally evolved (or changed) as the system grows and changes—by taking care of some important qualities of the system early in the design, and delaying the design of other aspects to the last responsible moment.

TDD from the Trenches

In this live coding session in Scala, Kfir Bloch (head of back-end engineering at Wix) will showcase how to build a full-blown feature in Scala, while maintaining the principles of TDD and Clean Code. We’ll start with some simple scaffolding and build the feature in its entirety: defining the user-facing API, writing tests outside-in with all of the requisite building blocks (collaborators and matchers), development-refactoring cycles and ending up with a clean codebase.

The Art of Decomposing Monoliths

Microservices are the new black. You’ve heard about them, you’ve read about them, you may have even implemented a few, but sooner or later you’ll run into the age-old conundrum: How do I break my monolith apart? Where do I draw service boundaries?

In this talk you will learn several widely-applicable strategies for decomposing your monolithic application, along with their respective risks and the appropriate mitigation strategies. These techniques are widely used at Wix, took us a long time to develop and have proven consistently effective; hopefully they will help you avoid the same battle scars.

Continuous Delivery with Jenkins & Kubernetes @ Sky

The talk is based on what we currently use in Sky to deliver in a continuous fashion one of our platforms in Sky.

In short, it covers the following topics:

  • Problems we are trying to solve
  • Design a deployment pipeline that allows a large team to scale
  • Generate automatically pipelines using groovy DSL for Jenkins
  • Leverage Kubernetes for a flexible deployment model
  • Achieve continuous delivery

The demo will consist of taking a simple app from the first commit and all the way through the production deployment pipeline.

DevOps with Smell: Antipatterns

DevOps is the hottest topic on the market. Everybody are adopting DevOps, however many starting to do mistakes. This talk is about experience gathered during consulting DevOps tools and practices in multiple projects and locaitons over the last years. We will review common anti-patterns and proposed solutions.

Serverless Architectures

Live coding session that shows step-by-step how to build Serverless Architecture webiste that will be higly available, scaleable across multiple regions, backed with git as CMS and cost to operate less than 5$/mo. We will review Serverless Architecture style and address some of important gaps of this architecture.

Micro Service Architecture: best practices from A to Z

You start new project or working with existing one and think: “Hey, I could use microservices, it is something new, that resolve all my problems: flexibility, scalability, modularity…”. It is not working like that. In this speach you will not hear how good or bad Micro Service Architecture. Real use cases, pros&cons, from real practice. Only best practises. This speach should gives you one more tool into your toolbox, with clear understanding where you can use it and cases, when you should avoid MSA.

Pragmatic Architecture, Today.

Software development has evolved. Agile is now the de-facto standard. The role of an architect in an agile project is very different than the typical role in a more classic waterfall approach. Using an updated interpretation of ‘viewpoints and perspectives’, this talk will demonstrate how to make rapid, agile delivery sustainable. These viewpoints and perspectives will be linked to easy-to-produce models that can be used immediately in your projects. The talk will provide examples on how to determine which models are architecturally significant and worth the effort.

Developers have always been very important stakeholders of an architectural description. A good agile architect needs to strive for consensus and buy-in.

Journey from Monolith to Microservices and DevOps by WIX

Wix.com started the journey toward DevOps and a microservices solution about 5 years ago when we switched from a monolithic application to a microservices-based system—a transition that took two full years to complete, with many lessons learned along the way. Today, Wix successfully operates over 200 microservices on a battle-tested production environment. In this talk, we will cover why Continuous Delivery and DevOps are important requirements for microservices, discuss guidelines for a good microservice architecture, explain why YAGNI and KISS are important and how operational concerns (DevOps) affect the design of a microservices architecture, as well as give some recommendations on the best way to transition from a monolithic to a microservices architecture.

Beyond Software Craftsmanship – Johnny’s Road to Remarkable Career

Meet Johnny – a full-stack Java developer with 5+ years of experience under the belt, M.Sc degree and ‘get sh%t done fast’ mentality. Although Johnny possesses exceptional technical skills, Milton – his manager, doesn’t promote him, no matter how hard Johnny tried and how many late nights he has spent polishing his coding skills. Unfortunately, there is something important that Johnny doesn’t understand. Something that stops him from becoming successful. Together with Johnny, you will walk the thorny road to his remarkable career as a Chief Software Architect. The road full of struggles, discoveries and actions that may or will influence your professional life.

XDSD: is your team extreme enough?

Over the last two years we’ve completed over 20 projects, wrote over 300K lines of Java code, closed over 20K tickets, pull requests and bugs, assembled together over 200 senior programmers and made profit. We’ve done all that without a single meeting, Skype call, or a Slack chats. We barely knew each other aside from GitHub, where all that development happened. At the presentation I will disclose a few of our dirty secrets.

A DevOps pipeline

A guided tour of using Docker and other best-of-breed tools to deliver quality code from developers to production in a fast and scalable process. What does a modern pipeline look like in the context of Docker?

We’ll cover:

  • the state of the ecosystem
  • tools of the trade
  • process overview
  • key automations
  • integrations and hosting
  • deployment, operations and scaling
  • working with Docker without losing your mind 🙂

Target audience: new and intermediate engineers working with/interested in Docker.

How QA engineers could affect product quality? Or couldn’t?

Most frequently we are using words “testing” and “tester” when talk about product quality. But does testing or tester role affect quality? The eternal struggle between QC and QA… Yes, I’m almost sure you understand this, but why nothing is changed in most of teams? Because we need mind shift in our heads and more global changes in QA processes. Who QA engineers are and what are their responsibilities, activities, duties in modern development world? What options do they have to affect product quality and improve it if developers are responsible for product development? In this talk I will try to find detailed practical answers to all these questions. Let’s change development world together!

Code review at large scale

When you work in a small collocated team many engineering practices and approaches are relatively easy to use and adapt. In large project with many teams working on the same product this task is not so simple. I want to share experience report in implementing Code Review practice in big product development team (more than 150 people, 10+ feature teams). In this talk we will review what approaches works in such setup and what don’t work, what tools and additional practices are needed to support Code Review and make it more effective, what difficulties and blockers will you probably see in the real life cases, what useful metrics could be produced by this practice.

How TDD helps to produce better design, or not?

TDD is well known approach to develop more clear and less buggy solutions, completely covered with tests as a bonus. But what about design? Some people think that TDD also helps design to emerge as implementation grows, so there will be just enough design in place when all cases are covered. Others think that without general design skills and experience output from TDD will be a garbage from design perspective. In this talk we will try to cover this topic in all details, focusing on TDD usage at different levels and with different styles.

Confession of An Engineer

We all are professionals, e.g. software engineers, quality engineers, technical/team leaders, project/product managers, etc. But we all are humans too. Often due to different reasons, like tight deadlines, push from customers/clients, etc., we all tend to neglect common sense and omit important practices. In this talk based on my both positive and negative experience we will review some patterns how we make common mistakes and what terrible results they may lead us to.


Product Requirements: where they are coming from?

Have you ever had any of these thoughts:

  • Why are we working on this?
  • Others have this feature, shouldn’t we match the competition?
  • I was redoing it for 3 times, could someone think it through first?
  • Killing a working feature – this is insane. I could build this in a day, how come they work on spec for weeks?

After switching from engineering to product team I’d like to share my discoveries about business side of the product development.

UX Design & Agile

How do squeeze UX/UI design into agile practises? How do you insure you have right deliverables at right moment?

There is more than one way to do it effectively. There is more than one way to fail. Over a course of years I’ve been working as UX designer with development team practicing agile methodologies and I’d like to share some insights and practises I use.


DCI @ XING – same same but different

We write a lot of object oriented code at XING. Despite the ease of development with modern tools, we weren’t quite happy with the code produced as our codebase grew and matured until we introduced DCI (Data-Context-Interaction paradigm – Trygve Reenskaug’s invention, the author of famous MVC pattern).

DCI has become a hype word in recent years, yet one can hardly find evidence of real-life applications out there in the Internet. In this talk I’ll demonstrate how XING applies DCI to connect the important Agile practices and techniques such as DDD and TDD into a seamless development process, giving a revive of spirit to a long-lived OOP paradigm.


Don’t let your code to be illiterate along with your colleagues

Do you remember you saw in the code method with name “getCatalogVerion()” or variable name “reimbusmentEntrys” or comment “necesarry”? If you’re an Eclipse user I’d say you’re lucky, IntelliJ guys are not. Why? Because they see those silly mistakes after Eclipse guys checked code in. If you’re an IntelliJent person and do not want to make a “holly war” come to my talk – I’m going to share a good practices to keep your code “clean” from grammar perspective as well.


Automate everything you should

Nowadays computers are tremendously fast and powerful. All their cores, RAM and gigahertz’ are to our service. And seems like we have come to the point when we cannot make them 100% loaded.

Even we, software engineers, do a lot manual stuff. Manual testing, debugging, packaging, deployment – all that can and should be automated. In this talk Serhiy will sell you automation idea explaining what benefits you (developer, QA, manager) will get from it every single day.


Why to bother with writing test? Nobody cares?!

  • Why to bother with writing test?
  • You don’t see a benefit of writing tests first?
  • They slow down your app development?
  • Hard to create a name for the next describe\it?
  • You are forced to write the tests?
  • Or you doing it for money?

After this talk you will love to write test! Or at least understand why other do (note: no money back guarantee, sorry).


Escaping from the automation hell

We build software that runs on 21+ platform with millions of users and billions of deployments. Our software engineers have to keep the high pace of quality. More than 500k tests are executed daily. In this talk I would like to share my experience of dealing with unstable and long running tests, collecting, aggregating and analysis test execution data.

What does it mean to be a test engineer?

Test engineering is hard, even harder than software development. Being test engineer puts you in a wider context, with no clear boundaries. You have to find those by yourself. This requires courage. Courage to take action, courage to make mistakes. As a test engineer, you do mistakes every day. You do them so often that sometimes you feel you can predict the future. Scientific explanation to this phenomena is patterns recognition. It is an ability of our brain to match the information from a stimulus with information retrieved from memory. Defect prevention is hard. Together with technical skills one have to develop high social awareness. Working on safety nets never was so important, different types of checks on different levels to make sure software is reliable and serves its purpose to the variety of everyday use-cases. We know that life is so complex and sometimes complicated which makes it impossible to predict all possible outcomes and scenarios. But striving for excellence never was so important as nowadays in such an open, transparent and competitive environment.

Goal of my talk will be to show you my everyday job as a test engineer. Not only how to look for defects, but how to prevent them from happening. Not only how to automate tests(noun), but how to build safety nets to minimize end-user impact. Not only how to inform testing status but how to influence quality on company level.


Pair Programming: how to do it right

Pair programming is the key to XP. It is the bedrock practice which marks XP as being team-focused rather than individual-focused. There is evidence that it is a very effective practice. So why is it not more common? This presentation examines pair programming in detail.


API Driven Development

The general idea of this talk is that you define your application data, structure and everything to do with the data/API side of your application before you write a single line of code. It’s a constructive methodology that lets you think about what you are going to build before actually building it. This talk will cover test driven development of your API and database structure with the examples in JavaScript, Node.js and C#. The methodology is language agnostic though.


The Transition from Product to Infrastructure

Over the past number of years, operations has become a very interesting part of IT. Traditionally, operations and developers have been completely separate. Developers thought SysAdmins worked in basements, eating pizza. But, the operations space has had a boom in new tools to make life a lot easier. The role of SysAdmin has become a very important part of the product delivery cycle.

Paul has made the transition from being a product developer to an infrastructure developer. In this talk, he will be able to talk about why that was an interesting move and the types of problems he has to work on on a day-to-day basis. Paul will be able to talk about how this move has helped him be involved in much more successful project delivery and also how it has helped the companies he has worked with become more successful.


Continuous Delivery – the missing parts

A lot of developers have started to believe that hooking Visual Studio up to Azure and pushing code direct from their machines is CD. As much as I hate to say it, it isn’t. Continuous delivery has so many more moving parts required to work together.

As we discuss concepts such as config management, orchestration, security, monitoring and logging, this talk will help developers realise that continuous delivery is something we need to continually measure, learn and adapt to make us a higher achieving organisation.


Becoming a Better Programmer

You’ve come this conference to improve your skills. You’re here to learn: to learn new technologies, to learn new techniques, and to fuel your passion by meeting like-minded people.

Becoming a better programmer means more than just learning new technologies. It means more than practising techniques and idioms. It’s about more than passion and attitude. It’s the combination of all these things. That’s what this session will look at.

Pete Goodliffe, author of the book Becoming a Better Programmer, unpacks important mindsets and techniques that will help you improve as a programmer. You’ll discover specific tools that will help you review your current skillset, and you’ll learn techniques to help you “become a better programmer”.


Produсtonomicon. Antipatterns.

Kill your product with minimal efforts! Best practices and solutions are to be applied to your management, sales, team, architecture and code approaches ever.


Training “TDD in .NET”

Целевая аудитория

.NET разработчики.

!!! Внимание !!! Для выполнения практических заданий участникам требуется ноутбук (как минимум один на двоих)!

Описание тренинга

Современные средства разработки значительно повышают эффективность разработчиков. Создавать приложения становится все легче и легче. В тоже время, сложность самого программного обеспечения постоянно растет. И часто разработчики сталкиваются с проблемой: “А точно ли мой код работает так, как я хочу?”.

Разработка через тестирование (Test Driven Development – TDD) решает эту и ряд менее очевидных, но не менее важных проблем. Наверное, каждый слышал об этой технике, но далеко не все знают, как правильно ей пользоваться. И уж совсем немногие осознают, что TDD – это весело и продуктивно.

Данных тренинг позволит вам в компании коллег и под чутким руководством людей, практикующих TDD каждый день, пройти путь от ответа на вопрос “что ж это такое – TDD!?” до владения набором практик и знаний, которые сделают вашу жизнь разработчика намного легче и приятнее.

После прохождения тренингов слушатели смогут навсегда забыть о сомнениях “что делает/должен делать этот код” и обретут душевное равновесие и спокойствие на работе. Обилие практических заданий позволит попробовать все изложенное на деле и улучшит восприятие материала.

Детальная программа

Тренинг разбит на 8 полуторачасовых модулей:

  • Модуль 1. Введение
    • Что такое TDD, в чём его польза
    • Методика работы по TDD, основные правила и принципы
  • Модуль 2. Hello World
    • Начинаем работать
    • Пробуем Arrange/Act/Assert
    • Проектирование через тестирование
  • Модуль 3. Погружение
    • Тестовые двойники
    • Организация тестов
    • Запахи тестов
  • Модуль 4. Инфраструктура
    • Dependency Injection и его роль в TDD
    • Роль Continuous Integration в TDD
    • Метрики TDD
  • Модуль 5. Проверяем закрома (базы данных и прочие хранилища)
    • Взаимодействие с источниками данных
    • Интеграционные тесты на базу данных
  • Модуль 6. Welcome to real world
    • Взаимодействие с другими сервисами и системами
    • Изоляция тестов
    • Интеграционные тесты на сервисы
  • Модуль 7. UI
    • Тестирование пользовательского интерфейса
    • ASP.NET (MVC)
    • Winforms / WPF
  • Модуль 8. Наследие предков (legacy code)
    • Рефакторинг через тестирование

Training “Agile Mindset in systems design. Requirements, architecture, process.”

Инженерный agile mindset – это бизнес-обоснованность инженерии плюс частые поставки just in time.

Вспомните, когда в последний раз Вам приходилось из последних сил доказывать преимущества архитектурного решения, но так и не достигнуть успеха. Или когда вы с триумфом внедряли на первый взгляд абсолютно верное решение, терпящее в последствии полное фиаско. Подобные моменты порождают ряд справедливых вопросов: «Что я сделал не так? Как грамотно и логично преподнести свою точку зрения? В чем разница и где грань между осознанными и обоснованными архитектурными решениями и дилетантским подходом?»
Этот тренинг про здравый смысл – про обоснованность инженерных решений в условиях неопределенности. Мы разберем, от чего зависят инженерные решения и научимся четко обосновывать их. Задумаемся, какими должны быть ожидания от архитектутры и есть ли она вообще у Вас в проекте. Научимся объективно решать инженерные конфликты, и Вы навсегда забудете слово «холивар». Совершенно по-новому взглянем на шаблоны проектирования и теперь выжмем из них максимум. Поймем, как эффективно выстраивать документацию к системе, чтобы она действительно начала работать, а не была write-only. Научимся фокусироваться в своих решениях и наконец-то выясним, с чего начинать – со схемы БД или concurrency design. И одна из важнейших вещей тренинга – научимся не делать лишнюю работу. Мы научимся сжимать архитектурный этап без потери качества, чтобы как можно быстрее начать поставки.

Поэтому если Вы замучились от неполноты и изменчивости требований, от накопившегося технического долга, от бесконечных холиваров и вообще непонятно, что этот бизнес от Вас хочет – этот тренинг для Вас.

Для кого

  • Для инженеров: архитекторов и разработчиков.
  • Для техменеджеров: тимлидов и техлидов.
  • Для менеджеров: проектных менеджеров и продуктовых менеджеров

Опыт на старте

  • Ожидаемый уровень участников: базовый и уверенный.
  • Желателен опыт промышленной разработки от 1 года.

После тренинга участники смогут

  • Проинспектировать существующую архитектуру на предмет соответствия бизнес-задачам и стратегии – выбрать ключевые точки для скорейшего рефакторинга
  • Обоснованно принимать архитектурные решения и аргументированно отстаивать их
  • Обеспечить необходимую архитектурную гибкость
  • Снизить текущие затраты за счет четкой фокусировки на действительно важных вопросах
  • Снизить затраты и риски будущей поддержки
  • Легко и эффективно разрешать инженерные конфликты – без ругани, обид и драм
  • Обоснованно принимать инженерные решения в условиях неопределенности – когда непонятно до конца, что и как делать
  • Ускорить поставку за счет осмысленного параллелизма работ
  • Понимать потребности и образ мышления бизнеса – давать бизнесу действительно нужную ему информацию о статусе проекта
  • Минимальными усилиями перестроить процесс производства для снижения времени поставки и повышения качества


  • Постановка проблем
    • Знакомство и сбор проблем участников
    • Обзор тренинга
    • Разбивка на команды
  • Зачем нужна архитектура – как не угробить проект
    • Что такое архитектура?
    • Где граница микро-дизайна и архитектуры?
    • Кто является потребителем архитектурных артефактов?
    • На какие ответы должна отвечать выбранная архитектура?
  • Архитектура как план рисков – компенсировать неопределенность будущего
    • Какие источники проектных рисков мы можем выделить?
    • Как на ранних этапах можно адресовать внешние риски в своей архитектуре?
    • Как на ранних этапах можно адресовать внутренние риски в своей архитектуре?
    • Границы системы и способы их фиксации
  • Архитектура как план проекта – повысить эффективность производства
    • Какие требования предъявляет к архитектуре PM/РП?
    • Как можно по архитектуре создать план проекта?
    • Видно ли критический путь?
    • Как распараллелить работы?
  • Архитектура как требования к компонентам – обеспечить гибкость и снизить стоимость поддержки
    • На какие предположения мы опираемся при проектировании с использованием готовых компонентов или внешних систем?
    • Как можно сформулировать наши ожидания от внешних компонентов?
    • Как адресовать риски несоответствия нашим ожиданиям?
  • Требования к архитектуре: начало чеклиста – что не забыть и не упустить
  • Архитектурная методология – как принимать инженерные решения в пользу бизнес-потребностей и делать решения прозрачными для бизнеса
    • От чего зависят решения в дизайне и архитектуре? Где найти ответы, чтобы обосновать их?
    • Как компенсировать неопределенность требований?
    • Как обосновать решения по методологии?
  • Архитектура как функция от требований – как делать что нужно, снизить rework и повысить удовлетворенность клиентов
    • Какие виды требований можно выделить?
    • Как можно определить «критические пути» в требованиях?
    • Как требования определяют границы системы?
    • Какие знаете типовые переходы «профиль требований → типовая архитектура»?
    • Отдельно про масштабируемость
  • «Компромисс» и «Специализация» – как принимать решения в случае конструктивного конфликта ожиданий
    • В каком соответствии находятся требования?
    • Как инженерными решениями адресовать эти связи между требованиями?
  • Как относиться к шаблонам проектирования – их ценность и проблемы
  • Архитектурные точки зрения и документирование архитектуры – как тратить ресурсы сфокусированно и рано адресовать риски
    • В каком виде можно документировать архитектурные решения? Какие артефакты можно выдавать?
    • Что важнее – схема БД или concurrency design?
    • В какой момент документировать и что?
  • Требования к архитектуре: продолжение чеклиста
  • Что бизнес хочет от архитектуры?
    • Как начать поставлять быстрее?
    • Сжатие архитектурного этапа без потери качества
  • Архитектурная методология – как проектировать в условиях внешней неопределенности
    • Что вы делаете, если не знаете будущих изменений?
    • Оси вариативности требований
    • BDUF vs YAGNI
    • Инкапсуляция изменчивости
  • Архитектурная методология – как проектировать в условиях внутренней неопределенности
    • Ключевые ожидания к компонентам, исходя из требований
    • Ранние проверки ключевых контрактов
    • Внешняя и внутренняя экспертиза, каркасные прототипы
    • Тесты как ранняя проверка контракта
  • Требования к архитектуре: завершение чеклиста
  • Итоговая ретроспектива: что применить на производстве уже завтра

В чем отличие от других тренингов по архитектуре и проектированию в Agile

Мы собрали ключевые техники проектирования из основных методологий и архитектурных стандартов и перевели на человеческий язык. Подключили наш собственный опыт и работающие решения наших многочисленных заказчиков.

При этом формат тренинга – практический, поэтому к большинству решений участники придут самостоятельно, что дает колоссальную конверсию навыков в применение на производстве. В итоге участники смогут начать поставлять ПО гораздо быстрее без потери качества.
Фокус на том, как сократить время поставок без потери качества, чтобы разработка и бизнес как можно скорее получили ценность от системы.

Workshop “Microservices Lifecycle”

Microservices are becoming more and more popular and, as with every other new trend, often implemented without enough experience. Idea behind them easy to explain. Brake monolithic application into smaller independent services. That’s it. That is what many think microservices are about. However, implementation is much harder to master. There are many things to consider when embarking down this path. How do we organize microservices? Which technologies to use and how? Should they be mutable or not? How to test them? How to deploy them? How to create scalable and fault tolerant systems? Self-healing, zero-downtime and logging? How should the teams be organized? Today’s successful implementations of microservices require all those and many other questions to be answered. It’s not only about splitting things into smaller pieces. The whole development ecosystem needs to be changed and we need to take a hard look at the microservices development lifecycle.

This workshop will go through the whole **microservices development lifecycle**. We’ll start from the very beginning. We’ll define and design architecture. From there on we’ll move from requirements, technological choices and development environment setup, through coding and testing all the way until the final deployment to production. We won’t stop there. Once our new services are up and running we’ll see how to maintain them, scale them depending on resource utilization and response time, recuperate them in case of failures and create central monitoring and notifications system. We’ll try to balance the need for creative manual work and the need to automate as much of the process as possible.

This will be a journey through all the aspect of the lives or microservices and everything that surrounds them. We’ll see how microservices fit into continuous deployment and immutable containers concepts and why the best results are obtained when those three are combined into one unique framework.

Technical requirements

It is an hands-on workshop and will require participants to bring their own laptops. Participants should have laptops with at least 8 GB of memory. Each of them will receive a script (tested on Ubuntu, MacOS and Windows) that will setup the whole environment required for the workshop.

Training “Agile Testing”

Целевая аудитория

Разработчики, тестировщики, менеджеры проектов, лидеры команд.

Описание тренинга

Agile методологии заставили инженеров всерьез задуматься о качестве выпускаемого продукта. Главной причиной этому есть сжатые сроки и требование к непрерывной поставке рабочей версии системы. Тактика водопада или мини-водопадов перестала давать требуемой эффективности. Ведь чем дольше мы разрабатываем и тестируем систему, тем больше риски, что этот продукт уже никому не будет нужен. В такой динамичной среде следует всерьез задуматься о тестировании.

Классическое тестирование в динамичной среде работает с минимальной эффективность и пора искать новые подходы, которые смогут повысить результативность команды и при этом выпускать продукт требуемого качества в срок. Многие, кто говорит об Agile разработке, пропускают тестирование или говорят о том, что нужно использовать автоматизацию и заставлять разработчиков писать автотесты. Это правда, но лишь отчасти. Инженер по тестированию в Agile команде может принести много пользы, но это требует определенной подготовки и навыков. Использование старых артефактов и подходов к тестированию может погубить проект или превратить его в бюрократическую машину, что приведет к старой модели мини-водопадов. Так же не стоит забывать, что Quality Assurance – это ответственность всей команды, а не отдельно-взятого человека.

Многие говорят, что Testing Is Dead, но мы с этим не согласны и считаем, что это очередной маркетинговый ход. Тестирование не умерло, оно эволюционировало в новую форму, информацию о которой мы и хотим вам донести на тренинге.

Детальная программа

День 1

Модуль 1

Модуль 2

  • Первые фазы проекта
    • Идея
    • Lean Canvas/Бизнес модель
  • User Stories Workshop
    • User Personas
    • Specification by Example
    • Story Mapping
    • Minimal Working Product
    • Acceptance Criteria
    • Как тестировщики могут помочь в этом процессе?

Модуль 3

  • Работа по методологии Scrum
    • Что такое Scrum?
    • Подготовка Product Backlog
    • Sprint 0
    • Sprint Backlog
  • Этап планирования
    • Что такое Story Point?
    • Planning Poker
    • Иерархия задач
    • Оценки задач со стороны тестирования
    • Почему Testability это важно и как этого добиваться?
  • Практика: Эмитация Planning Poker для оценки в Story Points
  • Что такое Acceptance Testing?
    • Приемочный сценарии
    • Gherkin синтаксис
  • Практика: Написание приемочных тестов на подготовленные User Stories
  • Стратегия тестирования продукта
    • Нужен ли тест план?
    • Что такое тестовая стратегия?
    • SFDPOT
    • Функциональная карта системы
    • Практики тест дизайна
    • Pairwise, Tractability и прочие матрицы
    • Mockups

Модуль 4

  • Автоматизация
    • Классический подход к автоматизации в виде перевернутой пирамиды
    • Тестирование по подходу правильной пирамиды
    • Непрерывная интеграция
    • Сборка и установка проекта
    • Тестовое Покрытие
    • Использование автоматизации для облегчения рутинных задач
    • Должен ли тестировщик заниматься только автоматизацией на 100%?

Модуль 5

  • Acceptance Test Driven Development
    • Взаимодействие тестировщиков, аналитиков и программистов на ранних этапах разработки
    • 3 Amigo Meetings
    • Definition Of Done
  • Что может делать тестировщик, когда тестировать нечего?
    • Тщательный анализ документации
    • Подготовка тестовых данных
  • Создание Step Definitions для автоматизации
    • Помните о ваших пользователях
    • Демонстрация написания Acceptance Test на примере Cucumber-JVM
  • Практика: Создание функциональной карты приложения
  • Демонстрация программирования регрессионных тестов
  • Тестирование
    • Что такое тестирование?
    • Что такое исследование?
    • Что такое Exploratory Testing?
  • Тестовые квадранты и их заблуждение
  • Нахождение баланса между скриптовым и ad-hoc тестированием
  • Отчетность и документация
  • Нужны ли тест менеджеры?
  • Session Based Test Management
  • Взаимодействие тестировщиков и программистов на завершающих этапах разработки
  • Командный подход к тестированию

Модуль 6

  • Еще раз о критерии готовности – Definition Of Done
  • Демо и какая роль тестировщика в нем
  • Ретроспектива и о чем должен не забывать тестировщик
  • Готовимся к релизу и кто за него должен отвечать?
  • User Acceptance Testing
  • Как лучше проводить Performance Testing?
  • Когда начинать готовиться к Load Testing?
  • Стоит ли тестировать Security?
  • Pre-production
  • Production
  • Схема работы в Scrum командах 5-9 человек
  • Подведение итогов первого дня
  • Советы и рекомендации тренера

День 2

Модуль 7

  • 10 принципов Agile тестировщика
  • Одна итерация в жизни Scrum тестировщика
  • Enterprise Scrum и проблемы с тестированием зависимостей
    • Обязательные митинги для тестировщиков
    • Варианты синхронизации с членами команды
    • Рекомендуемые документы для работы
  • Частые проблемы организации процесса тестирования в больших командах

Модуль 8

  • Цель от бизнеса: делать поставку чаще
  • Правила методологии Kanban
  • Что ждет тестировщиков в еще более динамичном процессе?
  • Больше дисциплины, культуры разработки и автоматизации в команде
  • Определение частых застоев (bottlenecks) в процессе разработки
  • Как избежать и решить застои?
  • Как работать с WIP ограничениями?

Модуль 9

  • Практика: Имитация процесса разработки в динамической среде
  • Практика: Серия Debrief митингов
  • Практика: Подготовка отчета о тестовой сессии

Модуль 10

  • Процесс учета задач и конфигурация специализируемых систем
  • Документация или как не превратиться в бардак или бюрократизированную машину?
  • Как переходить к Agile разработке?
  • Стоит ли переходить на Agile разработку?
  • Agile анархисты и их истории
  • Частые проблемы, с которыми может столкнуться тестировщик в новой среде
  • Подведение итогов второго дня
  • Рекомендации и советы тренера

Price of the data you’ve lost

I’ve been working as software engineer for a long time and almost every time I am introduced to a new application I feel desperation on the data organization within it. When I have a chance to talk to developers they explains me that it is done according to initial requirements or because of performance reasons or even because of YAGNI and KISS principles.

As a result, huge amount of incredibly valuable information was lost and was lost intentionally. It is not their direct fault because it was implemented “exactly” what they had been told. However, I do think that the design flaws were so obvious that the guys should at least be ashamed.

I want to share my vision on the application design in terms of data processing. I will show how precious data can be and why you cannot take it lightly. Code aside I will be talking only about data and data alone. I hope it will help you avoid numbers of design pitfalls when it comes to data.


Estimation patterns for engineering tasks. How to avoid comparison of warm with soft.

Estimates is one of the most difficult issues in SWE. It’s not because of lack of our competencies but complexity and non-linearity of social and software systems.
In this talk I’ll try to show why sometimes we can’t do estimate at all but sometimes we can. We’ll see the patterns of internal engineering complexity and tools to deal with it. What’s the difference of R and D and how to estimate in these contexts. So for outcome I want to give some working patterns of estimating you can take to your project rigth now.

Points of View: key to good communication in the team – see quality behind diagrams

I think the root of all evil in software development is misunderstanding and communication impedance of the team. Especially if team members are in different production roles. This directly leads to project and product fails.

In case of issues and fails team members reactively solve it. But can we behave more proactive? This means managing quality early and not to be a hostage of issues.
Yes, we can! And the key to proactive quality management is to decrease mentioned misunderstanding and communication impedance of team.

In this talk I’ll describe team comminucation framework based on concept of Points Of View. Also we’ll disscuss three particular patterns you can instatly take away to your project. Please prepare your own project cases in form of text description or UML so we could discuss it.


Scaling To Infinity: The Quest For Fully Automated, Scalable, Self-Healing System With Zero-Downtime

It’s been a bit over a year since Docker released its first “production ready” release. A new door was opened and many of us stepped through. We are creating immutable containers and deploying them to production in a much easier and more reliable ways than we did before. However, with widespread usage of Docker a huge number of new possibilities started to emerge.

Can we automatically scale (and de-scale) services depending on traffic and server load? Do we need to know where will the applications be deployed? Can we treat all our servers as one big “server farm”? What can we do with auto-discovery? Can we recuperate from failures without human intervention? Can we truly accomplish zero-downtime?

This presentation will try to answer those and other questions. It is the result of different proofs of concept done as experiments as well as successful implementations of large scalable systems.


Planning – “shmanning”, estimations – “shmetimations”

This talk was inspired by “The Black Swan: The Impact of the Highly Improbable” book written by Nassim Nicholas Taleb. I want to apply his ideas to IT industry and discuss absurdness of it’s basic practices like estimation and planning. Human beings have some very strange habits like building theories just to bring some facts together or believing in such theories with ignorance of facts where they don’t work at all. Managers want to play in such games and even measure success with metrics based on almost nothing – our ability to predict the future. Lets discuss how to change software development processes to avoid fooling yourself and your colleagues.


How to make your functional tests really quick

Functional tests are usually the slowest layer of automated tests for almost every product. They use product via UI, store data in real DB, integrate with external services and do other “slow” things. The first easy answer how to make them fast is to run in parallel. But in reality tests depends on the same data and intersect by some common functionality. In this talk we will review useful techniques and approaches how to win this battle.


Scaling Docker with Kubernetes

Docker is revolutionizing the way people think about applications and deployments. It provides a simple way to run and distribute Linux containers for a variety of use cases, from lightweight virtual machines to complex distributed micro-services architectures.

Kubernetes is an open source project to manage a cluster of Linux containers as a single system, managing and running Docker containers across multiple Docker hosts, offering co-location of containers, service discovery and replication control. It was started by Google and now it is supported by Microsoft, RedHat, IBM and Docker Inc amongst others.

Once you are using Docker containers the next question is how to scale and start containers across multiple Docker hosts, balancing the containers across them. Kubernetes also adds a higher level API to define how containers are logically grouped, allowing to define pools of containers, load balancing and affinity.

Jenkins Continuous Integration environment can be dynamically scaled by using the Kubernetes and Docker plugins, using containers to run slaves and jobs, and also isolate job execution.


Pragmatics of TDD to Evolve Design

Test Driven Design, we hear is a great way to create lightweight design that is easier to maintain and evolve. Unfortunately, just writing test cases mechanically do not lead to good design. In fact, it may really not lead us anywhere we want to really go! In this presentation we will discuss some of the challenges with using test driven development, look at practical and pragmatic solutions that will help us make a good use of this wonderful design tool.

Video part 1:

Video part 2:

Towards an Evolutionary Architecture

Big up front design is discouraged in agile development. However, we know that architecture plays a significant part in software systems. Evolving architecture during the development of an application seems to be a risky business. In this presentation we will discuss the reasons to evolve the architecture, some of the core principles that can help us develop in such a manner, and the ways to minimize the risk and succeed in creating a practical and useful architecture.

Video part 1:

Video part 2:

Software Architecture Anti-Patterns

Applications of different size, business domain and criticality suffer from a huge set of issues, be it boring enterprise software, “Highly-Loaded” social network or a cozy startup. In this talk Eduards Sizovs will cover Software Architecture issues that he finds the most prevailing nowadays and what you can do with that. Think big!


8 Things That Make Continuous Delivery Go Nuts

Continuous Delivery is still trendy and everyone wants to get there, but there are so many walls you have to break and nerves to spoil! In this talk Eduards will present real-world battle stories of continuous delivery adoption, 8 underlooked things that tend to go wrong and what practices can you apply in order to survive.


“Automation testing of responsive design”

I want to discuss an area of QA automation which always is out of the automation – responsive design. Automation of functional use cases become regular in modern web-applications. That’s mean automation scripts do some input via web interface and than check output which they also retrieve from web interface. But often this process doesn’t include check of UI by itself.

So the question is how to automate verification of UI features? In general automation testing tools are not smart enough to do this in entire sense of the context. Fortunately Galen Framework gives us a new hope, because it aimed to work with dimensions of web elements depends on browser window size. Hence we can add a new level of automation to our good old functional tests.

“Why testing take so much time?”

Most of you work by iterative development approaches and regression testing is done in each iteration (at least I hope so). And quite frequently we see following picture: in one iteration testing is finished in time, but in the next one it is only 50% completed. WTF? We added small increment of functionality in this iteration! From such incidents managers (if you still have them) start to “analyze and tune” performance of testers. They usually use stats and metrics… May be some testers are fired during this process… Or new “more performant” are hired… But situation continues to happen again and again. In this talk I will try to show why testing is really slowed down and how to fix it.