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.

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.

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.

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!

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.

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.

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.

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.

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.

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.

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 😉

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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!

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.

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.

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.

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.

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.

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.

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.

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.

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.

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! 😉

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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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 @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 летнего опыта тренера по разработке софта за деньги 🙂

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

“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!

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.

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.

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.

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.

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.

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!

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.

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.

Video:

• 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).

Video:

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.

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.

Video:

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.

Video:

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.

Video:

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”.

Video:

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

Video:

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

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

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

Для кого

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

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

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

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

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

Программа

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

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

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

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

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

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

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

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

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

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

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

День 1

Модуль 1

• Основы Agile Software Development
  • Agile Manifesto
  • Agile Principles
  • Основные заблуждение в Agile философии
  • Альтернативные Manifesto
    • http://www.halfarsedagilemanifesto.org
    • http://www.waterfallmanifesto.org
    • http://programming-motherfucker.com
    • http://manifesto.softwarecraftsmanship.org

Модуль 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 анархисты и их истории
• Частые проблемы, с которыми может столкнуться тестировщик в новой среде
• Подведение итогов второго дня
• Рекомендации и советы тренера

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.

Video:

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.

Video:

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.

Video:

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:

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!

Video:

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.