Petes Linkedin Blog

   This blog post is Unfiltered    "Transparency is only a value if you do it when it is hard" 👁 That's one of the lines that has stuck with me from my GitLab Inc. onboarding nearly 2 years ago. You know where practicing transparency is typically "hard"? Security. Thankfully, I can honestly say that I work on a Security team that not only pushes the transparency boundaries in the industry, but also within GitLab itself. Take our RedTeam , they’ve put out a whole public project called Tech Notes which contains deep dives on some of the challenges and vulnerabilities they’ve encountered in their work. They also just held their first-ever, live and public AMA/Ask Me Anything on January 26, 2021 and responded to over a dozen questions about the work that they do and how they go about doing it here at GitLab. If you joined us, thank you! If you missed it, check out the replay below. We’d love to hear from you on whether you’d like to see an event like this...

The transition from working in an office to working for an all-remote company isn’t always easy. Many engineers are used to whiteboarding a troublesome piece of code with their colleagues and being able to tap their manager on the shoulder when they get really stuck. In-office engineering managers are accustomed to reading body language and following verbal clues when interacting with the team members they supervise. For developers used to working in an office, it takes some time to adjust to working autonomously from home, instead of in a pod of desks with a team. GitLab team members share how they managed the shift from in-person, colocated work to working and managing teams remotely at GitLab to help others make the transition to remote work more easily. "My day-to-day role is very similar," says Max Woolf , senior backend engineer on the Manage:Compliance team at GitLab. "I work closely with product owners or product managers deciding, refining work, and then writi...

If you've used a Web proxy server before, you're probably familiar with the environment variables http_proxy or HTTP_PROXY . You may be less familiar with no_proxy , which provides a way to exclude traffic destined to certain hosts from using the proxy. While HTTP is a well-defined standard, no standard exists for how clients should handle these variables. As a result, Web clients support these variables in subtly different ways. For one GitLab customer, these differences led to a weekend of troubleshooting that uncovered why certain services stopped communicating. Background Today, most Web clients support connection to proxy servers via environment variables: http_proxy / HTTP_PROXY https_proxy / HTTPS_PROXY no_proxy / NO_PROXY These variables tell the client what URL should be used to access the proxy servers and which exceptions should be made. For example, if you had a proxy server listening on http://alice.example.com:8080 , you might use it via: export http...

What you need to know: GitLab is phasing out the Bronze/Starter tier Current Bronze/Starter customers have over a year to transition Transition discount offers are available to current customers GitLab Free continues to gain features, with over 450 in the last year GitLab will continue to have SaaS and Self-Managed options for each tier GitLab is phasing out the Bronze and Starter tiers and moving to a three-tier subscription model. Existing customers on Bronze and Starter tiers can choose to remain on the same tier until the end of their subscription period, and may renew at the current price for one additional year or upgrade to Premium at a significant discount. More details on the transition offers are below . Why phase out the Bronze and Starter tiers? Over the last few years, GitLab has evolved into a complete DevOps platform. Many Bronze/Starter customers adopted GitLab just for source code management (SCM) or continuous integration (CI), but GitLab is now a robus...

Today we are releasing version 13.8.1 for GitLab Community Edition and Enterprise Edition. This version resolves a number of regressions and bugs in this month's 13.8 release and prior versions. GitLab Community Edition and Enterprise Edition Available in GitLab Core, Starter, Premium, and Ultimate: Fix LFS not working with S3 specific-storage settings Skip the auth settings for pages when access control is not enabled Fix missing setting LDAP servers Add notification email event for SAML/SCIM Create What's New for 13.8 Clean up artifact expiry migration problem Resolve "Update Approval Rule documentation" Docs: Reviewer approval rules Available in GitLab Premium and Ultimate: Fix browser performance widget issue body import Available in GitLab Ultimate: Geo: clarify how to migrate single PostgreSQL to Patroni on secondary node Failsafe access to current user's email Important notes on upgrading This version does include new migrations, an...

Today we are releasing version 13.7.5 for GitLab Community Edition and Enterprise Edition. This version resolves a number of regressions and bugs in this month's 13.7 release and prior versions. GitLab Community Edition and Enterprise Edition Available in GitLab Core, Starter, Premium, and Ultimate: Disable ref tx hooks for FetchRemote calls Fix brand_new_project_guidelines not being displayed Resolve "The gitlab-ctl patroni failover command does not work" Fix https pages settings Convert external_http pages setting to bool for rails Fix LFS not working with S3 specific-storage settings Only use top level groups in devops adoption 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 “small” the upgrade is. This behavior can be changed by adding a ...

   This blog post is Unfiltered    Organizations adopting DevOps best practices to software delivery spend time and effort designing, building, testing, integrating, and maintaining CI/CD pipelines for their different projects. Just as they must spend some of their time maintaining their business applications instead of innovating, they must do the same for their pipelines. Freeing your developers so that they can spend more of their time creating new business applications and differentiating value to the business is of utmost importance to remain competitive in a world where organizations must be digital leaders to succeed in the marketplace. GitLab provides Auto DevOps, which are prescribed out-of-the-box CI/CD templates that auto-discover the source code you have. Based on best practices, they automatically detect, build, test, deploy, and monitor your applications. Auto DevOps save your developers from implementing their own pipelines so that they can spend mo...

This post will give you an idea of how VS Code can aid your code review process. You'll get an overview of the features that GitLab VS Code Extension currently supports, as well as what we plan to introduce in the future. Reviewing merge requests is a core part of GitLab: both the product (since version 2.0.0 , released in 2011) and the company. We recognize that certain review tasks are hard to do just by looking at the diff, and we strive to make them easier. One such task might be looking in the codebase for duplicated code or examples of a particular coding style. We decided to aid code reviewers in two ways: First way: The GitLab Web IDE First, we introduced the Web IDE , which helps our users work with the codebase in the browser . You can quickly open multiple files, make changes, and commit them. The Web IDE is handy when you need to make a small change, or you don't have the project cloned locally. The second way is more recent. We always wanted to bring the code ...

Today, we are excited to introduce a dedicated Pipeline Editor, a deployment frequency dashboard, and several quality of life improvements that will make using GitLab every day even more enjoyable. These are just a few highlights from the 50+ improvements in this release. The new Pipeline Editor makes CI/CD easy to use Since its inception, the defining feature of GitLab CI/CD has been the .gitlab-ci.yml configuration file. Configuring pipelines as code means you can version control and collaborate on pipelines using the same interfaces you use for your application code. Additionally, GitLab's advanced syntax provides a high degree of customization for sophisticated and demanding CI/CD use cases. However, all of this power and flexibility comes with a fair bit of complexity. This is why our vision for CI/CD is to create a visual pipeline authoring experience, built-in to GitLab, that simplifies the complexity letting you quickly create and edit pipelines while still exposing adv...