@conference { ISI:000382672700052,
	title = {Botched Releases: Do we Need to Roll Back? Empirical Study on a Commercial Web App},
	booktitle = {2016 IEEE 23RD INTERNATIONAL CONFERENCE ON SOFTWARE ANALYSIS, EVOLUTION, AND REENGINEERING (SANER), VOL 1},
	year = {2016},
	note = {23rd IEEE International Conference on Software Analysis, Evolution, and Reengineering (SANER), Osaka, JAPAN, MAR 14-18, 2016},
	pages = {574-583},
	publisher = {IEEE; IEEE Comp Soc; IPA; Reengineering Forum; Informat Proc Soc Japan, Special Interest Grp Software Engn; Japan Soc Software Sci \& Technol, Special Interest Grp Fdn Software Engn; Osaka Univ, Grad Sch Informat Sci \& Technol; Mitsubishi Elect; Microsoft;},
	organization = {IEEE; IEEE Comp Soc; IPA; Reengineering Forum; Informat Proc Soc Japan, Special Interest Grp Software Engn; Japan Soc Software Sci \& Technol, Special Interest Grp Fdn Software Engn; Osaka Univ, Grad Sch Informat Sci \& Technol; Mitsubishi Elect; Microsoft;},
	abstract = {Few minutes after a web-based software release, the release team might encounter log traces showing the new system crashing, hanging, or having poor performance. This is the start of the most nerve-wrecking moments of a product{\textquoteright}s release cycle, i.e., should one run the risk of not doing anything and users losing precious data, or of prematurely engaging the tedious (and costly) roll-back procedure towards the previous release? Thus far, only little attention has been paid by researchers to these so-called {\textquoteleft}{\textquoteleft}botched releases{{\textquoteright}{\textquoteright}}, partly because of lack of release log data. This paper studies 345 releases of a large e-commerce web app over a period of 1.5 years, in which we identified 17 recurrent root causes of botched releases, classified into four major categories. We then build explanatory models to understand which root causes are the most important, and to explore the factors leading to botched releases.},
	isbn = {978-1-5090-1855-0},
	doi = {10.1109/SANER.2016.114},
	author = {Kerzazi, Noureddine and Adams, Bram}
}
@conference { ISI:000382224200013,
	title = {Who Needs Release and DevOps Engineers, and Why?},
	booktitle = {INTERNATIONAL WORKSHOP ON CONTINUOUS SOFTWARE EVOLUTION AND DELIVERY, CSED 2016},
	year = {2016},
	note = {1st International Workshop on Continuous Software Evolution and Delivery (CSED), Austin, TX, MAY 14-15, 2016},
	pages = {77-83},
	publisher = {Assoc Comp Machinery; IEEE Comp Soc; IEEE Tech Council Software Engn; ACM Special Interest Grp Software Engn},
	organization = {Assoc Comp Machinery; IEEE Comp Soc; IEEE Tech Council Software Engn; ACM Special Interest Grp Software Engn},
	abstract = {The recent surge in interest in continuous delivery has opened up the job market for release and DevOps engineers. However, despite an increasing number of conferences and publications on continuous delivery, smaller companies and start-ups still have a hard time determining the core tasks their future release and DevOps engineers should be responsible for (and what the differences between those two roles are), while universities are not sure what essential techniques and skills they should teach to their students. This paper performs an empirical analysis of online job postings to determine and compare the main tasks of release and DevOps engineers, globally and across countries. Our qualitative analysis shows that automation is the most important activity across the three roles, as articulated in job posting description data, and that the release engineer role combines the top activities of the DevOps and more traditional build engineer roles. Finally, different countries have a moderate degree of similarity between their ads, although each country has its specific focus.},
	isbn = {978-1-4503-4157-8},
	doi = {10.1145/2896941.2896957},
	author = {Kerzazi, Noureddine and Adams, Bram}
}
