Developer interview: Filipa Lacerda - Gitlab

[donbonifacio]

Pipeline:

• [ ] How to handle feature conflicts
• [ ] Talk about the experience mentoring, tips for other mentors
• [ ] What does it mean to be a senior frontender? How to spot them and how to build them?

[donbonifacio]

Hello Filipa. Can you introduce yourself and talk a bit about your background and what you do?

[filipalacerda]

Hi Pedro! Thank you for having me.

My name is Filipa Lacerda, I'm based in Aveiro, Portugal and I work remotely for GitLab as a senior frontend engineer.

I have a masters in Multimedia, and I've been working as a frontend engineer for a bit over 7 years.

At GitLab I work mostly with the CI/CD team and help with security issues. Recently I had the opportunity of being part of the Release team for four months, which was an amazing experience. The Release team is responsible for releasing and deploying GitLab every month which is a completely different work from frontend development.

I'm passionate about the web and I love teaching, so recently I've started doing mentorships. I'm working with The New Digital School as my first mentor experience, and I have a few workshops scheduled where I'll be a mentor for Vue Vixens, first one will be at Vue.js London.

I love to share GitLab's experience with Vue and Vuex, which lead me to be a speaker in a few conferences. I'm very excited for the next ones, I'll be at Vue.js Toronto and at Vue.js Amesterdam.

On my free time you can find me doing sports, reading and enjoying the sun.

[donbonifacio]

I'd say that it's not that common for companies to have release teams. Can you talk a bit about how the release team works? Does it deal with quality processes? It's also responsible for support and maintenance?

[filipalacerda]

At GitLab we release a new version on the 22nd of every month and our release managers are responsible for driving the monthly release of GitLab as well as any patch release for that version.

The Release Manager role is a rotating role and due to the complexity of the task, it requires some training. For each release there are two primary release managers and two trainee release managers, each team has one person in the Americas and the other on Europe or Asia, to ensure good coverage.

GitLab has two repositories, one for the Comunity Edition the other for the Enterprise Edition, both are open source. Our Enterprise Edition project has everything from the Community Edition one plus the same features, every tag is done for both.

The main responsibility of a release manager is to protect the work of every single person involved in creating the product and running the product at GitLab.com. Sometimes this responsibility requires making difficult decisions.

We have a code freeze date, which in on the 7th, that defines the window of new code that will be shipped on the next release. On the 1st of each month, the release managers will start the first release candidate (RC). After the 7th only regression's fix will go into the preparation branches.

After each RC is tagged, the release manager will deploy it to staging and work with the Quality team to guarantee both manual and automated tests are successful. Once we get a stable RC that we trust won't break any feature, we deploy it to production (gitlab.com).

From the 1st until the 22nd, the release manager has always something to do, there will be regressions that need to be picked, Community Edition and Enterprise Edition repositories must be in sync - they share the same base code, it's common that an RC can't be deployed into production and a new one must be tagged. We usually tag around 10 to 14 RCs before tagging the new version.

Sometimes the Release Manager will have to make difficult decisions. For a plenitude of reasons, it can happen that a feature that was scheduled for a specific release missed the code freeze date. It is the Release Manager's responsibility to guarantee a new change won't compromise the rest of the release, often leading to saying no into adding a new feature. The same can happen with code that was merged within the code freeze date, sometimes we need to decide on shipping a feature that is not working as expected to allow for other features/fixes to be available.

After the release date - 22nd - the release managers are responsible for every patch release and also for the security release. The latter only includes fixes for security vulnerabilities.

It's a handful job, there's always something that needs to be done, everything needs to be coordinated with the development and quality teams, everything is asynchronous, and you'll have people in more than 16 different time zones. But I have to confess, for me, it was one of the most fulfilling and challenging tasks I've ever done. The fact that I worked together with a great Release Manager - Mayra - helped a lot.

[donbonifacio]

That's very interesting and does seem very challenging. Can you give an overview of the process you take to go from a feature idea to be release ready?

[filipalacerda]

At GitLab everything starts with an issue, so the first step of any feature is to open an issue and describe your idea - anyone can open an issue asking for a new feature, not all features start with the product team.

From here it depends on how much value that feature will bring to the product and its users, if it's a feature most users would find value in it, most likely it will be scheduled sooner than a feature that won't bring as much value to the product.

Before it's scheduled there is usually some discussion on the issue. On that discussion, you'll most likely see a Product Manager, some developers and some community contributors involved. The issue is the Single Source of Truth, everything must be documented there.

Once it's scheduled, and this can be different between different teams, we may do a quick sync call to make sure we are all aligned with the issue's description. The result of this call will be documented on the issue. There's usually 1 element of each team involved in a big feature - UX, Frontend, Backend. From this step forward each team starts working on it - Frontend most likely will have to wait for the final mockups to be ready, but we try to avoid the waterfall process and work all at the same time.

Usually, we will all work in the same branch unless we can reduce the scope of the feature and merge it into master in smaller chunks - big Merge Requests are very hard to review. If the feature requires too many changes is also common for frontend and backend to work on separate branches.

Once the developers agree that the feature is complete we go through the review process. If a Merge Request has backend and frontend changes it must be reviewed by at least 4 people - a reviewer and a maintainer for each subject. The UX team member assigned to the issue must also review and approve the Merge Request before it gets merged. In case there are database changes, a Database maintainer will also have to approve the Merge Request.

Once the review step is finished, a maintainer will merge it into master.

During the release process, the merge request will be picked into a stable branch. Once a Release Candidate gets deployed into staging, the author of the Merge Request must test it manually and confirm it's working before moving on with the release.

[donbonifacio]

How do you make sure that changes by so many people are consistent, in terms of design, usability, etc? I mean, can you have for example a CTA on one part of site one colour, and on another part with a different style? How can we prevent this? And in a related subject, do you have problems with some style changes breaking things elsewhere?

[filipalacerda]

Both UX and Frontend work closely together, both teams have a weekly call and our managers make sure we are all heading in the same direction.

It happens, however, that every now and then we miss something. Since we believe in iteration, it's not a huge blocker if we are able to fix it fast enough.

Regarding styling changes, yes we do have some problems.

Recently we've updated from Bootstrap 3 to 4 and we broke a few things. Due to having different repositories for the community and the enterprise editions, sometimes we change CSS in the Community Edition that will break something on the Enterprise Edition and vice-versa.

We've started working on a new project, gitlab-ui that will allow us to have reusable components and snapshot tests. The main goal of this project is to reduce UI differences and regressions.

I believe that once we manage snapshot tests with the gitlab-ui , we will most likely try to implement them on GitLab itself.

[donbonifacio]

I'm a line manager with a background more in the backend. But I do have frontenders on my team that I am responsible to grow. How would you define a very valuable frontender? What kind of technical and soft skills would you expect?

[filipalacerda]

Soft skills are the hardest. Technical skills are easy to learn when you have the right mindset.

I guess the soft skills I'll point are not frontend specific. Looking at the engineers that I look up to, I'd say that no matter how senior you are, keep being humble, you won't ever know everything, and that's ok. Respect everyone, most often than you expect, you'll learn something new or you'll make a difference in someone else's career by respecting each other. Take the time to teach, and keep reminding yourself that when you started it was hard for you too. Last but not least, be kind, and do not take code discussion/code review into a personal matter. There are a time and place for everything and it's very hard to divide your work life from your personal life. If you master this, you'll be more successful and happy.

Regarding technical skills, I'd say that knowing the core basics of the language are key. Often I've worked with people that are using a framework without understanding why or what the impact of some data mutation may have. The advise I'd give to anyone starting would be, before jumping into a framework, take the time to learn JavaScript and CSS and try to understand which problems each framework solves.

So, to answer your question, for me, a very valuable frontend is someone who has a deep knowledge of JavaScript, CSS, and the browser, and who is capable of quickly read through any framework documentation and master it. It's someone that is kind enough to take the time and teach others and someone is always respectful, but also someone who is not ashamed of asking questions when they are not sure about the best approach.

[donbonifacio]

How can we make an impact in the growth of a junior frontender? How can we train them and make them level up faster and consistently?

[filipalacerda]

I don't think it's different from a backend junior developer, apart from the amount of tools frontend has, which can be daunting.

I know this can be hard in a fast-paced industry, but I'd say the time you invest, for example, in code reviews, explaining why some code is not the best choice and what would improve it is very important.

[donbonifacio]

Can you elaborate on your mentoring experience? How does that work and could we adapt that format for companies, for example?