Releasing the monolith on a daily basis
Struggling to get software released on a daily basis? Stressed about how to apply the same techniques that make companies successful with continuous deployment? Learn from the experience of Atlassian’s Confluence development team on its journey from releasing once a week to every day. The talk begins with the team’s build and deployment process, providing insights into dealing with particularly large builds and tests and deployment complexities. Next, the speaker explores, in detail, the cultural and technical problems that prevented the team from making that transition quickly, including: slow builds, flaky tests, a lack of automation, the wrong mindset and dealing with release blockers, to name a few. The talk concludes with a discussion of the strategies the team has implemented to resolve these problems, including: reducing complexity, defining ownership, setting and monitoring time limits and establishing a “culture of green.” Learn how you, too, can make continuous delivery happen in a real, (and not so perfect!), engineering organization.
Outline/Structure of the Talk
Continuous Delivery is a solved problem. Really? A lot of organizations still struggle for many reasons and Confluence was one of them. What if the world your engineering team lives in is not perfect. This talk is all about making continues deployment happen in a real and not so perfect engineering organization. This talk is all about the options you have a to achieve a goal without trying to solve all the problems at once.
The talk will start with setting the scene of Confluence’s build and deployment process. There will be some interesting insights in the sheer size of builds, tests and the complexities we have around deployments. Once the stage is set for Confluence’s environment, the next step is to explore the problems that are preventing the team to move faster both culturally and technically. To name a few: Build structure, build times, flakey tests, lack of automation, wrong culture, dealing with release blockers, test automation, post-deployment verification, monitoring and operating a production system.
Message to the committee
With the problems defined, we will go into them in more detail and also learn about the ways the Confluence team resolved them. To wrap it all up we go through the current situation and explain how far we have come with the strategies taken and implemented by the team. As a bonus, a sneak peak of the road ahead for Confluence's Continuous Deployment and Site Reliability Engineering will be shared with the audience.
It will also give attendees a great insight the technical solutions and an approach method that is very valuable in any organization.
Engineers, Engineering Managers, Architects anyone involved in the release process
schedule Submitted 2 years ago
People who liked this proposal, also liked:
Vincent Kok - Need-to-Know Patterns for building microservicesVincent KokEngineering ManagerAtlassian
schedule 2 years agoSold Out!
Microservices are still the rage—and for good reason. However, like any other emerging architecture, they’re not a silver bullet and anyone who adopts this architecture will need to learn and identify new patterns, patterns you didn’t need to know about in a monolithic world. This session discusses when to make the switch to a microservice architecture and the patterns Atlassian has identified in building microservices. They include patterns in code organization, configuration management, deployment, resilience, and decomposition. After this session, you will be able to identify whether you should give microservice architecture a try and, if so, you will have a toolbox full of patterns to apply in your own situation.