The second week of October, I had the pleasure of presenting lectures on release engineering to university students in Montreal as part of the PLOW lectures at École Polytechnique de Montréal. Most of the students were MSc or PhD students in computer science, with a handful of postdocs and professors in the class as well. The students came from Montreal area universities and many were international students. The PLOW lectures consisted of several invited speakers from various universities and industry spread over three days.
|View looking down from the university|
|Université de Montréal administration building|
|École Polytechnique building. Each floor is painted a different colour to represent a differ layer of the earth. So the ground floor is red, the next orange and finally green.|
|The first day, Jack Jiang from York University gave a talk about software performance engineering.|
The second day, I gave a lecture on release engineering in the morning. The rest of the day we did a lot of labs to configure a Jenkins server to build and run tests on an open source project. Earlier that morning, I had setup m3.large instances for the students on Amazon that they could ssh into and conduct their labs. Along the way, I talked about some release engineering concepts. It was really interesting and I learned a lot from their feedback. Many of the students had not been exposed to release engineering concepts so it was fun to share the information.
Several students came up to me during the breaks and said “So, I’m doing my PhD in release engineering, and I have several questions for you” which was fun. Also, some of the students were making extensive use of code bases for Mozilla or other open source projects so that was interesting to learn more about. For instance one research project looking at the evolution of multi-threading in a Mozilla code bases, and another student was conducting bugzilla comment sentiment analysis. Are angry bug comments correlated with fewer bug fixes? Looking forward to the results of this research!
I ended the day by providing two challenge exercises to the students that they could submit answers to. One exercise was to setup a build pipeline in Jenkins for another open source project. The other challenge was to use a the Jenkins REST API to query the Apache projects Jenkins server and present some statistics on their build history. The results were pretty impressive!
My slides are on GitHub and the readme file describes how I setup the Amazon instances so Jenkins and some other required packages were installed before hand. Please use them and distribute them if you are interested in teaching release engineering in your classroom.
Lessons I learned from this experience:
- Computer science classes focus on writing software, but not necessarily building it is a team environment. So complex branching strategies are not necessarily a familiar concept to some students. Of course, this depends on the previous work experience of the students and the curriculum at the school they attend. One of students said to me “This is cool. We write code, but we don’t build software”.
- Concepts such as building a pipeline for compilation, correctness/performance/
regression testing, packing and deployment can also be unfamiliar. As I said in the class, the work of the release engineer starts when the rest of the development team things they are done 🙂
- When you’re giving a lecture and people would point out typos, or ask for clarification I’d always update the repository and ask the students to pull a new version. I really liked this because my slides were in reveal.js and I didn’t have to export a new PDF and redistribute. Instant bug fixes!
- Add bonus labs to the material so students who are quick to complete the exercises have more to do while the other students complete the original material. Your classroom will have people with wildly different experience levels.
The third day there was a lecture by Michel Dagenais of Polytechnique Montréal on tracing heterogeneous cloud instances using https://lttng.org/ (tracing framework for Linux). The Eclipse trace compass project also made an appearance in the talk. I always like to see Eclipse projects highlighted. One of his interesting points was that none of the companies that collaborate on this project wanted to sign a bunch of IP agreements so they could collaborate on this project behind closed doors. They all wanted collaborate via an open source community and source code repository. Another thing he emphasized was that students should make their work available on the web, via GitHub or other repositories so they have a portfolio of work available. It was fantastic to seem him promote the idea of students being involved in open source as a way to help their job prospects when they graduate!
Thank you Foutse and Bram for the opportunity to lecture at your university! It was a great experience! Also, thanks Mozilla for the opportunity to do this sort of outreach to our larger community on company time!
Also, I have a renewed respect for teachers and professors. Writing these slides took so much time. Many long nights for me especially in the days leading up to the class. Kudos to you all who do teach everyday.
The slides are on GitHub and the readme file describes how I setup the Amazon instances for the labs
I just started my first full time job. I never would have guessed in school that I would be working in release engineering. I got obsessed with source control while doing a web bootcamp. I'm hoping your GitHub slide will give more details of the two labs because they sound fun. I really enjoyed this blog post!