|
| 07:30 am |
Registration |
|
Welcome Session |
| 08:30 am |
Introduction & Speed Dating  |
|
Session 1 : Planning the Unplannable? |
|
09:00 am |
Invited Talk by Chuck Rossi
(Release Engineering Manager at Facebook, USA)
Moving to mobile: The challenges of moving from web to mobile releases. 
Facebook's web frontend release process has evolved into a large scale pseudo-continuous deployment system where we release anywhere from 30 to 300 changes per push, twice a day, coming from around 1000 developers in four distributed engineering offices. What lessons did we take from our successful web deployments when we made the shift to a mobile-centric company? We'll discuss how we managed to keep features of our fast flowing development and release process and apply them to the very different world of mobile release, which is essentially a shift back to packaged software. We'll describe how we maintain a date based release schedule, how we test and collect mobile metrics, and describe the real-world issues of dealing with package deployment and end-user uptake.
Bio
Chuck Rossi (@chuckr) leads Release Engineering at Facebook and started as Facebook's first release engineer in 2008. Chuck has worked in release engineering for over 20 years and prior to joining Facebook, Chuck was a Senior Build and Release Engineer at both Google and VMware. |
| 10:00 am |
A Prototype Tool Supporting When-to-release Decisions in Iterative Development by
Jason Ho, Shawn Shahnewaz and Guenther Ruhe (University of Calgary, Canada) [research talk]
Continuous Delivery Meets Release Management by Rohit Jainendra (Electric Cloud, USA) [practitioner talk]
Abstract:
Continuous Delivery and DevOps practices are a way for engineering and operations teams to accelerate the delivery of applications. Organizations like Netflix, Etsy, Facebook and Amazon are deploying hundreds of changes daily into their live production environments. With users requiring faster delivery of software, the shift to continuous delivery (CD) has become more important to organizations. The efficiencies of a continuous delivery approach enable software development teams to achieve a reliable flow of software features into production. But while much of focus around the CD approach centers around technical hurdles and culture, an area often overlooked is managing the risk of the application delivery process.
While companies in regulated industries like financial services would benefit from faster time to market and improved qualities resulting from adopting CD practices, how should they deal with audit and compliance requirements? How do they manage the risk associated with delivering changes to a large number of dependent applications running across multiple stacks spanning from mobile to mainframe? Can they deploy changes into production at the same pace as peers in non-regulated environments? How does CD fit in with established release management and ITIL processes?
Based on the experiences of leading global software development teams and working with customers adopting Continuous Delivery practices, I will introduce methods that have been proven to close the gap of managing risk in a continuous delivery approach.
Join this session to: (i) learn about managing release pipelines at an enterprise scale across multiple applications with dependencies amongst them; (ii) hear how teams have integrated Agile and CD practices with release management and ITIL. I will introduce the "Continuous Delivery Dial" that does from 1 to 10. It even goes up to 11 for fans of Spinal Tap.
Discussion |
| 10:40 am |
Coffee Break |
|
Session 2 : Extreme Integration |
| 11:00 am |
Extreme Git Branching for Continuous Delivery by Sarah Goff-Dupont (Atlassian Software, USA) [practitioner talk]
Abstract:
Moving to Git unleashes the power of development branches. Without the clunky overhead of arbitrary code freezes and monolithic mega-merges that plague centralized version control, developers can use branches to isolate work in progress with ease, opening up a whole new level of agility for your team and removing a few hurdles on the path toward continuous delivery.
Teams at Atlassian have taken this to it's logical extreme, creating development branches for each story and bug fix they work on. In concert with an increasingly-automated delivery pipeline, the branch-per-issue process is helping us make our release cycles tighter than ever before.
If it's working for us, it might work for you too. I'll share...
...why a branch-per-story model lays the foundation for delivering working code in a continuous stream
...what our workflows look like for individual developers
...how we've changed up our continuous integration and code review practices
...lessons we've learned about dealing with merge conflicts, multiple-repository projects, and long-running version branches
…tips for evolving this from "development process" into "development culture"
Git ready, Git set... go!
How much does this commit cost? - A position paper by
Yujuan Jiang, Bram Adams and Daniel M. German (Polytechnique Montreal/University of Victoria, Canada) [research talk]
Dependency Management for Continuous Release by Chuck Karish (Google, USA) [practitioner talk]
Abstract: As we automate our development, validation, and release actions to achieve a smooth flow of innovations from developer to user, we identify bottlenecks and make changes to ease them. Managing software dependencies is critical in easing some bottlenecks. In this talk I outline strategies that some large companies have used to manage dependencies, and discuss strategies that might be used by smaller companies. Discussion |
|
Session 3 :
Building the Future |
| 12:00 pm |
Mozilla's hybrid continuous integration by Armen Zambrano Gasparnian (Mozilla, Canada) [practitioner talk]
Abstract: Over the last few years, Mozilla has seen a large growth in its number of contributors. The growth comes with an increased infrastructure load. This has lead, many times, in the development load outpacing the current infrastructure capacity.
Unfortunately, our procurement process can be too slow and expensive to keep up. In the last two years, we have been moving an increasing number of builds and tests of Firefox for desktop, Firefox for mobile and Firefox OS to the cloud. Doing so has allowed us to increase 'on-demand' our capacity to handle the sudden spikes in load produced by development.
This shift in the nature of the infrastructure comes with great opportunities as well as challenges.
Extending the Buildpack API for multi-platform builds by Alan Grosskurth (Package Lab, USA) [practitioner talk]
Abstract: Buildpacks are an emerging standard for defining and executing build processes. However, since they were initially intended for web applications, they have some limitations. This talk discusses extensions we have made to the Buildpack API to support complex, multi-platform builds such as web browsers (Chromium, Firefox) and mobile operating systems (Android, FirefoxOS).
Discussion |
| 12:40pm |
Lunch & Posters |
|
Session 4: Why should we do Release Engineering Again? |
|
02:00 pm |
Invited Talk by Dinah McNutt
(Release Engineer at Google, USA)
The 10 Commandments of Release Engineering.
This talk will present 10 commandments that I have found to be truths in my 20 years of building commercial software. For each truth, I will provide reasons and examples that support the truth. The commandments are simply solutions to requirements or problems, but it is more entertaining and provocative to present the truths up front, let the listener react, and then discuss the requirements and problems that led to the truth.
Bio
Dinah McNutt is a Release Engineer at Google, Inc. She has been involved with system administration since the mid-1980s. Some of her accomplishments include writing the "Daemons & Dragons" column for Unix Review Magazine and writing for SunExpert Magazine, Byte, and other publications. She has twenty years of commercial release engineering experience and has released all types of UNIX-based software, from shrink-wrapped to Web-based services to network appliances. |
| 03:00 pm |
On the Influence of Release Engineering on Software Reputation by
Christian Plewnia, Andrej Dyck and Horst Lichter (RWTH Aachen University/Software Construction, Germany) [research talk]
Challenges in Practicing High Frequency Releases in Cloud Environment by
Liming Zhu, Donna Xu, Xiwei Xu, An Binh Tran, Ingo Weber and Len Bass (NICTA/Sydney University, Australia) [research talk]
Quantifying the Business Value of Release Engineering by Dan Tehranian (Virtual Instruments, USA) [practitioner talk]
Abstract:
Within the software development community the practices of continuous integration, continuous delivery, and other development process improvements have become widely adopted in recent years. It's generally accepted that these improvements to tools, process, and culture will have a positive impact on a software product's time to market, quality, feature set, etc. But how can one quantify the business value of these development process enhancements?
Building on the RELENG 2013 keynote "Release Engineering as a Force Multiplier" by John O'Duinn, this talk will cross the disciplines of technology, economics, and finance to provide a quantitative and practical walk-through of how to bridge the gap between technologists and business management.
Relevance:
Release engineers are in a unique position to deliver an extraordinary amount of value to an R&D organization. By driving development process efficiencies within an organization, a release engineer has the opportunity to deliver many times more value than most software developers by increasing the productivity of each engineer on the team. Creating this value is a challenge that release engineers continually take on, but measuring the value generated by these efforts is regularly overlooked.
Given that there is no precise template for how every R&D team should operate, release engineers must use their creativity and insight to identify the specific opportunities for improvement within their teams. This talk will discuss common technical, organizational, and process pitfalls that plague organizations. It will also discuss the technical details and quantifiable business value of previously completed projects that have generated millions of dollars of value, for example: automating the creation of development environments with Vagrant, improving product build times by 15x via Jenkins, and re-architecting the means by which terabytes of build artifacts were distributed to VMware's global R&D organization.
Another obstacle in generating this value is obtaining buy-in from stakeholders. This talk will cross over into the field of finance and describe how to bridge the language gap between technologists and the business school-educated decision-makers they will need to influence. By learning how to properly quantify and advocate potential improvements to these decision makers, release engineers can be more successful in delivering on their ideas and ultimately deliver millions of dollars of value to their R&D organizations.
Bio:
Dan Tehranian is a release engineer and the "Economist in Residence" at Virtual Instruments, Inc., a dynamic and rapidly growing technology company headquartered in the heart of Silicon Valley. Prior to Virtual Instruments, Dan was a senior release engineer at VMware during its explosive growth years, 2007-2012.
In his 18 year technology career, Dan has contributed in various technical roles ranging from IT, QA, product development, release engineering, DevOps, and R&D management. He has worked in organizations of all sizes ranging from early-round startups to mega-cap corporations.
Dan studied Computer Science at UMass-Amherst and Economics at Harvard.
Discussion |
| 04:00 pm |
Coffee Break |
|
Session 5: What did those Release Engineers do?
|
| 04:30 pm |
Contrasting Development and Release Stabilization Work on the Linux Kernel by
Md Tajmilur Rahman and Peter Rigby (Concordia University, Canada) [research talk]
Factors Impacting Software Release Engineering: A Longitudinal Study by
Noureddine Kerzazi and Foutse Khomh (Payza.com/Polytechnique Montreal, Canada) [research talk]
Release Engineering Ain't What It Was by Curt Patrick (Netflix, USA) [practitioner talk]
Abstract: During the course of my twenty-four years as a Release Engineer, although tools have improved, machines have gotten faster and we have become more interconnected, for the first three quarters of that time most of what I had been doing had not changed that much. I was still gathering up tasks that slowed down developers in their work, taking responsibility for automating, running and monitoring those tasks, and taking further responsibility to chaperon the product out the door to the customer.
More recently, however, I have been noting some evolutionary changes that seem like game changers to me. Especially as a contributor in the Engineering Tools team at Netflix over the past four years (we provide build and release best practices and tooling for the entire company) I have not only had the chance to participate in some changing trends as they happen but am in an environment where the changes get discussed extensively in collaboration. It has given me pause to consider which changes are window dressing or simple technical improvements, versus fundamental shifts. The changing landscape of software development is touching every company today, presenting professional Release Engineers interesting and challenging opportunities within their specific contexts.
In my presentation I will draw on my recollections of "the early days" to point out how a few fundamentals used to be but aren't so much any more. And, more importantly, how failing to make note of these changes can result in obsolete thinking habits which are now counter-productive. Technical changes are more obvious, but thinking habits more pervasive. As the development environment changes, our approaches to solving Release Engineering problems must be refined. The objectives don't change all that much, but our strategies must. I will call out a few modern trends in the development environment that impress me for their impact on Release Engineers. Although it is likely that you will have to adopt and modify anything I have to share, it is my goal to share a few observations about how these changes impact your day-to-day job and should impact your preparations for the future.
Discussion |
| 05:30 pm |
Panel & Wrap-Up |
| 06:30 pm |
Leaving for Workshop Dinner |
List of Accepted Posters:
|
CFP (pdf)
CFP (txt)