Invited talk at the Leaders of Tomorrow Symposium of the 23rd IEEE International Conference on Software Analysis, Evolution, and Reengineering (SANER 2016).
The presentation (and its accompanying paper, see http://mcis.polymtl.ca/publications/2016/fose.pdf) explain the basics of release engineering pipelines, common challenges industry is facing as well as pitfalls software engineering researchers are falling into.
Speakers are Bram Adams (MCIS, http://mcis.polymtl.ca) and Shane McIntosh (McGill University, http://shanemcintosh.org).
A video-taped version of the talk will be available soon at https://www.youtube.com/channel/UCL8yG6qpHk7V66l1Jt3aZrA/featured.
Becoming A Plumber: Building Deployment Pipelines - LISA17Daniel Barker
A core part of our IT transformation program is the implementation of deployment pipelines for every application. Attendees will learn how to build abstract pipelines that will allow multiple types of applications to fit the same basic pipeline structure. This has been a big win for injecting change and updating legacy applications.
The 10 Commandments of Release EngineeringSolano Labs
This presentation on The 10 Commandments of Release Engineering is from the December 2013 Automated Testing San Francisco meetup that took place at New Relic's HQ in San Francisco. The author/presenter is Dinah McNutt, Release Engineer at Google. Dinah distills the truths that she's found in her 20 years of building commercial software.
For each truth, she will provide reasons and examples that support the truth. Some of the commandments are controversial, but she will include examples of where these commandments do not apply.
Feel free to join us at our next monthly meetup in San Francisco, New York, or Boston. Find us at #AutoTestSF / #AutoTestNYC / #AutoTestBoston
---
About Dinah McNutt:
Dinah McNutt is a Release Engineer at Google, Inc and is also chairing the USENIX 2014 Summit on Release Engineering. She has been involved with systems administration since the mid-1980’s. Some of her accomplishments include writing the Daemons & Dragons column for Unix Review Magazine, writing for SunExpert Magazine, Byte, and other publications. She has served on the LISA program committee several times including chairing the conference. She has 20 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.
Becoming a Plumber: Building Deployment Pipelines - RevConfDaniel Barker
A core part of our IT transformation program is the implementation of deployment pipelines for every application. Attendees will learn how to build abstract pipelines that will allow multiple types of applications to fit the same basic pipeline structure. This has been a big win for injecting change and updating legacy applications.
A Declarative Approach for Performance Tests Execution in Continuous Software...Vincenzo Ferme
Software performance testing is an important activity to ensure quality in continuous software development environments. Current performance testing approaches are mostly based on scripting languages and framework where users implement, in a procedural way, the performance tests they want to issue to the system under test. However, existing solutions lack support for explicitly declaring the performance test goals and intents. Thus, while it is possible to express how to execute a performance test, its purpose and applicability context remain implicitly described. In this work, we propose a declarative domain specific language (DSL) for software performance testing and a model-driven framework that can be programmed using the mentioned language and drive the end-to-end process of executing performance tests. Users of the DSL and the framework can specify their performance intents by relying on a powerful goal-oriented language, where standard (e.g., load tests) and more advanced (e.g., stability boundary detection and configuration tests) performance tests can be specified starting from templates. The DSL and the framework have been designed to be integrated into a continuous software development process and validated through extensive use cases that illustrate the expressiveness of the goal-oriented language, and the powerful control it enables on the end-to-end performance test execution to determine how to reach the declared intent.
My talk from The 9th ACM/SPEC International Conference on Performance Engineering (ICPE 2018). Cite us: https://dl.acm.org/citation.cfm?id=3184417
Collecting and Leveraging a Benchmark of Build System Clones to Aid in Qualit...Shane McIntosh
Build systems specify how sources are transformed into deliverables, and hence must be carefully maintained to ensure that deliverables are assembled correctly. Similar to source code, build systems tend to grow in complexity unless specifications are refactored. This paper describes how clone detection can aid in quality assessments that determine if and where build refactoring effort should be applied. We gauge cloning rates in build systems by collecting and analyzing a benchmark comprising 3,872 build systems. Analysis of the benchmark reveals that: (1) build systems tend to have higher cloning rates than other software artifacts, (2) recent build technologies tend to be more prone to cloning, especially of configuration details like API dependencies, than older technologies, and (3) build systems that have fewer clones achieve higher levels of reuse via mechanisms not offered by build technologies. Our findings aided in refactoring a large industrial build system containing 1.1 million lines.
Becoming A Plumber: Building Deployment Pipelines - LISA17Daniel Barker
A core part of our IT transformation program is the implementation of deployment pipelines for every application. Attendees will learn how to build abstract pipelines that will allow multiple types of applications to fit the same basic pipeline structure. This has been a big win for injecting change and updating legacy applications.
The 10 Commandments of Release EngineeringSolano Labs
This presentation on The 10 Commandments of Release Engineering is from the December 2013 Automated Testing San Francisco meetup that took place at New Relic's HQ in San Francisco. The author/presenter is Dinah McNutt, Release Engineer at Google. Dinah distills the truths that she's found in her 20 years of building commercial software.
For each truth, she will provide reasons and examples that support the truth. Some of the commandments are controversial, but she will include examples of where these commandments do not apply.
Feel free to join us at our next monthly meetup in San Francisco, New York, or Boston. Find us at #AutoTestSF / #AutoTestNYC / #AutoTestBoston
---
About Dinah McNutt:
Dinah McNutt is a Release Engineer at Google, Inc and is also chairing the USENIX 2014 Summit on Release Engineering. She has been involved with systems administration since the mid-1980’s. Some of her accomplishments include writing the Daemons & Dragons column for Unix Review Magazine, writing for SunExpert Magazine, Byte, and other publications. She has served on the LISA program committee several times including chairing the conference. She has 20 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.
Becoming a Plumber: Building Deployment Pipelines - RevConfDaniel Barker
A core part of our IT transformation program is the implementation of deployment pipelines for every application. Attendees will learn how to build abstract pipelines that will allow multiple types of applications to fit the same basic pipeline structure. This has been a big win for injecting change and updating legacy applications.
A Declarative Approach for Performance Tests Execution in Continuous Software...Vincenzo Ferme
Software performance testing is an important activity to ensure quality in continuous software development environments. Current performance testing approaches are mostly based on scripting languages and framework where users implement, in a procedural way, the performance tests they want to issue to the system under test. However, existing solutions lack support for explicitly declaring the performance test goals and intents. Thus, while it is possible to express how to execute a performance test, its purpose and applicability context remain implicitly described. In this work, we propose a declarative domain specific language (DSL) for software performance testing and a model-driven framework that can be programmed using the mentioned language and drive the end-to-end process of executing performance tests. Users of the DSL and the framework can specify their performance intents by relying on a powerful goal-oriented language, where standard (e.g., load tests) and more advanced (e.g., stability boundary detection and configuration tests) performance tests can be specified starting from templates. The DSL and the framework have been designed to be integrated into a continuous software development process and validated through extensive use cases that illustrate the expressiveness of the goal-oriented language, and the powerful control it enables on the end-to-end performance test execution to determine how to reach the declared intent.
My talk from The 9th ACM/SPEC International Conference on Performance Engineering (ICPE 2018). Cite us: https://dl.acm.org/citation.cfm?id=3184417
Collecting and Leveraging a Benchmark of Build System Clones to Aid in Qualit...Shane McIntosh
Build systems specify how sources are transformed into deliverables, and hence must be carefully maintained to ensure that deliverables are assembled correctly. Similar to source code, build systems tend to grow in complexity unless specifications are refactored. This paper describes how clone detection can aid in quality assessments that determine if and where build refactoring effort should be applied. We gauge cloning rates in build systems by collecting and analyzing a benchmark comprising 3,872 build systems. Analysis of the benchmark reveals that: (1) build systems tend to have higher cloning rates than other software artifacts, (2) recent build technologies tend to be more prone to cloning, especially of configuration details like API dependencies, than older technologies, and (3) build systems that have fewer clones achieve higher levels of reuse via mechanisms not offered by build technologies. Our findings aided in refactoring a large industrial build system containing 1.1 million lines.
MOPCON 2015 - Tips of Mobile Continuous Deliveryanistar sung
This deck was my sharing in MOPCON 2015. I told about some tips of continuous delivery in mobile development environment and what we did in Taiwan Yahoo. How to make a success strategy for mobile continuous delivery.
Simple tools to fight bigger quality battleAnand Ramdeo
This presentation was given in GTAC 2008 (Also available on www.TestingGeek.com) and discuss the approach of using SVN commit hooks and batch files as continuous integration system.
Short overview of the main principles of Continuous Integration (CI), describing benefits of CI and showing a smooth path of integrating CI into your development cycle, finishing with a short introduction into Xinc - PHP CI Server and how to utilize it for your projects.
Google在2013開始導入Gradle工具作為新的Android build system,Gradle的使用正是實踐DevOps的良好利器,除了方便進行automated building外, Gradle更幫助我們消弭不同開發環境/工具間的差異問題,如同infarsture as code之於web application/service的重要性,build script as code就是幫助Android App快速發佈版本並維持品質穩定的關鍵最後一哩路。
此次主題將探討如何利用gradle進行精實良好的系統開發配置管理,建立一條下達開發者本地端上通產品發佈系統的透明化產品開發流水線。你是否常常一個App剛發佈不久,下一個idea已經生成,舊程式需要繼續維護同時又要添加新功能,你的開發方法是否能讓多方產品流水線順暢運行而且並行不悖?妥善利用Gradle並深入理解Build by convention的內涵是最好的選擇。
Continuous Deployment of your Application @JUGtoberfestMarcin Grzejszczak
I have stopped counting how many times I’ve done this from scratch” - was one of the responses to the tweet about starting the project called Spring Cloud Pipelines. Every company sets up a pipeline to take code from your source control, through unit testing and integration testing, to production from scratch. Every company creates some sort of automation to deploy its applications to servers. Enough is enough - time to automate that and focus on delivering business value.
In this presentation, we’ll go through the contents of the Spring Cloud Pipelines project. We’ll start a new project for which we’ll have a deployment pipeline set up in no time. We’ll deploy to Cloud Foundry and check if our application is backward compatible so that we can roll it back on production.
Serhii Nezdolii about Mobile apps development (Android, iOS) best practices: Test Driven Development (unit/UI tests), Continuous Integration (Jenkins), Continuous Delivery (TestFlightApp)
Сергій Нездолій про кращі практики розробки мобільних додатків
Сергей Нездолий о лучших практиках разработки мобильных приложений
Continuous Integration for Salesforce1 PlatformTechsophy Inc.
AutoRABIT automates the process of building, testing, and deploying software on the Salesforce1 Platform. It includes powerful metadata management and automation tools. These tools can be used alone or as part of a complete Continuous Integration & Deployment procesess
QA Fest 2018. Adam Stasiak. React Native is Coming – the story of hybrid mobi...QAFest
Main idea of this talk is to show what technologies can be used for cross-platform mobile app development and how to deal with UI tests automation for them. I will outline set of challenges every tester and developer needs to conquer and give some tips how to solve them. During this talk I will present how to apply UI tests in React Native project using Detox framework.
Many Scala developers nowadays consider using Dependency Injection frameworks an anti-pattern incompatible with modern FP settings. We argue that it's just a consequence of a bad experience with legacy Java runtime reflection-based implementations that lack features important for modern functional programming, such as a first-class support for higher-kinded types. We argue that as a paradigm for structuring purely functional programs, DI with automatic wiring compares favorably against implicits, monad transformers, free monads, algebraic effects, cake pattern et al, enabling scaling and a degree of modularity unachievable by any manual wiring approach. This talk covers DIStage – a transparent, flexible and efficient DI framework for Scala that enables late binding, testability, effect separation and modular resource management at scale, working with, instead of compromising the Scala type system.
Documentation: https://izumi.7mind.io/latest/release/doc/distage/
Architecting the Future: Abstractions and Metadata - KCDCDaniel Barker
Kubernetes and Docker are two of the top open source projects, and they’re built around abstractions and metadata. These two concepts are the key to architecting in the future. Come with me as I dig a little deeper into these concepts within k8s and Docker and provide some examples from my own work.
“I have stopped counting how many times I’ve done this from scratch” - was one of the responses to the tweet about starting the project called Spring Cloud Pipelines. Every company sets up a pipeline to take code from your source control, through unit testing and integration testing, to production from scratch. Every company creates some sort of automation to deploy its applications to servers. Enough is enough - time to automate that and focus on delivering business value.
In this presentation we’ll go through the contents of the Spring Cloud Pipelines project. We’ll start a new project for which we’ll have a deployment pipeline set up in no time. We’ll deploy to Cloud Foundry and check if our application is backward compatible so that we can roll it back on production.
[QE 2018] Adam Stasiak – Nadchodzi React Native – czyli o testowaniu mobilnyc...Future Processing
Świat technologii mobilnych od pewnego czasu przechodzi rewolucję – odchodzi się od natywnych aplikacji mobilnych. Jak zatem twórcy aplikacji mobilnych odpowiadają na potrzeby rynku? Czy osoby automatyzujące testy aplikacji mobilnych mają do dyspozycji narzędzia gotowe na technologie, takie jak React Native czy Flutter? Czy można uniknąć pisania oddzielnego kodu testów dla Androida i iOS-a?
W czasie wykładu, na przykładzie aplikacji stworzonej w oparciu o technologię React Native oraz narzędzia Detox, Adam przedstawił praktyczną implementację testów end-to-end oraz ich konfigurację z Continuous Integration.
Hyper-pragmatic Pure FP testing with distage-testkit7mind
Having a proper test suite can turn ongoing application maintenance and development into pure joy – the best tests check meaningful properties, not the implementation details, and hold no impliict assumptions about their test environment - every test case must be self-contained and portable. To ensure that tests are free of implementation details and environment dependency, we may simply run them in a different test environment, with different implementations of components. But the boileplate and manual work involved in rewiring components, writing hardcoded fixtures and setting up different test environments make this very hard to do at scale. To tackle this problem we've created distage & distage-testkit, distage-testkit gives you the following superpowers:
* ability to easily swap out individual components or entire test environments
* principled & leak-free control of global resources for integration testing – docker containers, DBs, DDLs
* execute effects or allocate resources per-test, e.g. generate random fixtures per-test
* first-class testing of functional effects
* write tests as lambdas – access test fixtures via parameters or ZIO Environment
...and more! We'll also discuss general testing practices and what really distinguishes good tests from great tests.
Anatomy of a Continuous Integration and Delivery (CICD) PipelineRobert McDermott
This presentation covers the anatomy of a production CICD pipeline that is used to develop and deploy the cancer research application Oncoscape (https://oncoscape.sttrcancer.org)
Development Lifecycle: From Requirement to ReleaseJulie Meloni
This presentation was given as part of the User Experience (UX) community update series of meetings in the University of Virginia Library. For more information: http://bit.ly/dLbaXO
The Bash Dashboard (Or: How to Use Bash for Data Analysis)Bram Adams
Tutorial on how to use basic Bash concepts and commands to analyze CSV files. It uses a real-life data set and structures the content along concrete analysis questions. Feel free to contact me with questions or suggestions!
MOPCON 2015 - Tips of Mobile Continuous Deliveryanistar sung
This deck was my sharing in MOPCON 2015. I told about some tips of continuous delivery in mobile development environment and what we did in Taiwan Yahoo. How to make a success strategy for mobile continuous delivery.
Simple tools to fight bigger quality battleAnand Ramdeo
This presentation was given in GTAC 2008 (Also available on www.TestingGeek.com) and discuss the approach of using SVN commit hooks and batch files as continuous integration system.
Short overview of the main principles of Continuous Integration (CI), describing benefits of CI and showing a smooth path of integrating CI into your development cycle, finishing with a short introduction into Xinc - PHP CI Server and how to utilize it for your projects.
Google在2013開始導入Gradle工具作為新的Android build system,Gradle的使用正是實踐DevOps的良好利器,除了方便進行automated building外, Gradle更幫助我們消弭不同開發環境/工具間的差異問題,如同infarsture as code之於web application/service的重要性,build script as code就是幫助Android App快速發佈版本並維持品質穩定的關鍵最後一哩路。
此次主題將探討如何利用gradle進行精實良好的系統開發配置管理,建立一條下達開發者本地端上通產品發佈系統的透明化產品開發流水線。你是否常常一個App剛發佈不久,下一個idea已經生成,舊程式需要繼續維護同時又要添加新功能,你的開發方法是否能讓多方產品流水線順暢運行而且並行不悖?妥善利用Gradle並深入理解Build by convention的內涵是最好的選擇。
Continuous Deployment of your Application @JUGtoberfestMarcin Grzejszczak
I have stopped counting how many times I’ve done this from scratch” - was one of the responses to the tweet about starting the project called Spring Cloud Pipelines. Every company sets up a pipeline to take code from your source control, through unit testing and integration testing, to production from scratch. Every company creates some sort of automation to deploy its applications to servers. Enough is enough - time to automate that and focus on delivering business value.
In this presentation, we’ll go through the contents of the Spring Cloud Pipelines project. We’ll start a new project for which we’ll have a deployment pipeline set up in no time. We’ll deploy to Cloud Foundry and check if our application is backward compatible so that we can roll it back on production.
Serhii Nezdolii about Mobile apps development (Android, iOS) best practices: Test Driven Development (unit/UI tests), Continuous Integration (Jenkins), Continuous Delivery (TestFlightApp)
Сергій Нездолій про кращі практики розробки мобільних додатків
Сергей Нездолий о лучших практиках разработки мобильных приложений
Continuous Integration for Salesforce1 PlatformTechsophy Inc.
AutoRABIT automates the process of building, testing, and deploying software on the Salesforce1 Platform. It includes powerful metadata management and automation tools. These tools can be used alone or as part of a complete Continuous Integration & Deployment procesess
QA Fest 2018. Adam Stasiak. React Native is Coming – the story of hybrid mobi...QAFest
Main idea of this talk is to show what technologies can be used for cross-platform mobile app development and how to deal with UI tests automation for them. I will outline set of challenges every tester and developer needs to conquer and give some tips how to solve them. During this talk I will present how to apply UI tests in React Native project using Detox framework.
Many Scala developers nowadays consider using Dependency Injection frameworks an anti-pattern incompatible with modern FP settings. We argue that it's just a consequence of a bad experience with legacy Java runtime reflection-based implementations that lack features important for modern functional programming, such as a first-class support for higher-kinded types. We argue that as a paradigm for structuring purely functional programs, DI with automatic wiring compares favorably against implicits, monad transformers, free monads, algebraic effects, cake pattern et al, enabling scaling and a degree of modularity unachievable by any manual wiring approach. This talk covers DIStage – a transparent, flexible and efficient DI framework for Scala that enables late binding, testability, effect separation and modular resource management at scale, working with, instead of compromising the Scala type system.
Documentation: https://izumi.7mind.io/latest/release/doc/distage/
Architecting the Future: Abstractions and Metadata - KCDCDaniel Barker
Kubernetes and Docker are two of the top open source projects, and they’re built around abstractions and metadata. These two concepts are the key to architecting in the future. Come with me as I dig a little deeper into these concepts within k8s and Docker and provide some examples from my own work.
“I have stopped counting how many times I’ve done this from scratch” - was one of the responses to the tweet about starting the project called Spring Cloud Pipelines. Every company sets up a pipeline to take code from your source control, through unit testing and integration testing, to production from scratch. Every company creates some sort of automation to deploy its applications to servers. Enough is enough - time to automate that and focus on delivering business value.
In this presentation we’ll go through the contents of the Spring Cloud Pipelines project. We’ll start a new project for which we’ll have a deployment pipeline set up in no time. We’ll deploy to Cloud Foundry and check if our application is backward compatible so that we can roll it back on production.
[QE 2018] Adam Stasiak – Nadchodzi React Native – czyli o testowaniu mobilnyc...Future Processing
Świat technologii mobilnych od pewnego czasu przechodzi rewolucję – odchodzi się od natywnych aplikacji mobilnych. Jak zatem twórcy aplikacji mobilnych odpowiadają na potrzeby rynku? Czy osoby automatyzujące testy aplikacji mobilnych mają do dyspozycji narzędzia gotowe na technologie, takie jak React Native czy Flutter? Czy można uniknąć pisania oddzielnego kodu testów dla Androida i iOS-a?
W czasie wykładu, na przykładzie aplikacji stworzonej w oparciu o technologię React Native oraz narzędzia Detox, Adam przedstawił praktyczną implementację testów end-to-end oraz ich konfigurację z Continuous Integration.
Hyper-pragmatic Pure FP testing with distage-testkit7mind
Having a proper test suite can turn ongoing application maintenance and development into pure joy – the best tests check meaningful properties, not the implementation details, and hold no impliict assumptions about their test environment - every test case must be self-contained and portable. To ensure that tests are free of implementation details and environment dependency, we may simply run them in a different test environment, with different implementations of components. But the boileplate and manual work involved in rewiring components, writing hardcoded fixtures and setting up different test environments make this very hard to do at scale. To tackle this problem we've created distage & distage-testkit, distage-testkit gives you the following superpowers:
* ability to easily swap out individual components or entire test environments
* principled & leak-free control of global resources for integration testing – docker containers, DBs, DDLs
* execute effects or allocate resources per-test, e.g. generate random fixtures per-test
* first-class testing of functional effects
* write tests as lambdas – access test fixtures via parameters or ZIO Environment
...and more! We'll also discuss general testing practices and what really distinguishes good tests from great tests.
Anatomy of a Continuous Integration and Delivery (CICD) PipelineRobert McDermott
This presentation covers the anatomy of a production CICD pipeline that is used to develop and deploy the cancer research application Oncoscape (https://oncoscape.sttrcancer.org)
Development Lifecycle: From Requirement to ReleaseJulie Meloni
This presentation was given as part of the User Experience (UX) community update series of meetings in the University of Virginia Library. For more information: http://bit.ly/dLbaXO
The Bash Dashboard (Or: How to Use Bash for Data Analysis)Bram Adams
Tutorial on how to use basic Bash concepts and commands to analyze CSV files. It uses a real-life data set and structures the content along concrete analysis questions. Feel free to contact me with questions or suggestions!
A Qualitative Study on Performance Bugs (MSR 2012)Bram Adams
Software performance is one of the important qualities that makes software stand out in a competitive market. However, in earlier work we found that performance bugs take more time to fix, need to be fixed by more experi- enced developers and require changes to more code than non-performance bugs. In order to be able to improve the resolution of performance bugs, a better understanding is needed of the current practice and shortcomings of reporting, reproducing, tracking and fixing performance bugs. This paper qualitatively studies a random sample of 400 performance and non-performance bug reports of Mozilla Firefox and Google Chrome across four dimensions (Impact, Context, Fix and Fix validation). We found that developers and users face problems in reproducing performance bugs and have to spend more time discussing performance bugs than other kinds of bugs. Sometimes performance regressions are tolerated as a trade- off to improve something else.
http://sail.cs.queensu.ca/publications/pubs/MSR2012_Zaman.pdf
The Evolution of the R Software Ecosystem (CSMR 2013)Bram Adams
Software ecosystems form the heart of modern companies’ collaboration strategies with end users, open source developers and other companies. An ecosystem consists of a core platform and a halo of user contributions that provide value to a company or project. In order to sustain the level and number of high-quality contributions, it is crucial for companies and
contributors to understand how ecosystems tend to evolve and can be maintained successfully over time.
As a first step, this presentation explores the evolution characteristics of the statistical computing project GNU R, which is a successful, end-user programming ecosystem. We find that the ecosystem of user-contributed R packages has been growing steadily since R’s conception, at a significantly faster rate than core packages, yet each individual package remains stable in size. We also identified differences in the way user-contributed and core packages are able to attract an active community of users.
http://sail.cs.queensu.ca/publications/pubs/German-CSMR2013.pdf
An Empirical Study of Build System Migrations in Practice (ICSM 2012)Bram Adams
As the build system, i.e. the infrastructure that constructs executable deliverables out of source code and other resources, tries to catch up with the ever-evolving source code base, its size and already significant complexity keep on growing. Recently, this has forced some major software projects to migrate their build systems towards more powerful build system technologies. Since at all times software developers, testers and QA personnel rely on a functional build system to do their job, a build system migration is a risky and possibly costly undertaking, yet no methodology, nor best practices have been devised for it. In order to understand the build system migration process, we empirically studied two failed and two successful attempts of build system migration in two major open source projects, i.e. Linux and KDE, by mining source code repositories and tens of thousands of developer mailing list messages. The major contributions of this paper are: (a) isolating the phases of a common methodology for build system migrations, which is similar to the spiral model for source code development (multiple iterations of a waterfall process); (b) identifying four of the major challenges associated with this methodology: requirements gathering, communication issues, performance vs. complexity of build system code, and effective evaluation of build system prototypes; (c) detailed analysis of the first challenge, i.e., requirements gathering for the new build system, which revealed that the failed migrations did not gather requirements rigorously. Based on our findings, practitioners will be able to make more informed decisions about migrating their build system, potentially saving them time and money.
http://mcis.polymtl.ca/publications/2012/ICSM2012Roman.pdf
Why do Automated Builds Break? An Empirical Study (ICSME 2014)Bram Adams
To detect integration errors as quickly as possible, organizations use automated build systems. Such systems ensure that (1) the developers are able to integrate their parts into an executable whole; (2) the testers are able to test the built system; (3) and the release engineers are able to leverage the generated build to produce the upcoming release. The flipside of automated builds is that any incorrect change can break the build, and hence testing and releasing, and (even worse) block other developers from continuing their work, delaying the project even further. To measure the impact of such build breakage, this empirical study analyzes 3,214 builds produced in a large software company over a period of 6 months. We found a high ratio of build breakage (17.9%), and also quantified the cost of such build breakage ranging from 904.64 to 2034.92 man-hours. Interviews with 28 software engineers from the company helped to understand the circumstances under which builds are broken and the effects of build breakages on the collaboration and coordination of teams. We quantitatively investigated the main factors impacting build breakage and found that build failures correlate with the number of simultaneous contributors on branches, the type of work items performed on a branch, and the roles played by the stakeholders of the builds (for example developers vs. integrators).
http://mcis.polymtl.ca/publications/2014/icsm14_noureddine.pdf
Summary of fast development and cloud native architecture along with cost optimization techniques. Presented as opening keynote at the Utility and Cloud Computing 2014 as part of the Cloud Control Workshop.
When it comes to Continuous Integration and Delivery, the common idea is that the tools necessary to practice it are complex and require a lot of study and time to create the basic infrastructure.
With this workshop we want to show a "turnkey" solution to experiment the Continuous Delivery technique in just a few minutes! And show that the challenge is not to dominate the tools, but to change ourselves and the way we work and approach this topic.
6 Principles for Enabling Build/Measure/Learn: Lean Engineering in ActionBill Scott
Presented at Lean Day West - Portland, OR. Sept. 17, 2013
How do you take a gigantic organization like PayPal and begin to transform the experiences? Engineering is often the key blocker in being able to achieve a high rate of innovation. In this talk, Bill Scott will give specific examples on implemented Lean UX in a 13,000 person company, re-factored the technology stack and changed the way engineers work with design & product partners. In addition, Bill will provide additional examples that go back to his early days writing one of the first Macintosh games to his more recent work at Netflix and the power of treating the user interface layer as the experimentation layer.
This is a talk I gave at IPC 2014 in Munich.
It's about how to build durable web apis based on the experience gained at Namshi while we were developing our SOA architecture
Lean Engineering: How to make Engineering a full Lean UX partnerBill Scott
In 1999, PayPal's name was synonymous with innovation. In fact, the so called PayPal Mafia (original founders) went on to establish Tesla, SpaceX, YouTube, Skype and other startups. They also provided the early investments of many of the most innovative companies on the internet today. But over time that innovation slowed to a crawl.
In 2011 a number of things begin to come together for PayPal that started its journey back to innovation. This is the story of that reboot and how engineering has played a key role in partnering directly with product and design to move from a culture of products having a long shelf life, to one of rapid experimentation.
In this talk, Bill will outline the principles of Lean Engineering; principles for engineering that enable learning. Drawing from his experience leading User Interface Engineering at both Netflix & PayPal, Bill will walk you through the key principles your engineering team will need to adopt to be that enabler for product and design in your organization. This talk will not just inspire you, but it will also give you some hard earned advice on making this a reality in your organization.
Given at Agile Camp 2013, San Jose, CA. Sept. 21
How do you take a gigantic organization like PayPal that was entrenched in a culture of a “”long shelf life”” and transform it to a culture of rapid experimentation? Bill will give 3 principles applied to PayPal engineering to make it a full partner with Lean UX. This will be illustrated by showing how they re-factored the tech stack and changed the way engineers work in Lean streams with design & product partners and how it plays with agile.
As a backdrop Bill will discuss several historical factors in the field of software engineering that are antithetical to the Lean Startup mindset but still find their way into most large enterprises. By understanding this historical context and applying lean principles he will demonstrate how a lean transformation can take place in any enterprise.
Automation and Developer Infrastructure — Empowering Engineers to Move from I...indeedeng
Link to video: https://youtu.be/aHHfq4WK9Jw
At Indeed, we're growing quickly, from our engineer headcount to the number of features we deploy. Over the last three years, we’ve had a 6x increase in engineers, and a 15x increase in number of deploys. We’re currently deploying over 700 new features each week. In this talk, we'll describe the infrastructure built to support, scale and automate our software development and product releases, and how any organization can use these tools and techniques to improve release velocity in the face of rapid growth. Specifically, we will discuss Hobo — an easy, standardized way for developers to run our application stacks in Docker. We’ll also describe Control Tower, which manages software releases by unifying all of the information about application features into a single interface. These tools allow engineers to focus on product development, while moving their work from idea to production as efficiently as possible.
Over time, the software industry has come up with many ways to deliver code. Why is it so important to be in production as much as possible? What advantages and disadvantages do we have in rapid releases? Let’s talk about how to be faster, safer, and with better quality.
Slides that were presented during the webrtc Qt Cmake tutorial at IIT-RTC in October 2017 in Chicago. The slides are not yet complete, and will be updated later.
Free The Enterprise With Ruby & Master Your Own DomainKen Collins
On the heals of Luis Lavena's RailsConf talk "Infiltrating Ruby Onto The Enterprise Death Star Using Guerilla Tactics" comes a local and frank talk about the current state of Open Source Software (OSS) participation from Windows developers. Learn what OSS is, what motivates its contributors, and how OSS can make you a stronger developer. Be prepared to fall in love with writing software again!
We will start off with a 101 introduction to both the Ruby programming language and the Ruby on Rails web application framework. You will learn about ActiveRecord, a powerful ORM that maps rich objects to your databases, and the latest components to use it with SQL Server. As a Rails core contributor and author of the SQL Server stack, I will give you a modern insight into both that will allow you to leverage your legacy data with Ruby.
Lastly, I will review the bleeding edge tools being actively created for Windows developers to ease the transition to Ruby, Rails and OSS from a POSIX driven world. Many things have changed. It is time to learn and perform some occupational maintenance.
Lean engineering for lean/balanced teams: lessons learned (and still learning...Balanced Team
Bill Scott, PayPal
How do you take a gigantic organization and begin to transform the products? One key is to change the way teams work together to build experiences by following a Lean UX methodology. However, essential to this is to have engineering fully onboard as an integrated partner in the process. In this talk, Bill Scott will share 6 principles gleaned from the last two years to transforming engineering and the technology stack to support this working model.
Building A Distributed Build System at Google Scale (StrangeLoop 2016)Aysylu Greenberg
It's hard to imagine a modern developer workflow without a sufficiently advanced build system: Make, Gradle, Maven, Rake, and many others. In this talk, we'll discuss the evolution of build systems that leads to distributed build systems. Then, we'll dive into how we can build a scalable system that is fast and resilient, with examples from Google. We'll conclude with the discussion of general challenges of migrating systems from one architecture to another.
High Productivity Web Development WorkflowVũ Nguyễn
We are all familiar with these web technologies: Angular, NodeJS, Grunt, Karma, ... However, how to put them together to make a seamless, high productivity workflow for building prototypes quickly and delivering products frequently?
Vaccine management system project report documentation..pdfKamal Acharya
The Division of Vaccine and Immunization is facing increasing difficulty monitoring vaccines and other commodities distribution once they have been distributed from the national stores. With the introduction of new vaccines, more challenges have been anticipated with this additions posing serious threat to the already over strained vaccine supply chain system in Kenya.
Democratizing Fuzzing at Scale by Abhishek Aryaabh.arya
Presented at NUS: Fuzzing and Software Security Summer School 2024
This keynote talks about the democratization of fuzzing at scale, highlighting the collaboration between open source communities, academia, and industry to advance the field of fuzzing. It delves into the history of fuzzing, the development of scalable fuzzing platforms, and the empowerment of community-driven research. The talk will further discuss recent advancements leveraging AI/ML and offer insights into the future evolution of the fuzzing landscape.
Explore the innovative world of trenchless pipe repair with our comprehensive guide, "The Benefits and Techniques of Trenchless Pipe Repair." This document delves into the modern methods of repairing underground pipes without the need for extensive excavation, highlighting the numerous advantages and the latest techniques used in the industry.
Learn about the cost savings, reduced environmental impact, and minimal disruption associated with trenchless technology. Discover detailed explanations of popular techniques such as pipe bursting, cured-in-place pipe (CIPP) lining, and directional drilling. Understand how these methods can be applied to various types of infrastructure, from residential plumbing to large-scale municipal systems.
Ideal for homeowners, contractors, engineers, and anyone interested in modern plumbing solutions, this guide provides valuable insights into why trenchless pipe repair is becoming the preferred choice for pipe rehabilitation. Stay informed about the latest advancements and best practices in the field.
Cosmetic shop management system project report.pdfKamal Acharya
Buying new cosmetic products is difficult. It can even be scary for those who have sensitive skin and are prone to skin trouble. The information needed to alleviate this problem is on the back of each product, but it's thought to interpret those ingredient lists unless you have a background in chemistry.
Instead of buying and hoping for the best, we can use data science to help us predict which products may be good fits for us. It includes various function programs to do the above mentioned tasks.
Data file handling has been effectively used in the program.
The automated cosmetic shop management system should deal with the automation of general workflow and administration process of the shop. The main processes of the system focus on customer's request where the system is able to search the most appropriate products and deliver it to the customers. It should help the employees to quickly identify the list of cosmetic product that have reached the minimum quantity and also keep a track of expired date for each cosmetic product. It should help the employees to find the rack number in which the product is placed.It is also Faster and more efficient way.
Overview of the fundamental roles in Hydropower generation and the components involved in wider Electrical Engineering.
This paper presents the design and construction of hydroelectric dams from the hydrologist’s survey of the valley before construction, all aspects and involved disciplines, fluid dynamics, structural engineering, generation and mains frequency regulation to the very transmission of power through the network in the United Kingdom.
Author: Robbie Edward Sayers
Collaborators and co editors: Charlie Sims and Connor Healey.
(C) 2024 Robbie E. Sayers
COLLEGE BUS MANAGEMENT SYSTEM PROJECT REPORT.pdfKamal Acharya
The College Bus Management system is completely developed by Visual Basic .NET Version. The application is connect with most secured database language MS SQL Server. The application is develop by using best combination of front-end and back-end languages. The application is totally design like flat user interface. This flat user interface is more attractive user interface in 2017. The application is gives more important to the system functionality. The application is to manage the student’s details, driver’s details, bus details, bus route details, bus fees details and more. The application has only one unit for admin. The admin can manage the entire application. The admin can login into the application by using username and password of the admin. The application is develop for big and small colleges. It is more user friendly for non-computer person. Even they can easily learn how to manage the application within hours. The application is more secure by the admin. The system will give an effective output for the VB.Net and SQL Server given as input to the system. The compiled java program given as input to the system, after scanning the program will generate different reports. The application generates the report for users. The admin can view and download the report of the data. The application deliver the excel format reports. Because, excel formatted reports is very easy to understand the income and expense of the college bus. This application is mainly develop for windows operating system users. In 2017, 73% of people enterprises are using windows operating system. So the application will easily install for all the windows operating system users. The application-developed size is very low. The application consumes very low space in disk. Therefore, the user can allocate very minimum local disk space for this application.
CFD Simulation of By-pass Flow in a HRSG module by R&R Consult.pptxR&R Consult
CFD analysis is incredibly effective at solving mysteries and improving the performance of complex systems!
Here's a great example: At a large natural gas-fired power plant, where they use waste heat to generate steam and energy, they were puzzled that their boiler wasn't producing as much steam as expected.
R&R and Tetra Engineering Group Inc. were asked to solve the issue with reduced steam production.
An inspection had shown that a significant amount of hot flue gas was bypassing the boiler tubes, where the heat was supposed to be transferred.
R&R Consult conducted a CFD analysis, which revealed that 6.3% of the flue gas was bypassing the boiler tubes without transferring heat. The analysis also showed that the flue gas was instead being directed along the sides of the boiler and between the modules that were supposed to capture the heat. This was the cause of the reduced performance.
Based on our results, Tetra Engineering installed covering plates to reduce the bypass flow. This improved the boiler's performance and increased electricity production.
It is always satisfying when we can help solve complex challenges like this. Do your systems also need a check-up or optimization? Give us a call!
Work done in cooperation with James Malloy and David Moelling from Tetra Engineering.
More examples of our work https://www.r-r-consult.dk/en/cases-en/
Forklift Classes Overview by Intella PartsIntella Parts
Discover the different forklift classes and their specific applications. Learn how to choose the right forklift for your needs to ensure safety, efficiency, and compliance in your operations.
For more technical information, visit our website https://intellaparts.com
25. • How quickly can we ship a chemspill release?
• 4-6 weeks 11 hours
• How long to ship a “new feature” release?
• 12-18 months 6 weeks
• How many active code lines?
• 1 1/2 42
• How many checkins per day?
• ~15 per day 325 per day
Before & After
http://oduinn.com/images/2013/blog_2013_RelEngAsForceMultiplier.pdf 9
26. • How quickly can we ship a chemspill release?
• 4-6 weeks 11 hours
• How long to ship a “new feature” release?
• 12-18 months 6 weeks
• How many active code lines?
• 1 1/2 42
• How many checkins per day?
• ~15 per day 325 per day
Before & After
http://oduinn.com/images/2013/blog_2013_RelEngAsForceMultiplier.pdf 9
27. • How quickly can we ship a chemspill release?
• 4-6 weeks 11 hours
• How long to ship a “new feature” release?
• 12-18 months 6 weeks
• How many active code lines?
• 1 1/2 42
• How many checkins per day?
• ~15 per day 325 per day
Before & After
http://oduinn.com/images/2013/blog_2013_RelEngAsForceMultiplier.pdf 9
35. RELENG: International Workshop on
Release Engineering
13
230 participants3 editions
next RELENG:
in Fall 2016
http://releng.polymtl.ca
dozens of industry
& academic talks
56. user acceptance/system tests
performance tests
(selection of) unit tests
all unit tests
integration tests
time to run (hours)
full compilation
incremental compilation
`
Why do CI builds take so long?
16
57. user acceptance/system tests
performance tests
(selection of) unit tests
all unit tests
integration tests
time to run (hours)
full compilation
incremental compilation
`
local developer build
Why do CI builds take so long?
16
58. user acceptance/system tests
performance tests
(selection of) unit tests
all unit tests
integration tests
time to run (hours)
full compilation
incremental compilation
`
local developer build
Why do CI builds take so long?
16
59. user acceptance/system tests
performance tests
(selection of) unit tests
all unit tests
integration tests
time to run (hours)
full compilation
incremental compilation
` CI build of merged change
local developer build
Why do CI builds take so long?
16
60. user acceptance/system tests
performance tests
(selection of) unit tests
all unit tests
integration tests
time to run (hours)
full compilation
incremental compilation
CI build of merged change
local developer build
Why do CI builds take so long?
16
61. user acceptance/system tests
performance tests
(selection of) unit tests
all unit tests
integration tests
time to run (hours)
full compilation
incremental compilation
closer to release
CI build of merged change
local developer build
Why do CI builds take so long?
16
62. user acceptance/system tests
performance tests
(selection of) unit tests
all unit tests
integration tests
time to run (hours)
full compilation
incremental compilation
closer to release
CI build of merged change
local developer build
Why do CI builds take so long?
16
67. Even worse …
17
build machinery run
on each commit!
not just build and
test, also code
quality builds,
nightly builds, etc.
different feature
configurations
68. Even worse …
17
build machinery run
on each commit!
not just build and
test, also code
quality builds,
nightly builds, etc.
not all builds
succeed
different feature
configurations
92. Look at Project X!
It had a crazy number of
bugs in the typical six-month
post-release window!
25
93. Look at Project X!
It had a crazy number of
bugs in the typical six-month
post-release window!
Well, Project X releases
every 6 weeks, so
you’re counting several
releases…
25
94. Release cycles vary among
popular studied systems
Daysbetweenreleases
An Empirical Study of Delays in the Integration of
Addressed Issues
D. A. da Costa et al.
[ICSME 2014]
95. Release cycles can even
vary within systems!
1.0
2.0
2.5
3.0
3.5
4.0
5.0
6.0
7.0
8.0
9.0
10.0
0 200 400 600 800
Firefoxrelease
Days since prior release 27
101. Weird… The size of this
project fluctuates between
50k and 45k lines!
30
102. Weird… The size of this
project fluctuates between
50k and 45k lines!
Hmm, did you select the
relevant branch? Several
are developed in parallel!
30
103. An example of defect prediction
Feature development
Defect repairing
Merge
Commit types
31
104. An example of defect prediction
Feature development
Defect repairing
Merge
Commit types
31
105. An example of defect prediction
v1.0
Feature development
Defect repairing
Merge
Commit types
31
106. An example of defect prediction
v1.0
Feature development
Defect repairing
Merge
Commit types
Pre-
release
31
107. An example of defect prediction
v1.0
Feature development
Defect repairing
Merge
Commit types
Pre-
release
Post-
release
31
108. An example of defect prediction
v1.0
Feature development
Defect repairing
Merge
Commit types
Pre-
release
Post-
release
31
109. Handling the intricacies of a multi-
branch release pipeline
Dev
Stable
Feature development
Defect repairing
Merge
Commit types
32
110. Handling the intricacies of a multi-
branch release pipeline
Dev
Stable
Feature development
Defect repairing
Merge
Commit types
32
111. Handling the intricacies of a multi-
branch release pipeline
Dev
Stable
Feature development
Defect repairing
Merge
Commit types
32
112. Handling the intricacies of a multi-
branch release pipeline
Dev
Stable
Feature development
Defect repairing
Merge
Commit types
32
113. Handling the intricacies of a multi-
branch release pipeline
v1.0
Dev
Stable
Feature development
Defect repairing
Merge
Commit types
32
114. Handling the intricacies of a multi-
branch release pipeline
v1.0
Dev
Stable
Feature development
Defect repairing
Merge
Commit types
32
115. Handling the intricacies of a multi-
branch release pipeline
v1.0
Dev
Stable
Feature development
Defect repairing
Merge
Commit types
32
116. Handling the intricacies of a multi-
branch release pipeline
v1.0
Dev
Stable
Feature development
Defect repairing
Merge
Commit types
32
117. Handling the intricacies of a multi-
branch release pipeline
v1.0
Dev
Stable
Feature development
Defect repairing
Merge
Commit types
32
118. Handling the intricacies of a multi-
branch release pipeline
v1.0
Dev
Stable
Feature development
Defect repairing
Merge
Commit types
32
120. 1. All releases are equal
2. All branches are equal
Harmful assumptions about release pipelines
that can impact predictive modelling
34
121. 1. All releases are equal
2. All branches are equal
3. All files are equal
Harmful assumptions about release pipelines
that can impact predictive modelling
34
123. This popular web browser
has an enormous codebase!
>30M lines!
35
124. This popular web browser
has an enormous codebase!
>30M lines!
Yes, but the codebase
contains several systems!
The build configuration
decides which one is
produced!
35
125. 36
Many files are conditionally
included in deliverables
Tracing Software Build
Processes to Uncover
License Compliance
Inconsistencies
S. van der Berg et al.
[ASE 2014]
Aterm
Opkg
Bash
CUPS
Xalan
OpenSSL
FFmpeg
% Excluded Files
0% 20% 40% 60% 80%
126. 36
Many files are conditionally
included in deliverables
Fixes in these files may have a
smaller impact (if any) on customers
Tracing Software Build
Processes to Uncover
License Compliance
Inconsistencies
S. van der Berg et al.
[ASE 2014]
Aterm
Opkg
Bash
CUPS
Xalan
OpenSSL
FFmpeg
% Excluded Files
0% 20% 40% 60% 80%
128. 1. All releases are equal,
2. All branches are equal,
Harmful assumptions about release pipelines
that can impact predictive modelling
3. All files are equal
38
129. but some are more equal than others
1. All releases are equal,
2. All branches are equal,
Harmful assumptions about release pipelines
that can impact predictive modelling
3. All files are equal
38
130. My nightmare
Amassing and indexing a large
sample of version control systems
Audris Mockus
[MSR 2009]
Boa: a language and infrastructure for analyzing
ultra-large-scale software repositories
R. Dyer et al.
[ICSE 2013]
The GHTorrent Dataset and Tool
Suite
G. Gousios
[MSR 2013]
131. My nightmare
Amassing and indexing a large
sample of version control systems
Audris Mockus
[MSR 2009]
Boa: a language and infrastructure for analyzing
ultra-large-scale software repositories
R. Dyer et al.
[ICSE 2013]
The GHTorrent Dataset and Tool
Suite
G. Gousios
[MSR 2013]
We collect all of the data in the world,
but it’s meaningless without context!
135. Release
Engineering
integrating code changes building/testing (CI)
releasing to the user deploying a new release
http://www.informit.com/articles/article.aspx?p=1833567
reduce the risk
of releasing software
if it hurts, do it
more frequently, and
bring the pain
forward
Jez Humble
136. Release
Engineering
integrating code changes building/testing (CI)
releasing to the user deploying a new release
http://www.informit.com/articles/article.aspx?p=1833567
reduce the risk
of releasing software
if it hurts, do it
more frequently, and
bring the pain
forward
Jez Humble
137. Release
Engineering
integrating code changes building/testing (CI)
releasing to the user deploying a new release
http://www.informit.com/articles/article.aspx?p=1833567
reduce the risk
of releasing software
if it hurts, do it
more frequently, and
bring the pain
forward
Jez Humble
master branch
How to Predict Integration Effort?
14
3rd party
dependency
feature branch 1
git
repo
release branch
MERGE CONFLICT?
myapp
v.1
feature branch 2 sync
138. Release
Engineering
integrating code changes building/testing (CI)
releasing to the user deploying a new release
http://www.informit.com/articles/article.aspx?p=1833567
reduce the risk
of releasing software
if it hurts, do it
more frequently, and
bring the pain
forward
Jez Humble
master branch
How to Predict Integration Effort?
14
3rd party
dependency
feature branch 1
git
repo
release branch
MERGE CONFLICT?
myapp
v.1
feature branch 2
sync
139. Release
Engineering
integrating code changes building/testing (CI)
releasing to the user deploying a new release
http://www.informit.com/articles/article.aspx?p=1833567
reduce the risk
of releasing software
if it hurts, do it
more frequently, and
bring the pain
forward
Jez Humble
master branch
How to Predict Integration Effort?
14
3rd party
dependency
feature branch 1
git
repo
release branch
MERGE CONFLICT?
myapp
v.1
feature branch 2
sync
but some are more equal than others
1. All releases are equal,
2. All branches are equal,
Harmful assumptions about release pipelines
that can impact predictive modelling
3. All files are equal
140. Release
Engineering
integrating code changes building/testing (CI)
releasing to the user deploying a new release
http://www.informit.com/articles/article.aspx?p=1833567
reduce the risk
of releasing software
if it hurts, do it
more frequently, and
bring the pain
forward
Jez Humble
master branch
How to Predict Integration Effort?
14
3rd party
dependency
feature branch 1
git
repo
release branch
MERGE CONFLICT?
myapp
v.1
feature branch 2
sync
but some are more equal than others
1. All releases are equal,
2. All branches are equal,
Harmful assumptions about release pipelines
that can impact predictive modelling
3. All files are equal