Petes Linkedin Blog

GitLab provides an easy-to-install package for most Linux distributions and even for devices like the Raspberry Pi . However, if you want to install GitLab in a home lab or similar private network, you would then be faced with a new issue: how do you access the instance from outside that private network? Traditionally, you would set up your router to forward traffic from your public IP address to the server inside your network. However, this comes with several drawbacks: Opening a port on your home or private network comes with a sustainable amount of risk. It can be hard or impossible for folks to do depending on their internet service provider and what routing equipment they use. It can be especially tough if your ISP doesn't provide you with a statically assigned IP address which means your address can change from time to time, and you'll need to either update DNS manually or through some third-party dynamic DNS service. For me, all of these challenges have meant tha...

No one ever said hiring was easy. As a matter of fact, talent hiring and retention are some of the hardest aspects to get right for any software company. According to a recent article at Developer Pitstop the average engineer will only stay at a job for an average of two years before moving on, and this tenure is shrinking as time goes on. When we look at the average timeline for engineers in a new role we usually see something like: Learning and adaptation (3 / 6 months): Coming to grips with the new company, team, and their processes. Creating value for the organization (6 / 12 months): Adding value to the business by becoming a functioning member of the team. Becoming a role expert (6 / 18 months): Owning the role completely and helping to shape the direction of the team. At GitLab we pride ourselves on an outstanding onboarding process to reduce the amount of time an engineer will spend in the learning and adaptation bracket and accelerate their evolution into the...

One of the core jobs of product managers is to speak with users to better understand their needs, pain points and the context in which they operate and use our products. But not all user calls are the same. There are 3 prominent types of user calls: Discovery or problem validation calls Roadmap discussions Solution validation calls Here's an in-depth look at how we approach the three types of user calls at GitLab. Discovery calls Discovery or problem validation calls are product managers' most crucial conversations with users. Discovery calls are typically set up to learn about our users in a targeted way. These calls help build a better understanding of users' pain points. For discovery, we need a recipe for repeatable, comparable user calls. For this reason, we should create an interview script and follow that script on all the user calls. This does not mean these calls are robotic and devoid of improvisation, not at all! The script should provide the backbone o...

Today we are releasing version 15.1.3 for GitLab Community Edition and Enterprise Edition. This version resolves a number of regressions and bugs in this month's 15.1 release and prior versions. GitLab Community Edition and Enterprise Edition Add praefect list virtual storages subcommand documentation Fix flaky feature specs for "user awards emoji" Fix flaky repository settings spec Fix group access dropdown failure if no subgroups are available Fix worker processes not starting up due to 0 processes Ensure Ruby platform is set globally for arm64 based operating systems Adjust worker processes to use real CPUs instead of cores Set force_ruby_platform to true locally for Gitaly and GitLab Rails Important notes on upgrading This version does not include any new migrations, and for multi-node deployments, should not require any downtime . Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “...

Today we are releasing version 15.1.3 for GitLab Community Edition and Enterprise Edition. This version resolves a number of regressions and bugs in this month's 15.1 release and prior versions. GitLab Community Edition and Enterprise Edition Add praefect list virtual storages subcommand documentation Fix flaky feature specs for "user awards emoji" Fix flaky repository settings spec Fix group access dropdown failure if no subgroups are available Fix worker processes not starting up due to 0 processes Ensure Ruby platform is set globally for arm64 based operating systems Adjust worker processes to use real CPUs instead of cores Set force_ruby_platform to true locally for Gitaly and GitLab Rails Important notes on upgrading This version does not include any new migrations, and for multi-node deployments, should not require any downtime . Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “...

To monitor the health of GitLab.com we use multiple SLIs for each service. We then page the on-call when one of these SLIs is not meeting our internal SLOs and burning through the error budget with the hopes of fixing the problem before too many of our users even notice. All of our services SLIs and SLOs are defined using jsonnet in what we call the metrics-catalog where we specify a service and its SLIs/SLOs. For example, the web-pages service has an apdex SLO of 99.5% and multiple SLIs such as loadbalancer , go server , and time to write HTTP headers . Having these in code we can automatically generate Prometheus recording rules and alerting rules following multiple burn rate alerts . Every time we start burning through our 30-day error budget for an SLI too fast we page the SRE on-call to investigate and solve the problem. This setup has been working well for us for over two years now, but one big pain point remained when there was a service-wide degradation. The SRE on-ca...

Open core is obviously a horrible approach to creating a product with an ecosystem of extensions and integrations: There are no proper protocols and interfaces. Instead, anyone can just add their integration to the code base and even adjust said code base to their needs if it doesn’t fit. So why have we been using the “Worse” approach at GitLab for many years now, with great success? Because  Worse is Better  (a term conceived by  Richard P. Gabriel ). Of course, it turns out that “Worse” is actually even better than Worse is Better suggested. Gabriel’s  original argument  was that (slightly) intrinsically worse but simpler and easier to implement software has better survival characteristics than better-designed, more complex software, and thus will consistently win in the marketplace. At GitLab, we have found that this is basically true, which is why we, for example, favor “boring technology,” even if it might not be the best possible solution for a given sc...