[{"data":1,"prerenderedAt":3509},["ShallowReactive",2],{"/en-us/blog/categories/open-source/":3,"navigation-en-us":21,"banner-en-us":439,"footer-en-us":451,"open-source-category-page-en-us":662},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":12,"_id":15,"_type":16,"title":9,"_source":17,"_file":18,"_stem":19,"_extension":20},"/en-us/blog/categories/open-source","categories",false,"",{"title":9,"description":10},"Open Source","Browse articles related to Open Source on the GitLab Blog",{"name":9},{"template":13,"slug":14,"hide":6},"BlogCategory","open-source","content:en-us:blog:categories:open-source.yml","yaml","content","en-us/blog/categories/open-source.yml","en-us/blog/categories/open-source","yml",{"_path":22,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"data":24,"_id":435,"_type":16,"title":436,"_source":17,"_file":437,"_stem":438,"_extension":20},"/shared/en-us/main-navigation","en-us",{"logo":25,"freeTrial":30,"sales":35,"login":40,"items":45,"search":376,"minimal":407,"duo":426},{"config":26},{"href":27,"dataGaName":28,"dataGaLocation":29},"/","gitlab logo","header",{"text":31,"config":32},"Get free trial",{"href":33,"dataGaName":34,"dataGaLocation":29},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":36,"config":37},"Talk to sales",{"href":38,"dataGaName":39,"dataGaLocation":29},"/sales/","sales",{"text":41,"config":42},"Sign in",{"href":43,"dataGaName":44,"dataGaLocation":29},"https://gitlab.com/users/sign_in/","sign in",[46,90,186,191,297,357],{"text":47,"config":48,"cards":50,"footer":73},"Platform",{"dataNavLevelOne":49},"platform",[51,57,65],{"title":47,"description":52,"link":53},"The most comprehensive AI-powered DevSecOps Platform",{"text":54,"config":55},"Explore our Platform",{"href":56,"dataGaName":49,"dataGaLocation":29},"/platform/",{"title":58,"description":59,"link":60},"GitLab Duo (AI)","Build software faster with AI at every stage of development",{"text":61,"config":62},"Meet GitLab Duo",{"href":63,"dataGaName":64,"dataGaLocation":29},"/gitlab-duo/","gitlab duo ai",{"title":66,"description":67,"link":68},"Why GitLab","10 reasons why Enterprises choose GitLab",{"text":69,"config":70},"Learn more",{"href":71,"dataGaName":72,"dataGaLocation":29},"/why-gitlab/","why gitlab",{"title":74,"items":75},"Get started with",[76,81,86],{"text":77,"config":78},"Platform Engineering",{"href":79,"dataGaName":80,"dataGaLocation":29},"/solutions/platform-engineering/","platform engineering",{"text":82,"config":83},"Developer Experience",{"href":84,"dataGaName":85,"dataGaLocation":29},"/developer-experience/","Developer experience",{"text":87,"config":88},"MLOps",{"href":89,"dataGaName":87,"dataGaLocation":29},"/topics/devops/the-role-of-ai-in-devops/",{"text":91,"left":92,"config":93,"link":95,"lists":99,"footer":168},"Product",true,{"dataNavLevelOne":94},"solutions",{"text":96,"config":97},"View all Solutions",{"href":98,"dataGaName":94,"dataGaLocation":29},"/solutions/",[100,125,147],{"title":101,"description":102,"link":103,"items":108},"Automation","CI/CD and automation to accelerate deployment",{"config":104},{"icon":105,"href":106,"dataGaName":107,"dataGaLocation":29},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[109,113,117,121],{"text":110,"config":111},"CI/CD",{"href":112,"dataGaLocation":29,"dataGaName":110},"/solutions/continuous-integration/",{"text":114,"config":115},"AI-Assisted Development",{"href":63,"dataGaLocation":29,"dataGaName":116},"AI assisted development",{"text":118,"config":119},"Source Code Management",{"href":120,"dataGaLocation":29,"dataGaName":118},"/solutions/source-code-management/",{"text":122,"config":123},"Automated Software Delivery",{"href":106,"dataGaLocation":29,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"Security","Deliver code faster without compromising security",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":29,"icon":132},"/solutions/security-compliance/","security and compliance","ShieldCheckLight",[134,137,142],{"text":135,"config":136},"Security & Compliance",{"href":130,"dataGaLocation":29,"dataGaName":135},{"text":138,"config":139},"Software Supply Chain Security",{"href":140,"dataGaLocation":29,"dataGaName":141},"/solutions/supply-chain/","Software supply chain security",{"text":143,"config":144},"Compliance & Governance",{"href":145,"dataGaLocation":29,"dataGaName":146},"/solutions/continuous-software-compliance/","Compliance and governance",{"title":148,"link":149,"items":154},"Measurement",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":29},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[155,159,163],{"text":156,"config":157},"Visibility & Measurement",{"href":152,"dataGaLocation":29,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"Value Stream Management",{"href":162,"dataGaLocation":29,"dataGaName":160},"/solutions/value-stream-management/",{"text":164,"config":165},"Analytics & Insights",{"href":166,"dataGaLocation":29,"dataGaName":167},"/solutions/analytics-and-insights/","Analytics and insights",{"title":169,"items":170},"GitLab for",[171,176,181],{"text":172,"config":173},"Enterprise",{"href":174,"dataGaLocation":29,"dataGaName":175},"/enterprise/","enterprise",{"text":177,"config":178},"Small Business",{"href":179,"dataGaLocation":29,"dataGaName":180},"/small-business/","small business",{"text":182,"config":183},"Public Sector",{"href":184,"dataGaLocation":29,"dataGaName":185},"/solutions/public-sector/","public sector",{"text":187,"config":188},"Pricing",{"href":189,"dataGaName":190,"dataGaLocation":29,"dataNavLevelOne":190},"/pricing/","pricing",{"text":192,"config":193,"link":195,"lists":199,"feature":284},"Resources",{"dataNavLevelOne":194},"resources",{"text":196,"config":197},"View all resources",{"href":198,"dataGaName":194,"dataGaLocation":29},"/resources/",[200,233,256],{"title":201,"items":202},"Getting started",[203,208,213,218,223,228],{"text":204,"config":205},"Install",{"href":206,"dataGaName":207,"dataGaLocation":29},"/install/","install",{"text":209,"config":210},"Quick start guides",{"href":211,"dataGaName":212,"dataGaLocation":29},"/get-started/","quick setup checklists",{"text":214,"config":215},"Learn",{"href":216,"dataGaLocation":29,"dataGaName":217},"https://university.gitlab.com/","learn",{"text":219,"config":220},"Product documentation",{"href":221,"dataGaName":222,"dataGaLocation":29},"https://docs.gitlab.com/","product documentation",{"text":224,"config":225},"Best practice videos",{"href":226,"dataGaName":227,"dataGaLocation":29},"/getting-started-videos/","best practice videos",{"text":229,"config":230},"Integrations",{"href":231,"dataGaName":232,"dataGaLocation":29},"/integrations/","integrations",{"title":234,"items":235},"Discover",[236,241,246,251],{"text":237,"config":238},"Customer success stories",{"href":239,"dataGaName":240,"dataGaLocation":29},"/customers/","customer success stories",{"text":242,"config":243},"Blog",{"href":244,"dataGaName":245,"dataGaLocation":29},"/blog/","blog",{"text":247,"config":248},"Remote",{"href":249,"dataGaName":250,"dataGaLocation":29},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":252,"config":253},"TeamOps",{"href":254,"dataGaName":255,"dataGaLocation":29},"/teamops/","teamops",{"title":257,"items":258},"Connect",[259,264,269,274,279],{"text":260,"config":261},"GitLab Services",{"href":262,"dataGaName":263,"dataGaLocation":29},"/services/","services",{"text":265,"config":266},"Community",{"href":267,"dataGaName":268,"dataGaLocation":29},"/community/","community",{"text":270,"config":271},"Forum",{"href":272,"dataGaName":273,"dataGaLocation":29},"https://forum.gitlab.com/","forum",{"text":275,"config":276},"Events",{"href":277,"dataGaName":278,"dataGaLocation":29},"/events/","events",{"text":280,"config":281},"Partners",{"href":282,"dataGaName":283,"dataGaLocation":29},"/partners/","partners",{"backgroundColor":285,"textColor":286,"text":287,"image":288,"link":292},"#2f2a6b","#fff","Insights for the future of software development",{"altText":289,"config":290},"the source promo card",{"src":291},"/images/navigation/the-source-promo-card.svg",{"text":293,"config":294},"Read the latest",{"href":295,"dataGaName":296,"dataGaLocation":29},"/the-source/","the source",{"text":298,"config":299,"lists":301},"Company",{"dataNavLevelOne":300},"company",[302],{"items":303},[304,309,315,317,322,327,332,337,342,347,352],{"text":305,"config":306},"About",{"href":307,"dataGaName":308,"dataGaLocation":29},"/company/","about",{"text":310,"config":311,"footerGa":314},"Jobs",{"href":312,"dataGaName":313,"dataGaLocation":29},"/jobs/","jobs",{"dataGaName":313},{"text":275,"config":316},{"href":277,"dataGaName":278,"dataGaLocation":29},{"text":318,"config":319},"Leadership",{"href":320,"dataGaName":321,"dataGaLocation":29},"/company/team/e-group/","leadership",{"text":323,"config":324},"Team",{"href":325,"dataGaName":326,"dataGaLocation":29},"/company/team/","team",{"text":328,"config":329},"Handbook",{"href":330,"dataGaName":331,"dataGaLocation":29},"https://handbook.gitlab.com/","handbook",{"text":333,"config":334},"Investor relations",{"href":335,"dataGaName":336,"dataGaLocation":29},"https://ir.gitlab.com/","investor relations",{"text":338,"config":339},"Trust Center",{"href":340,"dataGaName":341,"dataGaLocation":29},"/security/","trust center",{"text":343,"config":344},"AI Transparency Center",{"href":345,"dataGaName":346,"dataGaLocation":29},"/ai-transparency-center/","ai transparency center",{"text":348,"config":349},"Newsletter",{"href":350,"dataGaName":351,"dataGaLocation":29},"/company/contact/","newsletter",{"text":353,"config":354},"Press",{"href":355,"dataGaName":356,"dataGaLocation":29},"/press/","press",{"text":358,"config":359,"lists":360},"Contact us",{"dataNavLevelOne":300},[361],{"items":362},[363,366,371],{"text":36,"config":364},{"href":38,"dataGaName":365,"dataGaLocation":29},"talk to sales",{"text":367,"config":368},"Get help",{"href":369,"dataGaName":370,"dataGaLocation":29},"/support/","get help",{"text":372,"config":373},"Customer portal",{"href":374,"dataGaName":375,"dataGaLocation":29},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":377,"login":378,"suggestions":385},"Close",{"text":379,"link":380},"To search repositories and projects, login to",{"text":381,"config":382},"gitlab.com",{"href":43,"dataGaName":383,"dataGaLocation":384},"search login","search",{"text":386,"default":387},"Suggestions",[388,390,394,396,400,404],{"text":58,"config":389},{"href":63,"dataGaName":58,"dataGaLocation":384},{"text":391,"config":392},"Code Suggestions (AI)",{"href":393,"dataGaName":391,"dataGaLocation":384},"/solutions/code-suggestions/",{"text":110,"config":395},{"href":112,"dataGaName":110,"dataGaLocation":384},{"text":397,"config":398},"GitLab on AWS",{"href":399,"dataGaName":397,"dataGaLocation":384},"/partners/technology-partners/aws/",{"text":401,"config":402},"GitLab on Google Cloud",{"href":403,"dataGaName":401,"dataGaLocation":384},"/partners/technology-partners/google-cloud-platform/",{"text":405,"config":406},"Why GitLab?",{"href":71,"dataGaName":405,"dataGaLocation":384},{"freeTrial":408,"mobileIcon":413,"desktopIcon":418,"secondaryButton":421},{"text":409,"config":410},"Start free trial",{"href":411,"dataGaName":34,"dataGaLocation":412},"https://gitlab.com/-/trials/new/","nav",{"altText":414,"config":415},"Gitlab Icon",{"src":416,"dataGaName":417,"dataGaLocation":412},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":414,"config":419},{"src":420,"dataGaName":417,"dataGaLocation":412},"/images/brand/gitlab-logo-type.svg",{"text":422,"config":423},"Get Started",{"href":424,"dataGaName":425,"dataGaLocation":412},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":427,"mobileIcon":431,"desktopIcon":433},{"text":428,"config":429},"Learn more about GitLab Duo",{"href":63,"dataGaName":430,"dataGaLocation":412},"gitlab duo",{"altText":414,"config":432},{"src":416,"dataGaName":417,"dataGaLocation":412},{"altText":414,"config":434},{"src":420,"dataGaName":417,"dataGaLocation":412},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":440,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"title":441,"button":442,"config":446,"_id":448,"_type":16,"_source":17,"_file":449,"_stem":450,"_extension":20},"/shared/en-us/banner","GitLab Duo Agent Platform is now in public beta!",{"text":69,"config":443},{"href":444,"dataGaName":445,"dataGaLocation":29},"/gitlab-duo/agent-platform/","duo banner",{"layout":447},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":452,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"data":453,"_id":658,"_type":16,"title":659,"_source":17,"_file":660,"_stem":661,"_extension":20},"/shared/en-us/main-footer",{"text":454,"source":455,"edit":461,"contribute":466,"config":471,"items":476,"minimal":650},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":456,"config":457},"View page source",{"href":458,"dataGaName":459,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":462,"config":463},"Edit this page",{"href":464,"dataGaName":465,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":467,"config":468},"Please contribute",{"href":469,"dataGaName":470,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":472,"facebook":473,"youtube":474,"linkedin":475},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[477,500,557,586,620],{"title":47,"links":478,"subMenu":483},[479],{"text":480,"config":481},"DevSecOps platform",{"href":56,"dataGaName":482,"dataGaLocation":460},"devsecops platform",[484],{"title":187,"links":485},[486,490,495],{"text":487,"config":488},"View plans",{"href":189,"dataGaName":489,"dataGaLocation":460},"view plans",{"text":491,"config":492},"Why Premium?",{"href":493,"dataGaName":494,"dataGaLocation":460},"/pricing/premium/","why premium",{"text":496,"config":497},"Why Ultimate?",{"href":498,"dataGaName":499,"dataGaLocation":460},"/pricing/ultimate/","why ultimate",{"title":501,"links":502},"Solutions",[503,508,511,513,518,523,527,530,534,539,541,544,547,552],{"text":504,"config":505},"Digital transformation",{"href":506,"dataGaName":507,"dataGaLocation":460},"/topics/digital-transformation/","digital transformation",{"text":135,"config":509},{"href":130,"dataGaName":510,"dataGaLocation":460},"security & compliance",{"text":124,"config":512},{"href":106,"dataGaName":107,"dataGaLocation":460},{"text":514,"config":515},"Agile development",{"href":516,"dataGaName":517,"dataGaLocation":460},"/solutions/agile-delivery/","agile delivery",{"text":519,"config":520},"Cloud transformation",{"href":521,"dataGaName":522,"dataGaLocation":460},"/topics/cloud-native/","cloud transformation",{"text":524,"config":525},"SCM",{"href":120,"dataGaName":526,"dataGaLocation":460},"source code management",{"text":110,"config":528},{"href":112,"dataGaName":529,"dataGaLocation":460},"continuous integration & delivery",{"text":531,"config":532},"Value stream management",{"href":162,"dataGaName":533,"dataGaLocation":460},"value stream management",{"text":535,"config":536},"GitOps",{"href":537,"dataGaName":538,"dataGaLocation":460},"/solutions/gitops/","gitops",{"text":172,"config":540},{"href":174,"dataGaName":175,"dataGaLocation":460},{"text":542,"config":543},"Small business",{"href":179,"dataGaName":180,"dataGaLocation":460},{"text":545,"config":546},"Public sector",{"href":184,"dataGaName":185,"dataGaLocation":460},{"text":548,"config":549},"Education",{"href":550,"dataGaName":551,"dataGaLocation":460},"/solutions/education/","education",{"text":553,"config":554},"Financial services",{"href":555,"dataGaName":556,"dataGaLocation":460},"/solutions/finance/","financial services",{"title":192,"links":558},[559,561,563,565,568,570,572,574,576,578,580,582,584],{"text":204,"config":560},{"href":206,"dataGaName":207,"dataGaLocation":460},{"text":209,"config":562},{"href":211,"dataGaName":212,"dataGaLocation":460},{"text":214,"config":564},{"href":216,"dataGaName":217,"dataGaLocation":460},{"text":219,"config":566},{"href":221,"dataGaName":567,"dataGaLocation":460},"docs",{"text":242,"config":569},{"href":244,"dataGaName":245,"dataGaLocation":460},{"text":237,"config":571},{"href":239,"dataGaName":240,"dataGaLocation":460},{"text":247,"config":573},{"href":249,"dataGaName":250,"dataGaLocation":460},{"text":260,"config":575},{"href":262,"dataGaName":263,"dataGaLocation":460},{"text":252,"config":577},{"href":254,"dataGaName":255,"dataGaLocation":460},{"text":265,"config":579},{"href":267,"dataGaName":268,"dataGaLocation":460},{"text":270,"config":581},{"href":272,"dataGaName":273,"dataGaLocation":460},{"text":275,"config":583},{"href":277,"dataGaName":278,"dataGaLocation":460},{"text":280,"config":585},{"href":282,"dataGaName":283,"dataGaLocation":460},{"title":298,"links":587},[588,590,592,594,596,598,600,604,609,611,613,615],{"text":305,"config":589},{"href":307,"dataGaName":300,"dataGaLocation":460},{"text":310,"config":591},{"href":312,"dataGaName":313,"dataGaLocation":460},{"text":318,"config":593},{"href":320,"dataGaName":321,"dataGaLocation":460},{"text":323,"config":595},{"href":325,"dataGaName":326,"dataGaLocation":460},{"text":328,"config":597},{"href":330,"dataGaName":331,"dataGaLocation":460},{"text":333,"config":599},{"href":335,"dataGaName":336,"dataGaLocation":460},{"text":601,"config":602},"Sustainability",{"href":603,"dataGaName":601,"dataGaLocation":460},"/sustainability/",{"text":605,"config":606},"Diversity, inclusion and belonging (DIB)",{"href":607,"dataGaName":608,"dataGaLocation":460},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":338,"config":610},{"href":340,"dataGaName":341,"dataGaLocation":460},{"text":348,"config":612},{"href":350,"dataGaName":351,"dataGaLocation":460},{"text":353,"config":614},{"href":355,"dataGaName":356,"dataGaLocation":460},{"text":616,"config":617},"Modern Slavery Transparency Statement",{"href":618,"dataGaName":619,"dataGaLocation":460},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":621,"links":622},"Contact Us",[623,626,628,630,635,640,645],{"text":624,"config":625},"Contact an expert",{"href":38,"dataGaName":39,"dataGaLocation":460},{"text":367,"config":627},{"href":369,"dataGaName":370,"dataGaLocation":460},{"text":372,"config":629},{"href":374,"dataGaName":375,"dataGaLocation":460},{"text":631,"config":632},"Status",{"href":633,"dataGaName":634,"dataGaLocation":460},"https://status.gitlab.com/","status",{"text":636,"config":637},"Terms of use",{"href":638,"dataGaName":639,"dataGaLocation":460},"/terms/","terms of use",{"text":641,"config":642},"Privacy statement",{"href":643,"dataGaName":644,"dataGaLocation":460},"/privacy/","privacy statement",{"text":646,"config":647},"Cookie preferences",{"dataGaName":648,"dataGaLocation":460,"id":649,"isOneTrustButton":92},"cookie preferences","ot-sdk-btn",{"items":651},[652,654,656],{"text":636,"config":653},{"href":638,"dataGaName":639,"dataGaLocation":460},{"text":641,"config":655},{"href":643,"dataGaName":644,"dataGaLocation":460},{"text":646,"config":657},{"dataGaName":648,"dataGaLocation":460,"id":649,"isOneTrustButton":92},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",{"featuredPost":663,"allPosts":685,"totalPages":3507,"initialPosts":3508},{"_path":664,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":665,"content":668,"config":678,"_id":681,"_type":16,"title":682,"_source":17,"_file":683,"_stem":684,"_extension":20},"/en-us/blog/how-we-use-gitlab-to-grow-open-source-communities",{"noIndex":6,"title":666,"description":667},"How we use GitLab to grow open source communities","Learn how to use the DevSecOps platform to solve onboarding problems for new contributors.",{"title":666,"description":667,"body":669,"authors":670,"heroImage":673,"category":14,"tags":674,"date":677},"\nGitLab's Contributor Success team faced a challenge.\nWhile our returning open source contributors were merging more code changes and collaborating on deeper features, first-time contributors were struggling to get started. We knew many newcomers to open source often gave up or never asked for help. But as advocates for [GitLab's mission](https://handbook.gitlab.com/handbook/company/mission/)\nto enable everyone to contribute, we wanted to do better.\n\nWe started running research studies on open source contributors to GitLab. Then we improved the stumbling blocks. In January, we achieved a record of 184 unique community contributors to GitLab in a single month,\nexceeding our team target of 170 for the first time.\n\nThree months later, we broke it again with 192.\n\nHere's how we used GitLab's own tools to solve the newcomer dilemma and grow our open source community.\n\n## What we learned studying first-time contributors\n\nIn 2023, we conducted the first-ever user study of GitLab open source contributors.\nWe watched six participants who had never contributed to GitLab make their first attempt. They completed diary studies and Zoom interviews detailing their experience.\n\nParticipants told us:\n\n* The contributor documentation was confusing\n* Getting started felt overwhelming\n* It wasn't clear how or where to find help\n\nOnly one out of the six participants successfully merged a code contribution to GitLab during the study.\n\nIt became clear we needed to focus on the onboarding experience if we wanted new contributors to succeed.\nSo we [iterated](https://handbook.gitlab.com/handbook/values/#iteration)!\n\nOur team spent the next year addressing their challenges. We used GitLab tools,\nsuch as issue templates, scheduled pipelines, webhooks, and the GitLab Query Language (GLQL), to build an innovative semi-automated onboarding solution.\n\nIn 2025, we performed a follow-up user study with new participants who had never made a contribution to GitLab. All 10 participants successfully created and merged contributions to GitLab, a 100% success rate. The feedback showed a great appreciation for the new onboarding process, the speed at which\nmaintainers checked in on contributors, and the recognition we offered to contributors.\n\nEven better, participants shared how much fun they had contributing:\n\"I felt a little rush of excitement at being able to say 'I helped build GitLab.'\"\n\n## We built personal onboarding with GitLab\n\nOur solution started with engagement.\nTo help newcomers get started, we introduced a personal onboarding process connecting each\ncontributor with a community maintainer.\n\nWe created an [issue template](https://gitlab.com/gitlab-community/meta/-/blob/ac0e5579a6a1cf26e367010bfcf6c7d35b38d4f8/.gitlab/issue_templates/Onboarding.md) with a clear checklist of tasks.\n\nThe onboarding issue also handles access approval for the\n[GitLab community forks](https://about.gitlab.com/blog/gitlab-community-forks/),\na collection of shared projects that make it easier to push changes, collaborate with others,\nand access GitLab Ultimate and Duo features.\n\nUsing [scoped labels](https://docs.gitlab.com/user/project/labels/#scoped-labels), we indicate the status of the access request for easy maintainer follow-ups.\n\n![GitLab onboarding issue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/vkiyl0hrfbgcer3nz38r.png)\n\nWe started with a Ruby script run via a [scheduled pipeline](https://docs.gitlab.com/ci/pipelines/schedules/),\nchecking for new access requests and using the issue template to create personalized onboarding issues.\n\nFrom here, our maintainers engage with new contributors to verify access, answer questions, and find issues.\n\n## We standardized responses with comment templates\n\nWith multiple maintainers in the GitLab community, we wanted to ensure consistent and clear messaging.\n\nWe created [comment templates](https://docs.gitlab.com/user/profile/comment_templates/),\nwhich we sync with the repository using the GraphQL API and a\n[Ruby script](https://gitlab.com/gitlab-community/meta/-/blob/dd6e0c2861c848251424b72e3e8c5603dcaac725/bin/sync_comment_templates.rb).\n\nThe script is triggered in `.gitlab-ci.yml` when comment template changes are pushed\nto the default branch (a dry run is triggered in merge requests).\n\n```yaml\nexecute:sync-comment-templates:\n  stage: execute\n  extends: .ruby\n  script:\n    - bundle exec bin/sync_comment_templates.rb\n  variables:\n    SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_ONLY\n  rules:\n    - if: $CI_PIPELINE_SOURCE == 'schedule' || $CI_PIPELINE_SOURCE == \"trigger\"\n      when: never\n    - if: $EXECUTE_SYNC_COMMENT_TEMPLATES == '1'\n    - if: $CI_MERGE_REQUEST_IID\n      changes:\n        - .gitlab/comment_templates/**/*\n      variables:\n        REPORT_ONLY: 1\n    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH\n      changes:\n        - .gitlab/comment_templates/**/*\n      variables:\n        FORCE_SYNC: 1\n        DRY_RUN: 0\n        SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_WRITE\n```\n\n\n\n![GitLab comment template](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/qmfaymqhq3zgdcnm6a3j.png)\n\n\n\n## We eliminated the 5-minute wait time\n\nOur first iteration was a little slow.\nAfter starting the onboarding process, contributors wondered what to do next while the scheduled\npipeline took up to 5 minutes to create their onboarding issue.\nFive minutes feels like forever when you have the momentum to dive in.\n\n[Niklas](https://gitlab.com/Taucher2003), a member of our [Core team ](https://about.gitlab.com/community/core-team/), built a solution.\nHe added [webhook events for access requests](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163094)\nand [custom payload templates for webhooks](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/142738).\n\nThese features together allowed us to trigger a pipeline immediately instead of waiting for the schedule.\nThis reduces the time to roughly 40 seconds (the time it takes for the CI pipeline to run)\nand generates the onboarding issue right away. It also saves thousands of wasted pipelines and compute minutes when no access requests actually need processing.\n\nWe set up a [pipeline trigger token](https://docs.gitlab.com/ci/triggers/#create-a-pipeline-trigger-token)\nand used this as the target for the webhook, passing the desired environment variables:\n\n```json\n{\n  \"ref\": \"main\",\n  \"variables\": {\n    \"EXECUTE_ACCESS_REQUESTS\": \"1\",\n    \"DRY_RUN\": \"0\",\n    \"PIPELINE_NAME\": \"Create onboarding issues\",\n    \"GROUP_ID\": \"{{group_id}}\",\n    \"EVENT_NAME\": \"{{event_name}}\"\n  }\n}\n```\n\n![Pipeline list](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512805/qom7hnqnwfcdzvria7dd.png)\n\n## We automated follow-ups\n\nWith an increasing volume of customers and community contributors onboarding to the GitLab community,\nmaintainers struggled to track which issues needed attention and some follow-up questions got lost.\n\nWe built automation leveraging webhooks and Ruby to label issues updated by community members.\nThis creates a clear signal of issue status for maintainers.\n\n[GitLab Triage](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage)\nautomatically nudges idle onboarding issues to ensure we maintain contributor momentum.\n\n![Automated nudge for idle GitLab onboarding issues](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512811/gkj3qaidjl1vv2dlu8ep.png)\n\n## We organized issue tracking with GLQL\n\nWe built a [GLQL view](https://docs.gitlab.com/user/glql/) to keep track of issues.\nThis GLQL table summarizes onboarding issues which need attention,\nso maintainers can review and follow up with community members.\n\n![GLQL view of issue tracking](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/hdduf0orntdfhkysheae.png)\n\nThese GLQL views improved our overall triage [efficiency](https://handbook.gitlab.com/handbook/values/#efficiency).\nIt was so successful we ended up using this strategy within the [GitLab for Open Source](https://about.gitlab.com/solutions/open-source/)\nand [GitLab for Education](https://about.gitlab.com/solutions/education/) programs, too.\nWith GLQL tables for support issues, these community programs lowered their response times by 75%.\n\n## We made the README findable\n\nThe [@gitlab-community group](https://gitlab.com/gitlab-community/)\nis the home for contributors on Gitlab.com.\nWe already had a `README.md` file explaining the community forks and onboarding process, but this file\nlived in our meta project.\nWith our follow-up user study, we discovered this was a point of confusion for newcomers when their\nonboarding issues were under a different project.\n\nWe used [GitLab's project mirroring](https://docs.gitlab.com/user/project/repository/mirror/)\nto solve this and mirrored the meta project to `gitlab-profile`.\nThis surfaced the existing README file at the group level, making it easier to discover.\n\n![GitLab project mirroiring](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512809/kbgdxyilza71kmj0aeqt.png)\n\n![Group README](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/taosgn8vvgo8onszuwaf.png)\n\n## The results speak for themselves\n\nBy dogfooding GitLab, we improved the stumbling blocks found in our research studies\nand transformed the GitLab contributor journey.\nWe have grown the number of customers and community members contributing to GitLab,\nadding features to the product, solving bugs, and adding to our CI/CD catalog.\n\nOur onboarding process has increased the rate newcomers join the community, and our total number of\ncontributors on the community forks has doubled over the last 9 months.\n\n![Community forks growth chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/xagra4vfsrhbcwnzekmp.png)\n\nWe reduced the time it takes for newcomers to make their first contribution by connecting them\nwith maintainers faster and supporting them in getting started.\nWe use [GitLab's value stream analytics](https://docs.gitlab.com/user/group/value_stream_analytics/)\nto track our response rates.\n\n* First response time from community maintainers is down to 46 minutes over the last 3 months\n* Average approval time for community forks access is down to 1 hour over the last 3 months\n\n![Value stream analytics timeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512812/jzksakrfdb22hooqemzh.png)\n\nThe 100% success rate of our 2025 user study confirmed these improvements for our first-time contributors.\n\n## We invested time savings into contributor recognition\n\nFixing these newcomer challenges allowed us more capacity to focus on better recognition of\ncontributors, incentivizing first-timers to keep coming back.\nThe result is [contributors.gitlab.com](https://contributors.gitlab.com/).\nWe built out a central hub for our contributors that features gamified leaderboards,\nachievements, and rewards.\nContributors can see their impact, track progress, and grow in the community.\n\n## Sharing what we learned\n\nThese improvements work and are repeatable for other open source projects.\nWe are sharing our approach across communities and conferences so that other projects can consider using these tools to grow.\n\nAs more organizations learn the barriers to participation, we can create a more welcoming open source environment.\nWith these GitLab tools, we can offer a smoother experience for both contributors and maintainers.\nWe're committed to advancing this work and collaborating to remove barriers for open source projects everywhere.\n\n## Start the conversation\n\nWant to learn more about growing your contributor community?\nEmail `contributors@gitlab.com` or [open an issue](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues)\nto start a discussion.\nWe're here to help build communities.",[671,672],"Lee Tickett","Daniel Murphy","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099558/Blog/Hero%20Images/Blog/Hero%20Images/gitlabflatlogomap_gitlabflatlogomap.png_1750099558369.png",[675,268,676],"open source","product","2025-07-15",{"featured":6,"template":679,"slug":680},"BlogPost","how-we-use-gitlab-to-grow-open-source-communities","content:en-us:blog:how-we-use-gitlab-to-grow-open-source-communities.yml","How We Use Gitlab To Grow Open Source Communities","en-us/blog/how-we-use-gitlab-to-grow-open-source-communities.yml","en-us/blog/how-we-use-gitlab-to-grow-open-source-communities",[686,706,728,747,766,788,808,828,850,872,892,910,930,948,966,986,1008,1028,1047,1066,1086,1105,1125,1146,1166,1185,1204,1223,1241,1261,1280,1301,1320,1339,1359,1377,1398,1420,1441,1462,1482,1508,1528,1548,1568,1591,1610,1630,1650,1673,1693,1712,1732,1751,1772,1792,1811,1830,1850,1870,1889,1908,1928,1948,1970,1990,2009,2032,2053,2073,2094,2114,2133,2153,2172,2192,2211,2230,2249,2268,2288,2307,2329,2349,2370,2388,2407,2425,2443,2462,2482,2502,2521,2539,2559,2577,2596,2614,2634,2655,2676,2694,2715,2735,2753,2771,2791,2809,2827,2846,2864,2882,2900,2918,2936,2956,2976,2994,3012,3030,3050,3069,3087,3107,3126,3145,3166,3185,3205,3225,3245,3265,3284,3303,3322,3339,3357,3375,3394,3413,3432,3451,3470,3489],{"_path":687,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":688,"content":691,"config":700,"_id":702,"_type":16,"title":703,"_source":17,"_file":704,"_stem":705,"_extension":20},"/en-us/blog/what-s-new-in-git-2-50-0",{"noIndex":6,"title":689,"description":690},"What’s new in Git 2.50.0?","Here are contributions from GitLab's Git team and the Git community such as the git-diff-pairs(1) command and git-rev-list(1) option to perform batched reference updates.",{"title":689,"description":692,"authors":693,"heroImage":695,"body":696,"date":697,"category":14,"tags":698},"Here are contributions from GitLab's Git team and the Git community such as the git-diff-pairs(1) command and git-update-ref(1) option to perform batched reference updates.",[694],"Justin Tobler","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png","The Git project recently released [Git Version 2.50.0](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u). Let's look at a few notable highlights from this release, which includes contributions from the Git team at GitLab and also the wider Git community.\n## New git-diff-pairs(1) command\n\nDiffs are at the heart of every code review and show all the changes made\nbetween two revisions. GitLab shows diffs in various places, but the most\ncommon place is a merge request's [\"Changes\" tab](https://docs.gitlab.com/user/project/merge_requests/changes/).\nBehind the scenes, diff generation is powered by\n[`git-diff(1)`](https://git-scm.com/docs/git-diff). For example:\n\n```shell\n$ git diff HEAD~1 HEAD\n```\n\nThis command returns the full diff for all changed files. This might pose a scalability challenge because the number of files changed between a set of revisions could be very large and cause the command to reach self-imposed timeouts for the GitLab backend. For large change sets, it would be better if\nthere were a way to break diff computation into smaller, more digestible chunks.\n\nOne way this can be achieved is by using\n[`git-diff-tree(1)`](https://git-scm.com/docs/git-diff-tree) to retrieve info\nabout all the changed files:\n\n```shell\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n:100644 100644 c9adfed339 99acf81487 M      Documentation/RelNotes/2.50.0.adoc\n:100755 100755 1047b8d11d 208e91a17f M      GIT-VERSION-GEN\n```\n\nGit refers to this output as the [\"raw\" format](https://git-scm.com/docs/git-diff-tree#_raw_output_format).\nIn short, each line of output lists filepairs and the accompanying metadata\nabout what has changed between the start and end revisions. Compared to\ngenerating the \"patch\" output for large changes, this process is relatively\nquick and provides a summary of everything that changed. This command can optionally perform rename detection by  appending the `-M` flag to check if identified changes were due to a file rename.\n\nWith this information, we could use `git-diff(1)` to compute each of the\nfilepair diffs individually. For example, we can provide the blob IDs\ndirectly:\n\n```shell\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f\n```\n\nWe can repeat this process for each of the filepairs, but spinning up a\nseparate Git process for each individual file diff is not very efficient.\nFurthermore, when using blob IDs, the diff loses some contextual information\nsuch as the change status, and file modes which are stored in with the parent\ntree object. What we really want is a mechanism to feed \"raw\" filepair info and\ngenerate the corresponding patch output.\n\nWith the 2.50 release, Git has a new built-in command named\n[`git-diff-pairs(1)`](https://git-scm.com/docs/git-diff-pairs). This command\naccepts \"raw\" formatted filepair info as input on stdin to determine exactly which patches to output. The following example showcases how this command could be\nused:\n\n```shell\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n```\n\nWhen used in this manner, the resulting output is identical to using `git-diff(1)`.\nBy having a separate command to generate patch output, the \"raw\" output from\n`git-diff-tree(1)` can be broken up into smaller batches of filepairs and fed to separate\n`git-diff-pairs(1)` processes. This solves the previously mentioned scalability\nconcern because diffs no longer have to be computed all at once. Future GitLab\nreleases could build upon this mechanism to improve diff\ngeneration performance, especially in cases where large change sets are\nconcerned. For more information on this change, check out the corresponding\n[mailing-list thread](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/).\n\n_This project was led by [Justin Tobler](https://gitlab.com/justintobler)._\n\n## Batched reference updates\n\nGit provides the [`git-update-ref(1)`](https://git-scm.com/docs/git-update-ref)\ncommand to perform reference updates. When used with the `--stdin` flag,\nmultiple reference updates can be batched together in a single transaction by\nspecifying instructions for each reference update to be performed on stdin.\nBulk updating references in this manner also provides atomic behavior whereby a\nsingle reference update failure results in an aborted transaction and no\nreferences being updated. Here is an example showcasing this behavior:\n\n```shell\n# Create repository with three empty commits and branch named \"foo\"\n$ git init\n$ git commit --allow-empty -m 1\n$ git commit --allow-empty -m 2\n$ git commit --allow-empty -m 3\n$ git branch foo\n\n# Print out the commit IDs\n$ git rev-list HEAD\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n5a74cd330f04b96ce0666af89682d4d7580c354c\n5a6b339a8ebffde8c0590553045403dbda831518\n\n# Attempt to create a new reference and update existing reference in transaction.\n# Update is expected to fail because the specified old object ID doesn’t match.\n$ git update-ref --stdin \u003C\u003CEOF\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n> EOF\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n# The \"bar\" reference was not created.\n$ git switch bar\nfatal: invalid reference: bar\n```\n\nCompared to updating many references individually, updating in bulk is also\nmuch more efficient. While this works well, there might be certain\ncircumstances where it is okay for a subset of the requested reference updates\nto fail, but we still want to take advantage of the efficiency gains of bulk\nupdates.\n\nWith this release, `git-update-ref(1)` has the new `--batch-updates` option,\nwhich allows the updates to proceed even when one or more reference updates\nfails. In this mode, individual failures are reported in the following format:\n\n```text\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP \u003Crejection-reason> LF\n```\n\nThis allows successful reference updates to proceed while providing context to\nwhich updates were rejected and for what reason. Using the same example\nrepository from the previous example:\n\n```shell\n# Attempt to create a new reference and update existing reference in transaction.\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n> EOF\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n\n# The \"bar\" reference was created even though the update to \"foo\" was rejected.\n$ git switch bar\nSwitched to branch 'bar'\n```\n\nThis time, with the `--batch-updates` option, the reference creation succeeded\neven though the update didn't work. This patch series lays the groundwork for\nfuture performance improvements in `git-fetch(1)` and `git-receive-pack(1)`\nwhen references are updated in bulk. For more information, check the\n[mailing-list thread](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/)\n\n_This project was led by [Karthik Nayak](https://gitlab.com/knayakgl)._\n\n## New filter option for git-cat-file(1)\n\nWith [`git-cat-file(1)`](https://git-scm.com/docs/git-cat-file), it is possible\nto print info for all objects contained in the repository via the\n`--batch–all-objects` option. For example:\n\n```shell\n# Setup simple repository.\n$ git init\n$ echo foo >foo\n$ git add foo\n$ git commit -m init\n\n# Create an unreachable object.\n$ git commit --amend --no-edit\n\n# Use git-cat-file(1) to print info about all objects including unreachable objects.\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nIn some situations, a user might want to search through all objects in the\nrepository, but only output a subset based on some specified attribute. For\nexample, if we wanted to see only the objects that are commits, we could use\n`grep(1)`:\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nWhile this works, one downside with filtering the output is that\n`git-cat-file(1)` still has to traverse all the objects in the repository, even\nthe ones that the user is not interested in. This can be rather inefficient.\n\nWith this release, `git-cat-file(1)` now has the `--filter` option, which only\nshows objects matching the specified criteria. This is similar to the option of\nthe same name for `git-rev-list(1)`, but with only a subset of the filters\nsupported. The supported filters are `blob:none`, `blob:limit=`, as well as\n`object:type=`. Similar to the previous example, objects can be filtered by\ntype with Git directly:\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nNot only is it convenient for Git to handle the processing, for large\nrepositories with many objects, it is also potentially more efficient. If a\nrepository has bitmap indices, it becomes possible for Git to efficiently\nlookup objects of a specific type, and thus avoid scanning through the\npackfile, which leads to a significant speedup. Benchmarks conducted on the\n[Chromium repository](https://github.com/chromium/chromium.git) show\nsignificant improvements:\n\n```text\nBenchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter\n   Time (mean ± σ):     82.806 s ±  6.363 s    [User: 30.956 s, System: 8.264 s]\n   Range (min … max):   73.936 s … 89.690 s    10 runs\n\nBenchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag\n   Time (mean ± σ):      20.8 ms ±   1.3 ms    [User: 6.1 ms, System: 14.5 ms]\n   Range (min … max):    18.2 ms …  23.6 ms    127 runs\n\nBenchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit\n   Time (mean ± σ):      1.551 s ±  0.008 s    [User: 1.401 s, System: 0.147 s]\n   Range (min … max):    1.541 s …  1.566 s    10 runs\n\nBenchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree\n   Time (mean ± σ):     11.169 s ±  0.046 s    [User: 10.076 s, System: 1.063 s]\n   Range (min … max):   11.114 s … 11.245 s    10 runs\n\nBenchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob\n   Time (mean ± σ):     67.342 s ±  3.368 s    [User: 20.318 s, System: 7.787 s]\n   Range (min … max):   62.836 s … 73.618 s    10 runs\n\nBenchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none\n   Time (mean ± σ):     13.032 s ±  0.072 s    [User: 11.638 s, System: 1.368 s]\n   Range (min … max):   12.960 s … 13.199 s    10 runs\n\nSummary\n   git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag\n    74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit\n   538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree\n   627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none\n  3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob\n  3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter\n```\n\nInterestingly, these results indicate that the computation time now scales with\nthe number of objects for a given type instead of the number of total objects\nin the packfile. The original mailing-list thread can be found\n[here](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/).\n\n_This project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab)._\n\n## Improved performance when generating bundles\n\nGit provides a means to generate an archive of a repository which contains a\nspecified set of references and accompanying reachable objects via the\n[`git-bundle(1)`](https://git-scm.com/docs/git-bundle) command. This operation\nis used by GitLab to generate repository backups and also as part of the\n[bundle-URI](https://git-scm.com/docs/bundle-uri) mechanism.\n\nFor large repositories containing millions of references, this operation can\ntake hours or even days. For example, with the main GitLab repository\n([gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)), backup times were\naround 48 hours. Investigation revealed there was a performance bottleneck due\nto how Git was performing a check to avoid duplicated references being included\nin the bundle. The implementation used a nested `for` loop to iterate and\ncompare all listed references, leading to O(N^2) time complexity. This scales\nvery poorly as the number of references in a repository increases.\n\nIn this release, this issue was addressed by replacing the nested loops with a\nmap data structure leading to a significant speedup. The following benchmark\nthe performance improvement for creating a bundle with a repository containing\n100,000 references:\n\n```text\nBenchmark 1: bundle (refcount = 100000, revision = master)\n  Time (mean ± σ):     14.653 s ±  0.203 s    [User: 13.940 s, System: 0.762 s]\n  Range (min … max):   14.237 s … 14.920 s    10 runs\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\n  Time (mean ± σ):      2.394 s ±  0.023 s    [User: 1.684 s, System: 0.798 s]\n  Range (min … max):    2.364 s …  2.425 s    10 runs\n\nSummary\n  bundle (refcount = 100000, revision = HEAD) ran\n    6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n```\n\nTo learn more, check out our blog post\n[How we decreased GitLab repo backup times from 48 hours to 41 minutes](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/).\nYou can also find the original mailing list thread\n[here](https://lore.kernel.org/git/20250401-488-generating-bundles-with-many-references-has-non-linear-performance-v1-0-6d23b2d96557@gmail.com/).\n\n_This project was led by [Karthik Nayak](https://gitlab.com/knayakgl)._\n\n## Better bundle URI unbundling\n\nThrough the [bundle URI](https://git-scm.com/docs/bundle-uri) mechanism in Git,\nlocations to fetch bundles from can be provided to clients with the goal to\nhelp speed up clones and fetches. When a client downloads a bundle, references\nunder `refs/heads/*` are copied from the bundle into the repository along with\ntheir accompanying objects. A bundle might contain additional references\noutside of `refs/heads/*` such as `refs/tags/*`, which are simply ignored when\nusing bundle URI on clone.\n\nIn Git 2.50, this restriction is lifted, and all references\nmatching `refs/*` contained in the downloaded bundle are copied.\n[Scott Chacon](https://github.com/schacon), who contributed this functionality,\ndemonstrates the difference when cloning\n[gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss):\n\n```shell\n$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49\nCloning into 'gl2.49'...\nremote: Enumerating objects: 1092703, done.\nremote: Counting objects: 100% (973405/973405), done.\nremote: Compressing objects: 100% (385827/385827), done.\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\nChecking objects: 100% (4194304/4194304), done.\nChecking connectivity: 959668, done.\nUpdating files: 100% (59972/59972), done.\n\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\nCloning into 'gl-2.50'...\nremote: Enumerating objects: 65538, done.\nremote: Counting objects: 100% (56054/56054), done.\nremote: Compressing objects: 100% (28950/28950), done.\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\nUpdating files: 100% (59972/59972), done.\n```\n\nComparing these results, we see that Git 2.50 fetches 43,887 objects\n(40.42 MiB) after the bundle was extracted whereas Git 2.49 fetches a\ntotal of 959,773 objects (366.94 MiB). Git 2.50 fetches roughly 95% fewer\nobjects and 90% less data, which benefits both the client and the server. The\nserver needs to process a lot less data to the client and the client needs to\ndownload and extract less data. In the example provided by Scott this led to a\nspeedup of 25%.\n\nTo learn more, check out the corresponding\n[mailing-list thread](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/).\n\n_This patch series was contributed by [Scott Chacon](https://github.com/schacon)._\n\n## Read more\n\nThis article highlighted just a few of the contributions made by GitLab and\nthe wider Git community for this latest release. You can learn about these from\nthe [official release announcement](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/) of the Git project. Also, check\nout our [previous Git release blog posts](https://about.gitlab.com/blog/tags/git/)\nto see other past highlights of contributions from GitLab team members.\n","2025-06-16",[699,675,268],"git",{"featured":92,"template":679,"slug":701},"what-s-new-in-git-2-50-0","content:en-us:blog:what-s-new-in-git-2-50-0.yml","What S New In Git 2 50 0","en-us/blog/what-s-new-in-git-2-50-0.yml","en-us/blog/what-s-new-in-git-2-50-0",{"_path":707,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":708,"content":716,"config":722,"_id":724,"_type":16,"title":725,"_source":17,"_file":726,"_stem":727,"_extension":20},"/en-us/blog/journey-through-gits-20-year-history",{"title":709,"description":710,"ogTitle":709,"ogDescription":710,"noIndex":6,"ogImage":711,"ogUrl":712,"ogSiteName":713,"ogType":714,"canonicalUrls":712,"schema":715},"Journey through Git's 20-year history","Follow along as we reminisce about the first commit, the unique aspects of the earliest releases, and the confusion sparked by an update to the git-push(1) default behavior.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097380/Blog/Hero%20Images/Blog/Hero%20Images/git-20-years-opt2_TWNsNk8KH43b3jP0KLD0U_1750097380123.png","https://about.gitlab.com/blog/journey-through-gits-20-year-history","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Journey through Git's 20-year history\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2025-04-14\",\n      }",{"title":709,"description":710,"authors":717,"heroImage":711,"date":719,"body":720,"category":14,"tags":721},[718],"Patrick Steinhardt","2025-04-14","The Git project has just turned 20 years old. A lot has happened during these years, and while the conceptual design of Git hasn't changed significantly since its inception, the way users interact with the tool has changed quite significantly. We at GitLab are proud to build on top of this critical piece of software and to be part of its history.\n\nJoin us on a journey through Git's history to explore how it has evolved over the years.\n\n## The first commit\n\nThe first commit was made on April 7, 2005, by Linus Torvalds, the creator of the Linux kernel: `e83c5163316 (Initial revision\nof \"git\", the information manager from hell, 2005-04-07)`.\n\nAs we can see, this\ncommit does not contain a lot of files:\n\n```shell\n$ git ls-tree e83c5163316\n100644 blob a6bba79ba1f46a1bbf7773449c3bd2bb9bf48e8b\tMakefile\n100644 blob 27577f76849c09d3405397244eb3d8ae1d11b0f3\tREADME\n100644 blob 98a32a9ad39883c6d05a000a68511d4b1ee2b3c7\tcache.h\n100644 blob 74a0a234dd346fff51c773aa57d82fc4b83a8557\tcat-file.c\n100644 blob 840307af0cfaab31555795ce7175d5e9c9f981a0\tcommit-tree.c\n100644 blob 25dc13fe101b219f74007f3194b787dd99e863da\tinit-db.c\n100644 blob c924a6e0fc4c36bad6f23cb87ee59518c771f936\tread-cache.c\n100644 blob 1b47742d8cbc0d98903777758b7b519980e7499e\tread-tree.c\n100644 blob b8522886a15db861508fb6d03d4d88d6de912a4b\tshow-diff.c\n100644 blob 5085a5cb53ee52e1886ff6d46c609bdb2fc6d6cd\tupdate-cache.c\n100644 blob 921f981353229db0c56103a52609d35aff16f41b\twrite-tree.c\n```\n\nIn addition to build infrastructure, the first commit provides seven top-level commands:\n\n- `init-db` to initialize a new Git repository\n- `update-cache` to add files to the index\n- `write-tree` to take what is in the index and create a new tree from it\n- `read-tree` to read a tree object\n- `commit-tree` to create a commit from a tree\n- `cat-file` to read a specific object into a temporary file\n\nNote that the `git` command itself did not yet exist at this point in time.\nInstead, these commands had to be executed directly.\n\nAs example, let's create a\nnew repository:\n\n```shell\n$ mkdir repo\n$ cd repo\n$ init-db\ndefaulting to private storage area\n$ ls -a\n.  ..  .dircache\n```\n\nThat looks quite unfamiliar: There is no `.git` directory, but there is a\n`.dircache` directory. And where was the private storage area?\n\nThe early design of Git distinguished between a \"shared\" and \"private\" object\nstorage area. This object storage area was where all of your Git objects went. For example, your\ncommits and blobs.\n\nBy default, `init-db` created a private object storage area that was only used for\nthe managed directory that it was created in. A \"shared\" object storage area, on\nthe other hand, shared object content across multiple managed directories so\nthat the same object did not need to be stored twice.\n\n### Create a commit\n\nSo, now that we have a repository, how did we create a commit? Well, it isn't as\neasy as today's `git add . && git commit`. Instead, you had to:\n\n1. Update the index by calling `update-cache` for every file that you want to\n   add.\n1. Write a new tree by calling `write-tree`, which takes everything you have\n   added to the index.\n1. Set up environment variables to tell Git who you are.\n1. Write a commit object by calling `commit-tree`.\n\nLet’s create a commit in the repository:\n\n```shell\n$ echo content-1 >file-a\n$ update-cache file-a\n$ echo content-2 >file-b\n$ update-cache file-b\n$ write-tree\n3f143dfb48f2d84936626e2e5402e1f10c2050fb\n$ export COMMITTER_NAME=\"Patrick Steinhardt\"\n$ export COMMITER_EMAIL=ps@pks.im\n$ echo \"commit message\" | commit-tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nCommitting initial tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\n5f8e928066c03cebe5fd0a0cc1b93d058155b969\n```\n\nThis isn't exactly ergonomic, but it works! Let's have a look at the generated\ncommit:\n\n```shell\n$ cat-file 5f8e928066c03cebe5fd0a0cc1b93d058155b969\ntemp_git_file_rlTXtE: commit\n$ cat temp_git_file_rlTXtE\ntree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nauthor Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\ncommitter Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\n\ncommit message\n```\n\nNote that `cat-file` didn't print the contents directly, but instead wrote\nit into a temporary file first. But the contents of the file looked exactly how a\nmodern commit would look.\n\n### Making changes\n\nNow that we have files, how do we get their status? You might have guessed it:\nthis could be done with `show-diff`:\n\n```shell\n$ show-diff\nfile-a: ok\nfile-b: ok\n\n$ echo modified-content >file-a\n$ show-diff\n--- -\t2025-03-26 13:14:53.457611094 +0100\n+++ file-a\t2025-03-26 13:14:52.230085756 +0100\n@@ -1 +1 @@\n-content-1\n+modified-content\nfile-a:  46d8be14cdec97aac6a769fdbce4db340e888bf8\nfile-b: ok\n```\n\nAmazingly, `show-diff` even knew to already generate diffs between the old and\nnew state of modified files! Funny enough though, Git achieved this by simply\nexecuting the diff(1) Unix tool.\n\nIn summary, all of this was still rather bare-bones, but it performed all of the\nnecessary duties to track history. There were still many limitations:\n\n- There was no easy way yet to switch between commits.\n- There was no way to show logs.\n- There were no branches, tags, or even references. Users were expected to manually\n  keep track of object IDs.\n- There was no way to synchronize two repositories with one another. Instead,\n  users were expected to use rsync(1) to synchronize the `.dircache` directories.\n- There was no way to perform merges.\n\n## Git 0.99\n\nThe first test release of Git was Version 0.99. This release came only two months after\nthe initial commit, but already contained 1,076 commits. There had been almost 50\ndifferent developers involved. The most frequent committer at this point was\nLinus himself, but he was closely followed by Junio Hamano, the current maintainer.\n\nA lot of things had changed since the initial commit:\n\n- Git started to track different development branches by using references, which\n  in most cases removes the need to manually track object IDs.\n- There was a new remote protocol that allows two repositories to exchange\n  objects with one another.\n- The `.dircache` directory was renamed to `.git`.\n- It became possible to merge single files with one another.\n\nThe most important visible change, though, was the introduction of\nthe top-level `git` command and its subcommands. Interestingly, this release\nalso created the notion of \"plumbing\" and \"porcelain\" commands:\n\n- \"Plumbing\" tools are the low-level commands that access the underlying Git\n  repository.\n- \"Porcelain\" tools are shell scripts that wrap the plumbing commands to provide\n  a nicer, high-level user interface.\n\nThis split still exists nowadays as documented in\n[`git(1)`](https://git-scm.com/docs/git#_high_level_commands_porcelain), but because \nmost porcelain tools have been rewritten from shell scripts to C, the line between these two\ncategories has started to blur significantly.\n\n## Linus hands over maintainership\n\nLinus never started Git out of love for version control systems, but because there was a need to replace BitKeeper for Linux kernel development. As such, he never planned to keep maintaining Git forever. The intent was to maintain it until someone trustworthy stepped up.\n\nThat someone was Junio Hamano. Junio got involved in Git about a week after Linus’s first commit and already had a couple of hundred commits in the history after the Git 0.99 release. So, on July 26, 2005, [Linus made Junio the new maintainer of the Git project](https://lore.kernel.org/git/Pine.LNX.4.58.0507262004320.3227@g5.osdl.org/). While Linus has continued to contribute to Git, his involvement with the project faded over time, which is only natural considering that he is quite busy as head of the Linux project.\n\nJunio is still leading the Git project today.\n\n## Git 1.0\n\nThe first major release of Git happened on December 21, 2005, by\nJunio. Interestingly enough, there had been 34 releases between Version 0.99\nand Version 1.0: 0.99.1 to 0.99.7, 0.99.7a to 0.99.7d, 0.99.8 to 0.99.8g, and\n0.99.9 up to 0.99.9n.\n\nOne of the more important milestones since 0.99 was probably the addition of the `git-merge(1)`\ncommand that allows one to merge two trees with one another. This is in stark\ncontrast to before, where one had to basically script the merges file by file.\n\n### Remotes\n\nAnother significant change was the introduction of shorthand notation for\nremote repositories. While Git already knew how to talk to remote repositories,\nusers always had to specify the URL to fetch from every single time they wanted\nto fetch changes from it. This was quite unfriendly to the users, because, typically, they wanted to interact with the same remote over and over again.\n\nYou may know about how remotes work now, but the mechanism that existed at  \nthis point in time was still significantly different. There was no `git-remote(1)`  \ncommand that you could use to manage your remotes. Remotes weren't even stored  \nin your `.git/config` file. In fact, when remotes were first introduced in  \nVersion 0.99.2, Git didn't even *have* config files.\n\nInstead, you had to configure remotes by writing a file into the  \n`.git/branches` directory, which nowadays feels somewhat counterintuitive. But  \nthe mechanism still works today:\n\n```shell\n$ git init repo --\nInitialized empty Git repository in /tmp/repo/.git/\n$ cd repo\n$ mkdir .git/branches\n$ echo https://gitlab.com/git-scm/git.git >.git/branches/origin\n$ git fetch origin refs/heads/master\n```\n\nBut that isn't all! The directory was soon renamed in Git Version 0.99.5 to \"remotes\", so there are a total of three different ways to configure remotes in a modern Git client.\n\nMost of you have probably never used either `.git/branches` nor `.git/remotes`,  \nand both of these mechanisms have been deprecated since 2005 and 2011,  \nrespectively. Furthermore, these directories will finally be removed in Git 3.0.\n\n## Git branding\n\nIn 2007, the first Git logo was created. It’s arguable if you can call it a logo, because it only consisted of three red minus signs above three green plus signs, reflecting what the output of `git diff` looks like:\n\n![three red minus signs above three green plus signs, reflecting what the output of `git diff`](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097387927.png)\n\nA bit later, in 2008, the website [git-scm.com](https://git-scm.com) was launched:\n\n![landing page for git-scm.com in 2006](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097387930.png)\n\nIn 2012, the Git website was [revamped](https://lore.kernel.org/git/CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com/) by Scott Chacon and Jason Long. It looks pretty similar to how it looks today:\n\n![git website revamped in 2012](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097387932.png)\n\nThis site redesign sports the new red-orange logo designed by Jason Long; the same logo that's currently used:\n\n![git logo](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097387934.png)\n\n## Git 2.0\n\nGit already started to look a lot like modern Git at the 1.0 release, so we\nare going to do a big historical jump to Git 2.0. This version was\nreleased around 10 years after Git 1.0 and was the first release that\nintentionally contained backwards-incompatible changes in central workflows.\n\n### `git-push(1)` default behavior\n\nThe change that arguably caused most the confusion in this release was the\nupdated default behavior of `git-push(1)`.\n\nThere are a couple of different actions that Git could take when you push\ninto a remote repository and don’t specify exactly what you want to push:\n\n- Git could refuse to do anything, asking you to provide more information of\n  what exactly you want to push.\n- Git could push the currently checked out branch.\n- Git could push the currently checked out branch, but only if it knows that it\n  has an equivalent on the remote side.\n- Git could push all of your branches that have an equivalent on the remote side.\n\nThe behavior of modern Git is the so-called \"simple\" strategy, which is the third\noption above. But before Git 2.0, the default behavior was the \"matching\"\nstrategy, which is the last option.\n\nThe “matching” strategy was significantly more risky. You always had to make sure that you\nwere fine with pushing all of your local branches that have an equivalent on the\nremote side before pushing. Otherwise, you might have ended up\npushing changes unintentionally. As such, it was decided to change the strategy\nto \"simple\" to reduce the risk and help out Git beginners.\n\n### `git-add(1)`\n\nAnother big change was the default behavior of `git-add(1)` when it comes to  \ntracked files that have been deleted. Before Git 2.0, `git-add(1)` wouldn't  \nstage deleted files automatically, but you instead had to manually add each  \ndeleted file by using `git-rm(1)` to make them part of a commit. With Git 2.0, this behavior was changed so that `git-add(1)` also adds deleted files to the index.\n\n## Celebrating the Git community\n\nI won’t bore you with the details around how Git works nowadays – you probably use it daily anyway, and, if you don’t, there are many tutorials out there that can help you get started. Instead, let’s celebrate the Git community, which has ensured that Git works as well as it does 20 years later.\n\nOver time, Git has:\n\n- Accumulated 56,721 commits as of the Git 2.49 release.\n- Received contributions from more than 2,000 different individuals.\n- Published 60 major releases.\n\nThe Git project also has a steady influx of new contributors by taking part in [Google Summer of Code](https://summerofcode.withgoogle.com/) and [Outreachy](https://www.outreachy.org/). New contributors like these are what will ensure that the Git project will remain healthy in the long term.\n\nAs such, let me extend a big thank you to all contributors. It is your contributions that have made Git possible.\n\n## Going forward\n\nIt should be an uncontroversial take to say that Git has essentially won the competition of version control systems. It has significant market share, and it isn't easy to find open source projects that are using a version control system other than Git. So it has clearly done a lot of things right.\n\nThat being said, its development hasn't stood still, and there are still many challenges ahead of Git. On the one hand, we have technical challenges:\n- modernization of an aging code base  \n- scaling with the ever-growing size of monorepos  \n- handling large binary files better\n\nAnd on the other hand, there are problems of a more social type:\n- improving the usability of Git  \n- fostering the Git community so that the project remains healthy in the long  \n  term\n\nThere always remains work to be done and we at GitLab are proud to be part  \nof these efforts to make sure that Git continues to be a great version control  \nsystem for the next 20 years.\n\n## Read more about Git\n\n- [Celebrating Git's 20th anniversary with creator Linus Torvalds](https://about.gitlab.com/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/)\n- [What's new in Git 2.49.0?](https://about.gitlab.com/blog/whats-new-in-git-2-49-0/)  \n- [What’s new in Git 2.48.0?](https://about.gitlab.com/blog/whats-new-in-git-2-48-0/)  \n- [A beginner's guide to the Git reftable format](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/)",[675,699],{"slug":723,"featured":92,"template":679},"journey-through-gits-20-year-history","content:en-us:blog:journey-through-gits-20-year-history.yml","Journey Through Gits 20 Year History","en-us/blog/journey-through-gits-20-year-history.yml","en-us/blog/journey-through-gits-20-year-history",{"_path":729,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":730,"content":736,"config":741,"_id":743,"_type":16,"title":744,"_source":17,"_file":745,"_stem":746,"_extension":20},"/en-us/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"title":731,"description":732,"ogTitle":731,"ogDescription":732,"noIndex":6,"ogImage":733,"ogUrl":734,"ogSiteName":713,"ogType":714,"canonicalUrls":734,"schema":735},"Celebrating Git's 20th anniversary with creator Linus Torvalds","Discover the origins of the open-source version control system, why he handed over the reins a few months in, and what he thinks about adding new programming languages to Git.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662510/Blog/Hero%20Images/git-20-years-opt1.png","https://about.gitlab.com/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Celebrating Git's 20th anniversary with creator Linus Torvalds\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2025-04-07\",\n      }",{"title":731,"description":732,"authors":737,"heroImage":733,"date":738,"body":739,"category":14,"tags":740},[718],"2025-04-07","The Git version control system was first released on April 7, 2005, by the father of the Linux kernel, Linus Torvalds. To mark the 20th anniversary of this important project that is nowadays used by almost every single developer, I interviewed Linus about the history of Git, why he handed over maintainership of Git, and what he considers to be its most important milestones.\n\n**In 2005, you were already the maintainer of the thriving Linux kernel. Why did you decide to start a new version control system?**\n\nSo, I got into it from really despising version control.\n\nI had used the traditional version control systems (CVS/RCS/SCCS) both as an end user (i.e., tracking open source projects like [GCC](https://gcc.gnu.org/)) and as a developer (we used CVS at Transmeta for everything) and absolutely hated the experience with a passion.\n\n\u003Cimg src=\"https://about.gitlab.com/images/blogimages/linustorvalds.png\" align=\"left\" width=\"200px\" style=\"padding-right: 20px; padding-bottom: 10px\"/>\n\nAnd yes, back then most projects that used CVS had probably moved to [SVN](https://subversion.apache.org/), but honestly, I always felt that SVN was just \"lipstick on a pig.\" It was just CVS in another form, with some UI improvements, but none of the fundamentals fixed, and a few new problems added.\n\nThe problems with CVS and its ilk are too many to even list, and, happily, they have largely become irrelevant and younger developers have probably never even had to deal with any of it. I absolutely refused to deal with it for the kernel, even though a few subsystems (notably the networking side) were actually using CVS to track their code back in the '90s.\n\nAnyway, back then I lived in the Bay Area, and Larry McVoy, who I knew from other projects (mainly [lmbench](https://www.usenix.org/legacy/publications/library/proceedings/sd96/full_papers/mcvoy.pdf)), had started BitMover, which had a new version control model called BitKeeper, or BK, for short.\n\nBK wasn't open source, but Larry liked open source projects and really felt that the lack of version control was holding the kernel back. He wasn't wrong, but the traditional source code managers (SCMs) really didn't work for me at all. Larry spent some time showing me and David Miller (networking maintainer and existing CVS user) what BitKeeper could do.\n\nBK wasn't perfect, and it was based on Source Code Control System (SCCS) like so many other traditional SCMs were, and thus had the same broken \"history per file\" model that everybody else had, and that causes huge and fundamental issues with file renaming and deletion.\n\nBut BK also wasn't just that \"lipstick\" thing. It may have used SCCS at a low level, but on a higher level it fixed some really fundamental things, and did proper distributed development, and had a real global – not per-file – history that made merging code from different trees actually work.\n\nWith CVS, creating branches and merging them was something you had to plan and discuss with people, and were major events. With BK, every repository was a branch. We take that for granted now, and Git obviously took it much further by having many branches *per* repository, but even the much more limited BK model was really a big deal at the time.\n\nAgain, BK wasn't perfect. As mentioned, it did do per-file history, which really is a big fundamental problem that makes renaming and file merging simply not work reliably, and inevitably causes chaos and pain (for CVS people, think Attic, shudder). And it had some scalability issues, too, but those took a while to become more than a bit problematic.\n\nBut the biggest problem with BK was the licensing, and while over the years (we used BK from 2002 to 2005) a lot of kernel maintainers did end up switching over to it, it was always a bit of a friction point. And that friction came to a head in late 2004, and the use of BK for the kernel basically became untenable a few months later.\n\nI was in the situation that for three years I'd finally used source control that worked, and it really had solved a lot of problems. There was no way I was going back to the days before source control, but in the years we'd been using BK, nothing better had really come out of the open source community.\n\nSure, people knew that CVS and SVN didn't work well, and there were projects that tried alternate approaches, but some of those approaches were even worse (basically amounting to \"fancy patch tracking\"), or had some good ideas but in the process making up some entirely new horrible design mistakes ([Monotone](https://www.monotone.ca/)).\n\nSo, I looked around for a while, and decided that I didn't have any options – I had to write my own.\n\nNow, technically, it actually did take only a few days to make the first version of Git, and hey, it's all there in the Git commit history. It's easy enough to see how it goes from pretty much zero to being usable enough that I started applying patches from others a week later (and being actively used for the kernel a few days after that).\n\nBut that ignores the fact that I had been *thinking* about the problem for a while by then. Writing code is easy. Getting a good design is what matters. So there was a fair amount of background to those few days that is pretty important, and that part doesn't show up in the history.\n\nAnd hey, that first version was very, very rough, and didn't do a lot that was to come later. But you can definitely already see much of the core design in those first few days.\n\n**Can you give us a short recount of the first days and weeks of how the Git project was started?**\n\nI had basically decided that I will stop kernel development until I had an alternative that worked for me. The main goals were to be distributed and high performance, and be something you could absolutely rely on to catch any corruption.\n\nBut I really do want to stress that I wasn't interested in SCMs, per se. I was interested in the end result, not in the process. So Git was never like the kernel for me: I do Linux because I think kernels are interesting - I did Git because I had to.\n\nWhich then directly segues into your next question.\n\n**You handed over the maintainership of Git to Junio Hamano after a couple of months, and Junio is still the maintainer. Why did you hand over maintainership and what made you pick Junio?**\n\nHanding over maintainership was not a hard choice. It was very much: \"The moment somebody else comes along that I can trust to keep it going, I'll go back to doing just the kernel.\"\n\nWhich is not to say that I just threw things over the wall and prayed for the best. I ended up maintaining Git for something like four months because I felt I needed to find somebody who would stick around, and had that hard-to-explain quality of \"GoodTaste\"(TM).\n\nJunio had been one of the very early people involved (he literally showed up the first week of development), but it's not like I just said, \"Tag, you're it.\"  It takes a while to see who sticks around, and who writes code and makes decisions that make sense.\n\nAnd I think Junio has been exemplary. I get much too much credit for the few months I spent on Git - particularly in light of the 20th anniversary. I'll take credit for getting the core design right, and getting the project started, but it really is Junio who has led the project (not to belittle the hundreds of other people involved, but still).\n\n**The initial version of the Mercurial version control system was released only 12 days after the initial version of Git, on April 19, 2005. Many people claim that Mercurial's user experience was superior over Git's, but nowadays Git is significantly more popular. Why do you think that Git has won over Mercurial?**\n\nOh, a big part of it is obviously just network effects, and SCMs have very strong network effects. It's why CVS survived as long as it did despite its limitations.\n\nSo, the fact that the kernel used Git (and then at some point it got to be very popular in the Ruby on Rails community, and then it took off everywhere).\n\nBut I really do think that the design of Git is superior. The core model is both very simple and very powerful, and I think that made it easier to translate into other environments. JGit was an early example of that, but you obviously have implementations like the MSgit virtual filesystem, etc.\n\nAnd while Git was famously somewhat hard to use early on, I really do think that some of that comes from having done things \"right,\" where people coming from other environments found Git non-intuitive because Git really did a few hard decisions that a traditional SCM person would never have done.\n\n**The Git project has not stood still since you handed maintainership over to Junio, and its community is always busy working on new features. What do you think the most important milestones were after you have left the project?**\n\nThat's really hard for me to say, mainly because I obviously made Git work for me, and so the things *I* use have worked from pretty much Day One. Just as an obvious example: Making Git work on Windows was obviously a huge step for other people, but it affected *me* not at all ;)\n\nThere's obviously all the infrastructure within Git itself to make it a lot easier to use, but I think most of the big milestones have all been around people taking the Git infrastructure and building things around it. Those often end up feeding back into Git features, of course, but, at the same time, the milestone is about something external.\n\nTo give an obvious example: All the big Git hosting sites were big milestones. Making Git be distributed was what made those so much easier to do, but the *milestone* was how then the hosting made it so easy for users to use Git for various projects.\n\n**If you had the capacity to work on Git full time again, would there be anything that you would like to implement?**\n\nAbsolutely not. Git did everything I really needed from very early on – my use is actually fairly limited, and I only really care about one project.\n\nAnd I say \"absolutely not\" because I refer you to that earlier answer: I was never really interested in SCMs at all to begin with. I think a large reason for why Git ended up being so different - mostly in good ways - from other SCMs was that I approached it more like I would a distributed journaling filesystem, not really a traditional SCM.\n\n**Is there any feature or design decision in Git that you have come to regret in retrospect?**\n\nDesign decisions? No. I still think the high-level design is just very good, and you can discuss various Git concepts without ever getting into the nitty-gritty complexity of actual implementation.\n\nAnd I think that's important in a project. You need a certain high-level design principle to guide the conceptual direction of a project.\n\nSometimes people take that too far, and think that the high-level design means that the implementation must then slavishly follow some core principle. And that's wrong, too – the *implementation* will have lots of nasty corner cases because reality is hard and people want odd things, but there needs to be some kind of top-level design that you can point to and reason about at a high level before you get your hands dirty with the nasty reality.\n\nAnd I think Git has a good balance of that. A very straightforward object store design (call them \"structured Merkle trees\" if you are a CS person, or you might just think of them as a \"content addressable storage\" if you are a filesystem person). That core design is there – but at the same time, it's realistically just a very tiny part of the actual code. Most of the *code* is about all the things you can do with the core design, but that basic clarity of design still gives the project some kind of high-level structure.\n\nIt's the same kind of high-level structure that Unix itself had, whether you said \"everything is a file\" or you were talking about process handling. There are a few \"concepts\" that drive the design, but then 99% of the code is about the ugly harsh details of what you build on top of that to make it all useful in the real world.\n\nI have two mantras in technology: \"If I have seen further, it is by standing on the shoulders of giants\" (Newton) and \"Genius is 1% inspiration and 99% perspiration\" (Edison).\n\nBut talking about the 99% perspiration: While I am very happy with the big design, there are certainly various details that I would have done differently if I were to do Git today.\n\nBut honestly, they aren't that important. What's much more important is all the *good* details that have been done over the last two decades.\n\n**The Linux kernel has started to use Rust as a programming language for some of its subsystems. Do you think it makes sense to start using such newer programming languages like this in Git?**\n\nI suspect that when it comes to Git, there's less reason to try to mix languages, which is always somewhat painful.\n\nIn the kernel, the end result is one single kernel binary – even if much of it can be loaded dynamically as modules, it is still linked together into effectively one single binary.\n\nAnd that makes using multiple languages more complex. But, on the other hand, the kernel also has more reason to worry about memory safety and, thus, look at newer languages.\n\nIn Git, if somebody wants to write parts of it in Rust or another language, I suspect it makes much more sense to just go for a separate implementation rather than try to mix languages in one binary.\n\nMuch of the Git core ideas are simple enough that just having parallel implementations of the core likely isn't too painful, and then you can target particular problem spaces where a different language makes more sense.\n\nAnd we've seen that in Git already, of course: That's exactly what JGit is. The use of a different language was due to a different web-based environment where that language choice was much more natural.\n\nI know that there are already Rust implementations of some of the core Git functionality, and I think the situation is similar: I suspect they make more sense in specific situations than in some kind of overall \"let's convert things to Rust\" kind of way.\n\nSo for anybody who is interested in implementing things in Rust, I'd suggest looking for target areas where the advantages of Rust are more obvious. I don't think C has actually been all that problematic in the standard Git source base.\n\n**New version control systems are popping up every couple of years. Do you think that Git will stay relevant in the future?**\n\nI already mentioned the network effects in SCMs, and I think that means that to replace Git you have to be not just slightly better, you have to be enormously better. Or so compatible that you effectively are just a new implementation of Git.\n\nAnd I do think the SCM situation has changed – Git doesn't have the kinds of huge gaping fundamental problems that SCMs had before Git. So being \"enormously better\" is fairly hard.\n\nSo, yes, I would expect Git to stay relevant for the foreseeable future, with people working on improvements *around* Git rather than replacements.\n\n*Note: This interview has been edited for length and clarity.*\n\n> Take a [journey with us through Git's 20-year history](https://about.gitlab.com/blog/journey-through-gits-20-year-history/).\n\n## Learn more about Git\n\n- [What's new in Git 2.49.0?](https://about.gitlab.com/blog/whats-new-in-git-2-49-0/)  \n- [What’s new in Git 2.48.0?](https://about.gitlab.com/blog/whats-new-in-git-2-48-0/)  \n- [A beginner's guide to the Git reftable format](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/)\n- [Git project](https://git-scm.com/)",[675,699],{"slug":742,"featured":92,"template":679},"celebrating-gits-20th-anniversary-with-creator-linus-torvalds","content:en-us:blog:celebrating-gits-20th-anniversary-with-creator-linus-torvalds.yml","Celebrating Gits 20th Anniversary With Creator Linus Torvalds","en-us/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds.yml","en-us/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"_path":748,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":749,"content":754,"config":760,"_id":762,"_type":16,"title":763,"_source":17,"_file":764,"_stem":765,"_extension":20},"/en-us/blog/whats-new-in-git-2-49-0",{"title":750,"description":751,"ogTitle":750,"ogDescription":751,"noIndex":6,"ogImage":695,"ogUrl":752,"ogSiteName":713,"ogType":714,"canonicalUrls":752,"schema":753},"What's new in Git 2.49.0?","Learn about the latest version of Git, including improved performance thanks to zlib-ng, a new name-hashing algorithm, and git-backfill(1).","https://about.gitlab.com/blog/whats-new-in-git-2-49-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What's new in Git 2.49.0?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Toon Claes\"}],\n        \"datePublished\": \"2025-03-14\",\n      }",{"title":750,"description":751,"authors":755,"heroImage":695,"date":757,"body":758,"category":14,"tags":759},[756],"Toon Claes","2025-03-14","The Git project recently released [Git 2.49.0](https://lore.kernel.org/git/xmqqfrjfilc8.fsf@gitster.g/). Let's look at a few notable highlights from this release, which includes contributions from GitLab's Git team and the wider Git community.\n\nWhat's covered:\n- [git-backfill(1) and the new path-walk API](#git-backfill(1)-and-the-new-path-walk-api)\n- [Introduction of zlib-ng](#introduction-of-zlib-ng)\n- [Continued iteration on Meson](#continued-iteration-on-meson)\n- [Deprecation of .git/branches/ and .git/remotes/](#deprecation-of-.gitbranches%2F-and-.git%2Fremotes%2F)\n- [Rust bindings for libgit](#rust-bindings-for-libgit)\n- [New name-hashing algorithm](#new-name-hashing-algorithm)\n- [Promisor remote capability](#promisor-remote-capability)\n- [Thin clone using `--revision`](#thin-clone-using---revision)\n\n## git-backfill(1) and the new path-walk API\n\nWhen you [`git-clone(1)`](https://git-scm.com/docs/git-clone) a Git repository,\nyou can pass it the\n[`--filter`](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt-code--filterltfilter-specgtcode)\noption. Using this option allows you to create a _partial clone_. In a partial\nclone the server only sends a subset of reachable objects according to the given\nobject filter. For example, creating a clone with `--filter=blob:none` will not\nfetch any blobs (file contents) from the server and create a _blobless clone_.\n\nBlobless clones have all the reachable commits and trees, but no blobs. When you\nperform an operation like\n[`git-checkout(1)`](https://git-scm.com/docs/git-checkout), Git will download\nthe missing blobs to complete that operation. For some operations, like\n[`git-blame(1)`](https://git-scm.com/docs/git-blame), this might result in\ndownloading objects one by one, which will slow down the command drastically.\nThis performance degradation occurs because `git-blame(1)` must traverse the\ncommit history to identify which specific blobs it needs, then request each\nmissing blob from the server separately.\n\nIn Git 2.49, a new subcommand `git-backfill(1)` is introduced, which can be\nused to download missing blobs in a blobless partial clone.\n\nUnder the hood, the `git-backfill(1)` command leverages the new path-walk API, which is different from how Git generally iterates over commits. Rather than iterating over the commits one at a time and recursively visiting the trees and blobs associated with each commit, the path-walk API does traversal by path. For each path, it adds a list of associated tree objects to a stack. This stack is then processed in a depth-first order. So, instead of processing every object in commit `1` before moving to commit `2`, it will process all versions of file `A` across all commits before moving to file `B`. This approach greatly improves performance in scenarios where grouping by path is essential.\n\nLet me demonstrate its use by making a blobless clone of [`gitlab-org/git`](https://gitlab.com/gitlab-org/git):\n\n```shell\n$ git clone --filter=blob:none --bare --no-tags git@gitlab.com:gitlab-org/git.git\nCloning into bare repository 'git.git'...\nremote: Enumerating objects: 245904, done.\nremote: Counting objects: 100% (1736/1736), done.\nremote: Compressing objects: 100% (276/276), done.\nremote: Total 245904 (delta 1591), reused 1547 (delta 1459), pack-reused 244168 (from 1)\nReceiving objects: 100% (245904/245904), 59.35 MiB | 15.96 MiB/s, done.\nResolving deltas: 100% (161482/161482), done.\n```\n\nAbove, we use `--bare` to ensure Git doesn't need to download any blobs to check\nout an initial branch. We can verify this clone does not contain any blobs:\n\n```sh\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort | uniq -c\n  83977 commit\n 161927 tree\n```\n\nIf you want to see the contents of a file in the repository, Git has to download it:\n\n```sh\n$ git cat-file -p HEAD:README.md\nremote: Enumerating objects: 1, done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 1 (from 1)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\n\n[![Build status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.com/git/git/actions?query=branch%3Amaster+event%3Apush)\n\nGit - fast, scalable, distributed revision control system\n=========================================================\n\nGit is a fast, scalable, distributed revision control system with an\nunusually rich command set that provides both high-level operations\nand full access to internals.\n\n[snip]\n```\n\nAs you can see above, Git first talks to the remote repository to download the blob before\nit can display it.\n\nWhen you would like to `git-blame(1)` that file, it needs to download a lot\nmore:\n\n```sh\n$ git blame HEAD README.md\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\n\n[snip]\n\ndf7375d772 README.md (Ævar Arnfjörð Bjarmason 2021-11-23 17:29:09 +0100  1) [![Build status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.com/git/git/actions?query=branch%3Amaster+event%3Apush)\n5f7864663b README.md (Johannes Schindelin \t2019-01-29 06:19:32 -0800  2)\n28513c4f56 README.md (Matthieu Moy        \t2016-02-25 09:37:29 +0100  3) Git - fast, scalable, distributed revision control system\n28513c4f56 README.md (Matthieu Moy        \t2016-02-25 09:37:29 +0100  4) =========================================================\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  5)\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  6) Git is a fast, scalable, distributed revision control system with an\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  7) unusually rich command set that provides both high-level operations\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  8) and full access to internals.\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  9)\n\n[snip]\n```\n\nWe've truncated the output, but as you can see, Git goes to the server for each\nrevision of that file separately. That's really inefficient. With\n`git-backfill(1)` we can ask Git to download all blobs:\n\n```shell\n$ git backfill\nremote: Enumerating objects: 50711, done.\nremote: Counting objects: 100% (15438/15438), done.\nremote: Compressing objects: 100% (708/708), done.\nremote: Total 50711 (delta 15154), reused 14730 (delta 14730), pack-reused 35273 (from 1)\nReceiving objects: 100% (50711/50711), 11.62 MiB | 12.28 MiB/s, done.\nResolving deltas: 100% (49154/49154), done.\nremote: Enumerating objects: 50017, done.\nremote: Counting objects: 100% (10826/10826), done.\nremote: Compressing objects: 100% (634/634), done.\nremote: Total 50017 (delta 10580), reused 10192 (delta 10192), pack-reused 39191 (from 1)\nReceiving objects: 100% (50017/50017), 12.17 MiB | 12.33 MiB/s, done.\nResolving deltas: 100% (48301/48301), done.\nremote: Enumerating objects: 47303, done.\nremote: Counting objects: 100% (7311/7311), done.\nremote: Compressing objects: 100% (618/618), done.\nremote: Total 47303 (delta 7021), reused 6693 (delta 6693), pack-reused 39992 (from 1)\nReceiving objects: 100% (47303/47303), 40.84 MiB | 15.26 MiB/s, done.\nResolving deltas: 100% (43788/43788), done.\n```\n\nThis backfills all blobs, turning the blobless clone into a full clone:\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort | uniq -c\n 148031 blob\n  83977 commit\n 161927 tree\n```\n\nThis [project](https://lore.kernel.org/git/pull.1820.v3.git.1738602667.gitgitgadget@gmail.com/)\nwas led by [Derrick Stolee](https://stolee.dev/) and was merged with\n[e565f37553](https://gitlab.com/gitlab-org/git/-/commit/e565f3755342caf1d21e22359eaf09ec11d8c0ae).\n\n## Introduction of zlib-ng\n\nAll objects in the `.git/` folder are compressed by Git using [`zlib`](https://zlib.net/). `zlib` is the reference implementation for the [RFC\n1950](https://datatracker.ietf.org/doc/html/rfc1950): ZLIB Compressed Data\nFormat. Created in 1995, `zlib` has a long history and is incredibly\nportable, even supporting many systems that predate the Internet. Because of its\nwide support of architectures and compilers, it has limitations in what it is\ncapable of.\n\nThe fork [`zlib-ng`](https://github.com/zlib-ng/zlib-ng) was created to\naccommodate the limitations. `zlib-ng` aims to be optimized for modern\nsystems. This fork drops support for legacy systems and instead brings in\npatches for Intel optimizations, some Cloudflare optimizations, and a couple\nother smaller patches.\n\nThe `zlib-ng` library itself provides a compatibility layer for `zlib`. The\ncompatibility later allows `zlib-ng` to be a drop-in replacement for `zlib`, but\nthat layer is not available on all Linux distributions. In Git 2.49:\n\n- A compatibility layer was added to the Git project.\n- Build options were added to both to the [`Makefile`](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/Makefile#L186-187)\n  and [Meson Build file](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/meson.build#L795-811).\n\nThese additions make it easier to benefit from the performance improvements of\n`zlib-ng`.\n\nIn local benchmarks, we've seen a ~25% speedup when using `zlib-ng` instead of `zlib`. And we're in the process of rolling out these changes to\nGitLab.com, too.\n\nIf you want to benefit from the gains of `zlib-ng`, first verify if Git\non your machine is already using `zlib-ng` by running\n`git version --build-options`:\n\n```shell\n$ git version --build-options\ngit version 2.47.1\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nlibcurl: 8.6.0\nOpenSSL: OpenSSL 3.2.2 4 Jun 2024\nzlib: 1.3.1.zlib-ng\n```\n\nIf the last line includes `zlib-ng` then your Git is already built\nusing the faster `zlib` variant. If not, you can either:\n\n- Ask the maintainer of the Git package you are using to include `zlib-ng` support.\n- Build Git yourself from source.\n\nThese [changes](https://gitlab.com/gitlab-org/git/-/commit/9d0e81e2ae3bd7f6d8a655be53c2396d7af3d2b0)\nwere [introduced](https://lore.kernel.org/git/20250128-b4-pks-compat-drop-uncompress2-v4-0-129bc36ae8f5@pks.im/)\nby [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Continued iteration on Meson\n\nIn our article about the Git 2.48 release,\nwe touched on [the introduction of the Meson build system](https://about.gitlab.com/blog/whats-new-in-git-2-48-0/#meson-build-system). [Meson](https://en.wikipedia.org/wiki/Meson_(software)) is\na build automation tool used by the Git project that at some point might replace [Autoconf](https://en.wikipedia.org/wiki/Autoconf),\n[CMake](https://en.wikipedia.org/wiki/CMake), and maybe even\n[Make](https://en.wikipedia.org/wiki/Make_(software)).\n\nDuring this release cycle, work continued on using Meson, adding various missing\nfeatures and stabilization fixes:\n\n  - [Improved test coverage for\n\tCI](https://lore.kernel.org/git/20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im/)\n\twas merged in\n\t[72f1ddfbc9](https://gitlab.com/gitlab-org/git/-/commit/72f1ddfbc95b47c6011bb423e6947418d1d72709).\n  - [Bits and pieces to use Meson in `contrib/`](https://lore.kernel.org/git/20250219-b4-pks-meson-contrib-v2-0-1ba5d7fde0b9@pks.im/)\n\twere merged in\n\t[2a1530a953](https://gitlab.com/gitlab-org/git/-/commit/2a1530a953cc4d2ae62416db86c545c7ccb73ace).\n  - [Assorted fixes and improvements to the build procedure based on\n\tmeson](https://lore.kernel.org/git/20250226-b4-pks-meson-improvements-v3-0-60c77cf673ae@pks.im/)\n\twere merged in\n\t[ab09eddf60](https://gitlab.com/gitlab-org/git/-/commit/ab09eddf601501290b5c719574fbe6c02314631f).\n  - [Making Meson aware of building\n\t`git-subtree(1)`](https://lore.kernel.org/git/20250117-b4-pks-build-subtree-v1-0-03c2ed6cc42e@pks.im/)\n\twas merged in\n\t[3ddeb7f337](https://gitlab.com/gitlab-org/git/-/commit/3ddeb7f3373ae0e309d9df62ada24375afa456c7).\n  - [Learn Meson to generate HTML documentation\n\tpages](https://lore.kernel.org/git/20241227-b4-pks-meson-docs-v2-0-f61e63edbfa1@pks.im/)\n\twas merged in\n\t[1b4e9a5f8b](https://gitlab.com/gitlab-org/git/-/commit/1b4e9a5f8b5f048972c21fe8acafe0404096f694).\n\nAll these efforts were carried out by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Deprecation of .git/branches/ and .git/remotes/\n\nYou are probably aware of the existence of the `.git` directory, and what is\ninside. But have you ever heard about the sub-directories `.git/branches/` and\n`.git/remotes/`? As you might know, reference to branches are stored in\n`.git/refs/heads/`, so that's not what `.git/branches/` is for, and what about\n`.git/remotes/`?\n\nWay back in 2005, [`.git/branches/`](https://git-scm.com/docs/git-fetch#_named_file_in_git_dirbranches)\nwas introduced to store a shorthand name for a remote, and a few months later they were\nmoved to [`.git/remotes/`](https://git-scm.com/docs/git-fetch#_named_file_in_git_dirremotes).\nIn [2006](https://lore.kernel.org/git/Pine.LNX.4.63.0604301520460.2646@wbgn013.biozentrum.uni-wuerzburg.de/),\n[`git-config(1)`](https://git-scm.com/docs/git-config) learned to store\n[remotes](https://git-scm.com/docs/git-config#Documentation/git-config.txt-remoteltnamegturl).\nThis has become the standard way to configure remotes and, in 2011, the\ndirectories `.git/branches/` and `.git/remotes/` were\n[documented](https://gitlab.com/git-scm/git/-/commit/3d3d282146e13f2d7f055ad056956fd8e5d7ed29#e615263aaf131d42be8b0d0888ebd3fec954c6c9_132_124)\nas being \"legacy\" and no longer used in modern repositories.\n\nIn 2024, the document [BreakingChanges](https://git-scm.com/docs/BreakingChanges)\nwas started to outline breaking changes for the next major version of Git\n(v3.0). While this release is not planned to happen any time soon, this document\nkeeps track of changes that are expected to be part of that release.\nIn [8ccc75c245](https://gitlab.com/git-scm/git/-/commit/8ccc75c2452b5814d2445d60d54266293ca48674),\nthe use of the directories `.git/branches/` and `.git/remotes/` was added to\nthis document and that officially marks as them deprecated and to be removed in\nGit 3.0.\n\nThanks to [Patrick Steinhardt](https://gitlab.com/pks-gitlab) for\n[formalizing this deprecation](https://lore.kernel.org/git/20250122-pks-remote-branches-deprecation-v4-5-5cbf5b28afd5@pks.im/).\n\n## Rust bindings for libgit\n\nWhen compiling Git, an internal library `libgit.a` is made. This library\ncontains some of the core functionality of Git.\n\nWhile this library (and most of Git) is written in C, in Git 2.49 bindings were\nadded to make some of these functions available in Rust. To achieve this, two\nnew Cargo packages were created: `libgit-sys` and `libgit-rs`. These packages\nlive in the [`contrib/`](https://gitlab.com/gitlab-org/git/-/tree/master/contrib) subdirectory in the Git source tree.\n\nIt's pretty\n[common](https://doc.rust-lang.org/cargo/reference/build-scripts.html#-sys-packages)\nto split out a library into two packages when a [Foreign Function\nInterface](https://en.wikipedia.org/wiki/Foreign_function_interface) is used.\nThe `libgit-sys` package provides the pure interface to C functions and links to\nthe native `libgit.a` library. The package `libgit-rs` provides a high-level\ninterface to the functions in `libgit-sys` with a feel that is more idiomatic to\nRust.\n\nSo far, the functionality in these Rust packages is very limited. It only\nprovides an interface to interact with the `git-config(1)`.\n\nThis initiative was led by [Josh Steadmon](https://lore.kernel.org/git/8793ff64a7f6c4c04dd03b71162a85849feda944.1738187176.git.steadmon@google.com/) and was merged with [a4af0b6288](https://gitlab.com/gitlab-org/git/-/commit/a4af0b6288e25eb327ae9018cee09def9e43f1cd).\n\n## New name-hashing algorithm\n\nThe Git object database in `.git/` stores most of its data in packfiles. And\npackfiles are also used to submit objects between Git server and client over the\nwire.\n\nYou can read all about the format at\n[`gitformat-pack(5)`](https://git-scm.com/docs/gitformat-pack). One important\naspect of the packfiles is delta-compression. With delta-compression not every\nobject is stored as-is, but some objects are saved as a _delta_ of another\n_base_. So instead of saving the full contents of the objects, changes compared\nto another object are stored.\n\nWithout going into the details how these deltas are calculated or stored, you\ncan imagine that it is important group files together that are very similar. In\nv2.48 and earlier, Git looked at the last 16 characters of the path name to\ndetermine whether blobs might be similar. This algorithm is named version `1`.\n\nIn Git 2.49, version `2` is available. This is an iteration on version `1`, but\nmodified so the effect of the parent directory is reduced. You can specify the\nname-hash algorithm version you want to use with option `--name-hash-version` of\n[`git-repack(1)`](https://git-scm.com/docs/git-repack).\n\n[Derrick Stolee](https://stolee.dev/), who drove this project, did some\ncomparison in resulting packfile size after running `git repack -adf\n--name-hash-version=\u003Cn>`:\n\n| Repo                                          \t| Version 1 size   | Version 2 size |\n|---------------------------------------------------|-----------|---------|\n| [fluentui](https://github.com/microsoft/fluentui) | 440 MB \t| 161 MB   |\n| Repo B                                        \t| 6,248 MB   | 856 MB   |\n| Repo C                                        \t| 37,278 MB  | 6,921 MB |\n| Repo D                                        \t| 131,204 MB | 7,463 MB |\n\nYou can read more of the details in the [patch\nset](https://lore.kernel.org/git/pull.1823.v4.git.1738004554.gitgitgadget@gmail.com/),\nwhich is merged in\n[aae91a86fb](https://gitlab.com/gitlab-org/git/-/commit/aae91a86fb2a71ff89a71b63ccec3a947b26ca51).\n\n## Promisor remote capability\n\nIt's known that Git isn't great in dealing with large files. There are some\nsolutions to this problem, like [Git LFS](https://git-lfs.com/), but there are\nstill some shortcomings. To give a few:\n\n- With Git LFS the user has to configure which files to put in LFS. The server has\n  no control about that and has to serve all files.\n- Whenever a file is committed to the repository, there is no way to get it out\n  again without rewriting history. This is annoying, especially for large files,\n  because they are stuck for eternity.\n- Users cannot change their mind on which files to put into Git LFS.\n- A tool like Git LFS requires significant effort to set up, learn, and use\n  correctly.\n\nFor some time, Git has had the concept of promisor remotes. This feature can be used to deal with large files, and in Git 2.49 this feature took a step forward.\n\nThe idea for the new “promisor-remote” capability is relatively simple: Instead of sending all\nobjects itself, a Git server can tell to the Git client \"Hey, go download these\nobjects from _XYZ_\". _XYZ_ would be a promisor remote.\n\nGit 2.49 enables the server to advertise the information of the promisor remote\nto the client. This change is an extension to\n[`gitprotocol-v2`](https://git-scm.com/docs/gitprotocol-v2). While the server\nand the client are transmitting data to each other, the server can send  names and URLs of the promisor remotes it knows\nabout.\n\nSo far, the client is not using the promisor remote info it gets from the server during clone, so all\nobjects are still transmitted from the remote the clone initiated from. We are planning to continue work on this feature, making it use promisor remote info from the server, and making it easier to use.\n\nThis [patch\nset](https://lore.kernel.org/git/20250218113204.2847463-1-christian.couder@gmail.com/)\nwas submitted by [Christian Couder](https://gitlab.com/chriscool) and merged\nwith\n[2c6fd30198](https://gitlab.com/gitlab-org/git/-/commit/2c6fd30198187c928cbf927802556908c381799c).\n\n## Thin clone using `--revision`\n\nA new `--revision` option was added to\n[`git-clone(1)`](https://git-scm.com/docs/git-clone). This enables you to create\na thin clone of a repository that only contains the history of the given\nrevision. The option is similar to `--branch`, but accepts a ref name (like\n`refs/heads/main`, `refs/tags/v1.0`, and `refs/merge-requests/123`) or a\nhexadecimal commit object ID. The difference to `--branch` is that it does not\ncreate a tracking branch and detaches `HEAD`. This means it's not suited if you\nwant to contribute back to that branch.\n\nYou can use `--revision` in combination with `--depth` to create a very minimal\nclone. A suggested use-case is for automated testing. When you have a CI system\nthat needs to check out a branch (or any reference) to perform autonomous\ntesting on the source code, having a minimal clone is all you need.\n\nThis\n[change](https://gitlab.com/gitlab-org/git/-/commit/5785d9143bcb3ef19452a83bc2e870ff3d5ed95a)\nwas\n[driven](https://lore.kernel.org/git/20250206-toon-clone-refs-v7-0-4622b7392202@iotcl.com/)\nby [Toon Claes](https://gitlab.com/toon).\n\n# Read more\n- [What’s new in Git 2.48.0?](https://about.gitlab.com/blog/whats-new-in-git-2-48-0/)\n- [What’s new in Git 2.47.0?](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/)\n- [What’s new in Git 2.46.0?](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/)",[268,675,699],{"slug":761,"featured":92,"template":679},"whats-new-in-git-2-49-0","content:en-us:blog:whats-new-in-git-2-49-0.yml","Whats New In Git 2 49 0","en-us/blog/whats-new-in-git-2-49-0.yml","en-us/blog/whats-new-in-git-2-49-0",{"_path":767,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":768,"content":774,"config":782,"_id":784,"_type":16,"title":785,"_source":17,"_file":786,"_stem":787,"_extension":20},"/en-us/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"title":769,"description":770,"ogTitle":769,"ogDescription":770,"noIndex":6,"ogImage":771,"ogUrl":772,"ogSiteName":713,"ogType":714,"canonicalUrls":772,"schema":773},"How to use OCI images as the source of truth for continuous delivery","Discover the benefits of using Open Container Initiative images as part of GitOps workflows and the many features GitLab offers to simplify deployments to Kubernetes.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097601/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20Use%20this%20page%20as%20a%20reference%20for%20thumbnail%20sizes_76Tn5jFmEHY5LFj8RdDjNY_1750097600692.png","https://about.gitlab.com/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to use OCI images as the source of truth for continuous delivery\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daniel Helfand\"}],\n        \"datePublished\": \"2025-02-19\",\n      }",{"title":769,"description":770,"authors":775,"heroImage":771,"date":777,"body":778,"category":14,"tags":779},[776],"Daniel Helfand","2025-02-19","Is [GitOps](https://about.gitlab.com/topics/gitops/) still GitOps if you are not using a git repository as your deployment artifact? While git remains central to GitOps workflows, storing infrastructure definitions as Open Container Initiative (OCI) artifacts in container registries has seen a rise in adoption as the source for GitOps deployments. In this article, we will dive deeper into the ideas behind this trend and how GitLab features support this enhancement to GitOps workflows.\n\n## What is GitOps?\n\nThe [OpenGitOps](https://opengitops.dev/) project has defined [four principles](https://opengitops.dev/#principles) for the practice of GitOps:\n- A [system managed by GitOps](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#software-system) must have its [desired state expressed declaratively](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#declarative-description).\n- Desired state is stored in a way that enforces immutability and versioning, and retains a complete version history.\n- Software agents automatically pull the desired state declarations from the source.\n- Software agents [continuously](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#continuous) observe actual system state and [attempt to apply the desired state](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#reconciliation).\n\nAn example of GitOps is storing the Kubernetes manifests for a microservice in a GitLab project. Those Kubernetes resources are then continuously reconciled by a [controller](https://kubernetes.io/docs/concepts/architecture/controller/) running on the Kubernetes cluster where the microservice is deployed to. This allows engineers to manage infrastructure using the same workflows as working with regular code, such as opening merge requests to make and review changes and versioning changes. GitOps also has operational benefits such as [preventing configuration drift](https://about.gitlab.com/topics/gitops/#cicd) and helps engineers audit what changes led to certain outcomes with deployments.\n\n## Benefits and limitations of git in GitOps workflows\n\nWhile git is an essential piece of GitOps workflows, git repositories were not designed to be deployed by GitOps controllers. Git does provide the ability for engineers to collaborate on infrastructure changes and audit these changes later on, but controllers do not need to download an entire git repository for a successful deployment. GitOps controllers simply need the infrastructure defined for a particular environment.\n\nAdditionally, an important piece of the deployment process is to [sign and verify deployments](https://docs.sigstore.dev/about/overview/#why-cryptographic-signing) to assure deployment changes to an environment are coming from a trusted source. While git commits can be signed and verified by GitOps controllers, commits may also capture other details not related to the deployment itself (e.g., documentation changes, updates to other environments, and git repository restructuring) or not enough of the deployment picture as a deployment may consist of multiple commits. This again feels like a case this git feature wasn’t designed for.\n\nAnother challenging aspect of git in GitOps workflows is that it can sometimes lead to more automation than expected. Soon after merging a change to the watched branch, it will be deployed. There are no controls in the process outside of git. How can you make sure that nothing gets deployed on a Friday late afternoon? What if teams responsible for deployment do not have permissions to merge changes in certain GitLab projects? Using OCI images adds a pipeline into the process, including all the delivery control features, like [approvals or deploy freezes](https://docs.gitlab.com/ee/ci/environments/protected_environments.html).\n\n## OCI images\n\nThe [Open Container Initiative](https://opencontainers.org/) has helped to define standards around container formats. While most engineers are familiar with building Dockerfiles into container images, many may not be as familiar with storing Kubernetes manifests in a container registry. Because [GitLab’s Container Registry](https://docs.gitlab.com/ee/user/packages/container_registry/) is OCI compliant, it allows for users to push Kubernetes manifests for a particular environment to a container registry. GitOps controllers, such as [Flux CD](https://about.gitlab.com/blog/why-did-we-choose-to-integrate-fluxcd-with-gitlab/), can use the manifests stored in this OCI artifact instead of needing to clone an entire git repository.\n\nOften in GitOps workflows, a git repository can include the infrastructure definitions for all environments that a microservice will be deployed to. By packaging the Kubernetes manifests for only a specific environment, Flux CD can download the minimum files needed to carry out a deployment to a specific environment.\n\n### Security benefits of using OCI artifacts\n\nAs mentioned previously, signing and verifying the artifacts to be deployed to an environment adds an additional layer of security for software projects. After Kubernetes manifests are pushed to a container registry, a tool like [Sigstore Cosign](https://docs.sigstore.dev/quickstart/quickstart-cosign/) can be used to sign the OCI image with a private key that can be securely stored in a GitLab project as a [CI/CD variable](https://docs.gitlab.com/ee/ci/variables/). Flux CD can then use a public key stored on a Kubernetes cluster to verify that a deployment is coming from a trusted source.\n\n## Using GitLab to push and sign OCI images\n\nGitLab offers many features that help simplify the process of packaging, signing, and deploying OCI images. A common way to structure GitLab projects with GitOps workflows is to have separate GitLab projects for microservices’ code and a single infrastructure repository for all microservices. If an application is composed of `n` microservices, this would require having `n +1` GitLab projects for an application.\n\nThe artifact produced by a code project is usually a container image that will be used to package the application. The infrastructure or delivery project will contain the Kubernetes manifests defining all the resources required to scale and serve traffic to each microservice. The artifact produced by this project is usually an OCI image used to deploy the application and other manifests to Kubernetes.\n\nIn this setup, separation of environments is handled by defining Kubernetes manifests in separate folders. These folders represent environments (e.g., development, staging, and production) that will host the application. When changes are made to the code project and a new container image is pushed, all that needs to be done to deploy these changes via GitLab’s integration with Flux CD is to edit the manifests under the environment folder to include the new image reference and open a merge request. Once that merge request is reviewed, approved, and merged, the delivery project’s CI/CD job will push a new OCI image that Flux CD will pick up and deploy to the new environment.\n\n![OCI images - flow chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097611/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097611046.png)\n\nSigning an OCI image is as simple as including Cosign in your project’s CI/CD job. You can simply generate a new public and private key with Cosign by running the commands below locally. Just make sure to log in to your GitLab instance with the [glab CLI](https://gitlab.com/gitlab-org/cli/#installation) and replace the [`PROJECT_ID`] for the Cosign command with your [delivery project’s ID](https://docs.gitlab.com/ee/user/project/working_with_projects.html#access-a-project-by-using-the-project-id).\n\n```\nglab auth login\ncosign generate-key-pair gitlab://[PROJECT_ID]\n```\n\nOnce the cosign command runs successfully, you can see the Cosign keys added to your project under the CI/CD variables section under the key names `COSIGN_PUBLIC_KEY` and `COSIGN_PRIVATE_KEY`.\n\n### Example CI/CD job\n\nA GitLab CI/CD job for pushing an OCI image will look something like the following:\n\n```yaml\nfrontend-deploy:\n  rules:\n  - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    changes:\n      paths:\n      - manifests/dev/frontend-dev.yaml\n  trigger:\n    include:\n      - component: gitlab.com/components/fluxcd/oci-artifact@0.3.1\n        inputs:\n          version: 0.3.1\n          kubernetes_agent_reference: gitlab-da/projects/tanuki-bank/flux-config:dev\n          registry_image_url: \"oci://$CI_REGISTRY_IMAGE/frontend\"\n          image_tag: dev\n          manifest_path: ./manifests/dev/frontend-dev.yaml\n          flux_oci_repo_name: frontend\n          flux_oci_namespace_name: frontend-dev\n          signing_private_key: \"$COSIGN_PRIVATE_KEY\"\n```\n\nThe [GitLab CI/CD Catalog](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) offers a GitLab-maintained [CI/CD component for working with OCI artifacts and Flux CD](https://gitlab.com/explore/catalog/components/fluxcd). This component allows development teams to push Kubernetes manifests as OCI images to GitLab’s Container Registry or an external container registry, sign the OCI image using Cosign, and immediately reconcile the newly pushed image via Flux CD.\n\nIn the example above, the Flux CD `component` is included in a `.gitlab-ci.yml` file of a GitLab project. Using the component’s `inputs`, users can define what registry to push the image to (i.e., `registry_image_url` and `image tag`), the file path to Kubernetes manifests that will be pushed (i.e., `manifest_path`), the cosign private key used to sign images (i.e., `signing_private_key`), and the Kubernetes namespace and Flux CD [OCIRepository](https://fluxcd.io/flux/components/source/ocirepositories/) name needed to sync updates to an environment (i.e., `flux_oci_namespace_name` and `flux_oci_repo_name`).\n\nThe `kubernetes_agent_reference` allows GitLab CI/CD jobs to inherit the `kubeconfig` needed to access a Kubernetes cluster without needing to store a `kubeconfig` CI/CD variable in each GitLab project. By setting up the [GitLab agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/), you can configure all GitLab projects’ CI/CD jobs in a [GitLab group](https://docs.gitlab.com/ee/user/group/) to inherit permissions to deploy to the Kubernetes cluster.\n\nThe agent for Kubernetes context is typically configured wherever you configure the GitLab Agent for Kubernetes in your GitLab group. It is typically recommended that this be done in the project where Flux CD is managed. More information on configuring the agent for CI/CD access can be found in our [CI/CD workflow documentation](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html).\n\nThe variables `$COSIGN_PRIVATE_KEY`, `$FLUX_OCI_REPO_NAME`, and `$FRONTEND_DEV_NAMESPACE` are values stored as CI/CD variables to easily access and mask these sensitive pieces of data in CI/CD logs. The `$CI_REGISTRY_IMAGE` is a variable that GitLab jobs have available by default that specifies the GitLab project’s container registry.\n\n### Deploy OCI images\n\nUsing [Flux CD with your GitLab projects](https://docs.gitlab.com/ee/user/clusters/agent/gitops/flux_tutorial.html), you can automate deployments and signing verification for your microservice’s environments. Once Flux CD is configured to sync from a GitLab project, you could add the following Kubernetes [custom resource definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) to your project to sync your pushed OCI image.\n\n```yaml\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: frontend-dev\n  labels:\n    name: frontend-dev\n---\napiVersion: bitnami.com/v1alpha1\nkind: SealedSecret\nmetadata:\n  name: cosign-public-key\n  namespace: frontend-dev\nspec:\n  encryptedData:\n    cosign.pub: AgAKgLf4VbVzJOmr6++k81LlFayx88AELaUQFNOaXmBF4G+fBfBYeABl0skNvMAa1UrPVNSfMIHgFoYHoO96g576a+epk6V6glOI+++XvYbfsygof3GGxe0nL5Qh2b3ge0fNpyd0kTPSjTj0YUhRhKtMGMRSRw1jrwhNcGxCHK+Byibs52v8Np49KsIkeZKbzLdgYABkrv+k0j7hQM+jR180NpG+2UiRvaXpPuogxkbj61FEqWGrJHk8IVyfl3eh+YhoXxOHGDqko6SUC+bUZPDBlU6yKegO0/8Zq3hwulrSEsEjzRZNK+RFVMOLWWuC6h+WGpYhAMcsZPwjjJ/y29KLNa/YeqkN/cdk488QyEFc6ehCxzhH67HxIn2PDa+KkEOTv2TuycGF+Q00jKIizXF+IwLx/oRb3pTCF0AoAY8D8N3Ey+KfkOjsBON7gGID8GbQiJqX2IgIZxFMk0JRzxbRKOEqn+guLd5Shj7CD1a1Mkk0DxBdbqrGv2XNYUaFPI7xd3rZXUJZlnv+fsmwswsiGWRuXwim45HScWzQnfgLAe7tv3spVEGeaO5apl6d89uN21PBQnfE/zyugB//7ZW9tSp6+CSMyc5HynxI8diafqiwKPgvzLmVWRnkvxJijoXicRr3sCo5RudZPSlnjfd7CKdhwEVvLl7dRR4e/XBMdxCzk1p52Pl+3/kJR+LJii5+iwOpYrpVltSZdzc/3qRd19yMpc9PWpXYi7HxTb24EOQ25i21eDJY1ceplDN6bRtop2quzkjlwVeE2i4cEsX/YG8QBtQbop/3fjiAjKaED3QH3Ul0PECS9ARTScSkcOL3I00Xpp8DyD+xH0/i9wCBRDmH3yKX18C8VrMq02ALSnlP7WCVVjCPzubqKx2LPZRxK9EG0fylwv/vWQzTUUwfbPQZsd4c75bSTsTvxqp/UcFaXA==\n  template:\n    metadata:\n      name: cosign-public-key\n      namespace: frontend-dev\n---\napiVersion: source.toolkit.fluxcd.io/v1beta2\nkind: OCIRepository\nmetadata:\n    name: frontend\n    namespace: frontend-dev\nspec:\n    interval: 1m\n    url: oci://registry.gitlab.com/gitlab-da/projects/tanuki-bank/tanuki-bank-delivery/frontend\n    ref:\n        tag: dev\n    verify:\n      provider: cosign\n      secretRef:\n        name: cosign-public-key\n---\napiVersion: kustomize.toolkit.fluxcd.io/v1\nkind: Kustomization\nmetadata:\n    name: frontend\n    namespace: frontend-dev\nspec:\n    interval: 1m\n    targetNamespace: frontend-dev\n    path: \".\"\n    sourceRef:\n        kind: OCIRepository\n        name: frontend\n    prune: true\n```\n\nThe [`Kustomization`](https://fluxcd.io/flux/components/kustomize/kustomizations/) resource allows for further customization of Kubernetes manifests and also specifies which namespace to deploy resources to. The `OCIRepository` resource for Flux CD allows users to specify the OCI image repository reference and tag to regularly sync from. Additionally, you will notice the `verify.provider` and `verify.secretRef` properties. These fields allow you to verify that the OCI image deployed to the cluster was signed by the corresponding Cosign private key used in the earlier CI/CD job.\n\nThe public key needs to be stored in a [Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/) that will need to be present in the same namespace as the `OCIRepository` resource. To have this secret managed by Flux CD and not store the secret in plain text, you can consider using [SealedSecrets](https://fluxcd.io/flux/guides/sealed-secrets/) to encrypt the value and have it be decrypted cluster side by a controller.\n\nFor a simpler approach not requiring SealedSecrets, you can [deploy the secret via a GitLab CI/CD](https://docs.gitlab.com/ee/user/clusters/agent/getting_started_deployments.html) job using the [`kubectl CLI`](https://kubernetes.io/docs/reference/kubectl/). In the non-sealed secret approach, you would simply remove the SealedSecret included above and run the job to deploy the public key secret before running the job to push the new OCI image. This will make sure the secret is stored securely in GitLab and make sure the secret can be accessed on the cluster by the OCIRepository. While this approach is a bit simpler, just note this is not a suitable approach for managing secrets in production.\n\n## The benefits of OCI, GitLab, and GitOps\n\nOCI artifacts allow for GitOps teams to take deployments even further with added security benefits and allowing for deployments to be minimal. Users still gain all the benefits offered by git as far as having a source of truth for infrastructure and collaborating on projects. OCI images add a packaging approach that improves the deployment aspect of GitOps.\n\nGitLab continues to learn from our customers and the cloud native community on building experiences that help simplify GitOps workflows. To get started using some of the features mentioned in this blog, you can sign up for a [60-day free trial of GitLab Ultimate](https://about.gitlab.com/free-trial/). We would also love to hear from users about their experiences with these tools, and you can provide feedback in the [community forum](https://forum.gitlab.com/t/oci-images-as-source-of-truth-for-gitops-with-gitlab/120965).\n",[110,675,780,535,699,781],"kubernetes","tutorial",{"slug":783,"featured":6,"template":679},"how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","content:en-us:blog:how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery.yml","How To Use Oci Images As The Source Of Truth For Continuous Delivery","en-us/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery.yml","en-us/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"_path":789,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":790,"content":796,"config":802,"_id":804,"_type":16,"title":805,"_source":17,"_file":806,"_stem":807,"_extension":20},"/en-us/blog/whats-new-in-git-2-48-0",{"title":791,"description":792,"ogTitle":791,"ogDescription":792,"noIndex":6,"ogImage":793,"ogUrl":794,"ogSiteName":713,"ogType":714,"canonicalUrls":794,"schema":795},"What’s new in Git 2.48.0?","Learn about the latest version of Git, including a new build system and optimization in the new reftable backend. Discover contributions from GitLab's Git team and the Git community.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663691/Blog/Hero%20Images/AdobeStock_752438815.jpg","https://about.gitlab.com/blog/whats-new-in-git-2-48-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What’s new in Git 2.48.0?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christian Couder\"}],\n        \"datePublished\": \"2025-01-10\",\n      }",{"title":791,"description":792,"authors":797,"heroImage":793,"date":799,"body":800,"category":14,"tags":801},[798],"Christian Couder","2025-01-10","The Git project recently released [Git 2.48.0](https://lore.kernel.org/git/xmqqplku7cvm.fsf@gitster.g/). Let's look at a few notable highlights from this release, which includes contributions from GitLab's Git team and the wider Git community.\n\n## Meson build system\n\nFor a long time, Git could be built using either a [Makefile](https://en.wikipedia.org/wiki/GNU_Make)-based build system or an [Autoconf](https://en.wikipedia.org/wiki/Autoconf)-based build system. Git developers have been using mostly the Makefile-based build system, so\n[the Autoconf-based build system has lagged behind](https://lore.kernel.org/git/GV1PR02MB848925A79A9DD733848182D58D662@GV1PR02MB8489.eurprd02.prod.outlook.com/) in features and maintenance. Another issue was that a lot of Windows\ndevelopers use integrated development environments (IDEs) that don’t\nhave good support for Makefile- and Autoconf-based build systems.\n\nIn 2020, support for building Git using [CMake](https://cmake.org/) was added. CMake added better Windows support and IDE integration, especially for Visual\nStudio. Some modern build system features like out-of-source builds were also included.\n\nRecently, it appeared the CMake support was also lagging\nbehind and that it might never be a good option to replace the two other\nbuild systems. So [Patrick Steinhardt](https://gitlab.com/pks-gitlab), GitLab Git Engineering Manager, implemented support for the [Meson](https://mesonbuild.com/) build\nsystem with the goal of eventually replacing the Autoconf-, CMake-, and\nmaybe the Makefile-based build systems.\n\nThe new Meson-based build system has the following advantages:\n* Allows users to easily find the available build options, something which is difficult with Makefiles and CMake\n* Has a simple syntax compared to Autoconf and CMake\n* Supports many different operating systems, compilers, and IDEs\n* Supports modern build system features like out-of-source builds\n\nHere is an example of how it can actually be used to build Git:\n\n```shell\n$ cd git             \t# go into the root of Git's source code\n$ meson setup build/ \t# setup \"build\" as a build directory\n$ cd build           \t# go into the \"build\" directory\n$ meson compile      \t# actually build Git\n$ meson test         \t# test the new build\n$ meson install      \t# install the new build\n\n```\n\nMultiple build directories can be set up using `meson setup \u003Cbuild_dir>`, and the configuration of the build inside a build directory can be viewed or changed by running `meson configure` inside the build directory.\n\nMore information on how to build Git using Meson can be found at the top of the [`meson.build` file](https://gitlab.com/gitlab-org/git/-/blob/master/meson.build) in the Git code repository. A\n[comparison of the different build systems](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/technical/build-systems.txt) for Git is available as part of Git's technical documentation.\n\nThis project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Git is now memory-leak-free (as exercised by the test suite)\n\nIn our Git release blog post about the previous Git 2.47.0 release, we\ntalked about our [ongoing effort to fix all memory leaks](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/#code-refactoring-and-maintainability-improvements) surfaced by existing tests in the project. We said that prior to the Git 2.47.0 release, the project had 223 test files containing memory\nleaks, and that this had been whittled down to just 60.\n\nWe are pleased to report that the memory leaks in all 60 remaining test files have been resolved. As a result, Git, as exercised by the test suite, is now free of memory leaks. This is an important step towards the longstanding goal of “libifying” Git internal components (which means converting those components into internal libraries). It will also help with optimizing Git for memory usage.\n\nNow, any newly added test must be leak-free by default. It's still\npossible to have leaking tests, but the authors will have to use an\nescape hatch for that and provide good arguments why their test cannot\nbe made leak free.\n\nThis project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Improved bundle URI checks\n\nIn our Git release blog post about the Git 2.46.0 release, we talked\nabout some [bundle URI fixes](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/#bundle-uri-fixes)\nby [Xing Xin](https://lore.kernel.org/git/pull.1730.git.1715742069966.gitgitgadget@gmail.com/).\nAfter those fixes, Xing Xin worked on making it possible for [fetches using bundles to be fully checked](https://lore.kernel.org/git/pull.1730.v8.git.1718770053.gitgitgadget@gmail.com/)\nusing the [fsck](https://git-scm.com/docs/git-fsck) mechanism like regular fetches.\n\nWhen validating regular fetches, it's possible to specify\n[different severities](https://git-scm.com/docs/git-fsck#Documentation/git-fsck.txt-fsckltmsg-idgt) for [different fsck issues](https://git-scm.com/docs/git-fsck#_fsck_messages)\nto have fine-grained handling of what is accepted and what is rejected in a specific repository. This wasn't possible for fetches using bundles previously.\n\nTo further increase the usefulness and safety of [bundle-uri](https://git-scm.com/docs/bundle-uri), we [addressed this problem](https://lore.kernel.org/git/20241121204119.1440773-1-jltobler@gmail.com/) so that the different severities specified for different fsck issues\nare now used when checking fetches using bundles, too.\n\nThis project was led by [Justin Tobler](https://gitlab.com/justintobler).\n\n## Add reference consistency checks\n\nIn our Git release blog post about the Git 2.47.0 release, we mentioned Jialuo She's work on\n[adding a new 'verify' subcommand](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/#new-subcommand-for-git-refs(1)) to git-refs(1) which was part of the\n[Google Summer of Code 2024](https://summerofcode.withgoogle.com/archive/2024/projects/ukm4PTEF) (GSoC 2024).\n\nIn that blog post, we said that eventually the goal was to integrate this new subcommand as part of git-fsck(1) to provide a unified way to execute repository consistency checks. Jialuo She has decided to work on that after his GSoC was over.\n\nThe result from [this effort](https://lore.kernel.org/git/ZrtrT1CPI4YUf5db@ArchLinux/)\nis that git-fsck(1) can now detect and handle a number of reference-related issues, like when the content of a reference is bad, when a symbolic link is used as a symbolic reference, or when the target of a symbolic reference doesn't point to a valid reference. We still need to call `git refs verify` as part of git-fsck(1), and have the former perform all non-backend-specific checks that the latter currently does, but we are closer to our end goal of a unified way to execute all refs consistency checks.\n\nThis project was led by Jialuo She.\n\n## Iterator reuse in reftables\n\nIn the [Git 2.45.0](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNotes/2.45.0.txt) release, the 'reftables' format was introduced as a new backend for storing references (mostly branches and tags). If you are not yet\nfamiliar with the reftables backend, check out our previous [Git release blog post](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/) where the feature was introduced and our beginner’s guide to [learn more about how reftables work](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/).\n\nSince that release, we continued to improve this backend, and we recently focused on improving its performance by [reusing some internal iterators](https://lore.kernel.org/git/cover.1730732881.git.ps@pks.im/) when reading random references. Before these changes, reading a single reference required us to create a whole new iterator, seek it to the correct location in the respective tables, and then read the next value from it, which can be quite inefficient when reading many references in quick succession. After the change we now only create a single iterator and reuse it to read multiple references, thus saving some overhead.\n\nThe result of this work is increased performance in a number of reftables-related use cases, especially a 7% speedup when creating many references in a transaction that performs many random reads. Furthermore, this creates the possibility for more optimizations as we can continue to reuse more state kept in the iterators.\n\nThis project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Support for reflogs in `git-refs migrate`\n\nAfter the 'reftables' backend was introduced in Git 2.45.0 (see the section above), we worked on tooling to migrate reference backends in Git 2.46.0, which consisted of adding a new `migrate` subcommand to git-refs(1).\n\nOur article about Git 2.46.0 [talked about this work](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/#tooling-to-migrate-reference-backends) and mentioned some limitations that still existed. In particular, the article said:\n\n\"The reflogs in a repository are a component of a reference backend and would also require migration between formats. Unfortunately, the tooling is not yet capable of converting reflogs between the files and reftables backends.\"\n\nWe are pleased to report that we have [lifted this limitation in Git 2.48.0](https://lore.kernel.org/git/20241216-320-git-refs-migrate-reflogs-v4-0-d7cd3f197453@gmail.com/).\nReflogs can now also be migrated with `git refs migrate`. The migration tool is not yet capable of handling a repository with multiple worktrees, but this is the only limitation left. If you\ndon't use worktrees, you can already take advantage of the reftables backend in your existing repositories.\n\nThis project was led by [Karthik Nayak](https://gitlab.com/knayakgl).\n\n## Ref-filter optimization\n\nThe 'ref-filter' subsystem is some formatting code used by commands like `git for-each-ref`, `git branch` and `git tag` to sort, filter, format, and display information related to Git references.\n\nAs repositories grow, they can contain a huge number of references. This is why there is work not only on improving backends that store references, like the reftables backend (see above), but\nalso on optimizing formatting code, like the 'ref-filter' subsystem.\n\nWe recently [found a way](https://lore.kernel.org/git/d23c3e3ee7fdb49fcd05b4f2e52dd2a1cfdc10f2.1729510342.git.ps@pks.im/)\nto avoid temporarily buffering references and iterating several times on them in the ref-filter code when they should be processed in the same sorting order as the order the backends provide them. This results in memory savings and makes certain commands up to 770 times faster in some\ncases.\n\nThis project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Read more\n\nThis blog post highlighted just a few of the contributions made by GitLab and the wider Git community for this latest release. You can learn about these from the official release announcement of the Git project. Also, check out [our previous Git release blog posts](https://about.gitlab.com/blog/tags/git/) to see other past highlights of contributions from GitLab team members.\n\n- [What’s new in Git 2.47.0?](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/)\n- [What’s new in Git 2.46.0?](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/)\n- [What’s new in Git 2.45.0](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/)\n- [A beginner's guide to the Git reftable format](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/)\n",[699,675,268],{"slug":803,"featured":92,"template":679},"whats-new-in-git-2-48-0","content:en-us:blog:whats-new-in-git-2-48-0.yml","Whats New In Git 2 48 0","en-us/blog/whats-new-in-git-2-48-0.yml","en-us/blog/whats-new-in-git-2-48-0",{"_path":809,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":810,"content":816,"config":822,"_id":824,"_type":16,"title":825,"_source":17,"_file":826,"_stem":827,"_extension":20},"/en-us/blog/git-command-line-on-windows-with-git-bash",{"title":811,"description":812,"ogTitle":811,"ogDescription":812,"noIndex":6,"ogImage":813,"ogUrl":814,"ogSiteName":713,"ogType":714,"canonicalUrls":814,"schema":815},"Git command line on Windows with Git Bash","Learn about Git Bash, how it works, how to install it, and the main commands you need to know.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660028/Blog/Hero%20Images/blog-image-template-1800x945__25_.png","https://about.gitlab.com/blog/git-command-line-on-windows-with-git-bash","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git command line on Windows with Git Bash\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2024-12-16\",\n      }",{"title":811,"description":812,"authors":817,"heroImage":813,"date":819,"body":820,"category":14,"tags":821},[818],"GitLab","2024-12-16","Git commands allow developers to manage different versions of code and collaborate as a team. If you're in a Windows environment, you may have heard of Git Bash, a Bash terminal emulator that includes a Windows-friendly version of Git. Discover everything you need to know about installing Git Bash in this guide.\n\n## How does Git Bash work?   \nGit Bash is an application that you can install on Windows operating systems using Git for Windows. This application acts as an emulator to use the [Git version control tool](https://about.gitlab.com/topics/version-control/what-is-git-version-control/#what-is-git) on a Bash command terminal.\n\nBash is an acronym for Bourne Again SHell. SHell refers to the command terminal application of an operating system (OS). Bourne Again SHell is actually an upgraded version of Bourne SHell (also referred to as shell sh), the command line interface for UNIX developed by Stephen Bourne in 1977.  \n\nBash is the default shell for Linux and MacOS operating systems. With Git Bash, Windows users can install Bash, run Bash commands and use Git commands.\n\n## How to install Git Bash   \n\nTo download Git Bash, it is necessary to install Git for Windows. To do this, go to the official [Git for Windows](https://gitforwindows.org/) website and click \"Download\" to install the full Git package. When the download is complete, open the .exe file and begin the installation.  \n\nTo install Git Bash on Windows, please follow these step-by-step instructions:\n\n1. Open the .exe file and click **Next**. Select the appropriate folder for the installation.  \n2. Accept the terms of use and click **Next** to start the installation.  \n3. In this step, select the components to install. The pre-selected settings are relevant, but you can change them according to your preferences. Click **Next** again.  \n4. Then, choose the editor you prefer to use with Git. The tool recognizes editors already installed on your computer.  \n5. A window is displayed with three settings of the PATH environment. Depending on your needs, choose whether Git should only be used by Git Bash or if you want to use it from other third-party software.  \n6. Finally, keep the default settings by clicking **Next** and install Git Bash by clicking **Install**.\n\n## What are Bash commands?   \nFirst of all, the `pwd` (Print Working Directory) command allows you to view the absolute path. This means that it displays the path of the folder we are in at the time of typing the command.  \n**Remember:** When you open the Git Bash terminal, you are in a folder on your computer. Usually, this is the folder with your username.  \n\nThe `ls` command gives access to the list of files present in the current folder. You can also add options to the `ls` command with a dash `-`. For example, the `-l` option after `ls` lists the contents of a folder with more information about each file.\n\nBash also has a `cd` (Change Directory) command to move around your computer. To indicate the directory you want to go to, please specify the relative or absolute path after `cd`. The relative path is the location relative to the current directory while the absolute path is its location relative to the root folder.\n\n## How to use Git Bash with GitLab   \nUsing Git Bash with [GitLab](https://about.gitlab.com/) is like using the terminal emulator with another source code management platform. In order to push and retrieve your changes from GitLab, add the URL of your GitLab remote repository with the command: `git remote add origin \u003Crepository_url>`.\n\nIf your project is private, Git Bash asks you to authenticate yourself. Enter your credentials when the terminal requests your username and password. If you're having trouble logging in, check your authorization settings directly in GitLab.\n\nThen use the basic Git commands like `git clone`, `git commit`, `git push`, `git branch`, as well as `git checkout`, to name a few. To learn more, visit our [Git Cheat Sheet](https://about.gitlab.com/images/press/git-cheat-sheet.pdf).\n\n## Git Bash FAQ   \n**Are Git Bash and GitLab compatible?**\n\nYes. Using Git Bash with GitLab is similar to working with another source code management platform. Be sure to set up GitLab as a remote repository and authenticate yourself during the initial setup.\n\n**Why use Git Bash?**\n\nGit Bash acts as a terminal emulator to use the Git and Bash commands in a Windows environment.  \n\n**What's the point of a shell?**\n\nUsing a shell allows you to automate tasks through scripts, effectively control your computer and benefit from direct access to system functions.\n\n## Read more\n- [What is Git version control?](https://about.gitlab.com/topics/version-control/what-is-git-version-control/)\n- [What's new in Git 2.47.0?](https://about.gitlab.com/blog/whats-new-in-git-2-47-0/)\n- [Git pull vs. git fetch: What's the difference?](https://about.gitlab.com/blog/git-pull-vs-git-fetch-whats-the-difference/)",[699,675],{"slug":823,"featured":6,"template":679},"git-command-line-on-windows-with-git-bash","content:en-us:blog:git-command-line-on-windows-with-git-bash.yml","Git Command Line On Windows With Git Bash","en-us/blog/git-command-line-on-windows-with-git-bash.yml","en-us/blog/git-command-line-on-windows-with-git-bash",{"_path":829,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":830,"content":836,"config":844,"_id":846,"_type":16,"title":847,"_source":17,"_file":848,"_stem":849,"_extension":20},"/en-us/blog/ask-a-hacker-a-conversation-with-ahacker1",{"title":831,"description":832,"ogTitle":831,"ogDescription":832,"noIndex":6,"ogImage":833,"ogUrl":834,"ogSiteName":713,"ogType":714,"canonicalUrls":834,"schema":835},"Ask a hacker: A conversation with ahacker1","Alexander Siyou Tan, also known as ahacker1, joined us for an AMA to discuss how he got into hacking and some of his best bug bounty hunting strategies.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098255/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%282%29_5kE1qyriiwHs6cpvIwuyB_1750098255490.png","https://about.gitlab.com/blog/ask-a-hacker-a-conversation-with-ahacker1","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Ask a hacker: A conversation with ahacker1\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ottilia Westerlund\"}],\n        \"datePublished\": \"2024-12-12\",\n      }",{"title":831,"description":832,"authors":837,"heroImage":833,"date":839,"body":840,"category":14,"tags":841},[838],"Ottilia Westerlund","2024-12-12","At GitLab we have a tradition: Every year, we invite a bug bounty hunter to join us for an AMA. This year, we met with Alexander Siyou Tan, also known as [ahacker1](https://hackerone.com/ahacker1?type=user), and did a deep dive into all aspects of bug bounty hunting.\n\n## About Alexander (ahacker1)\n\nAlexander is passionate about hacking complex SaaS applications, with a particular interest in authorization-based vulnerabilities. Currently, he's focusing on [SAML and SSO](https://about.gitlab.com/blog/the-ultimate-guide-to-enabling-saml/) research. His hacking journey began during the Covid-19 pandemic, when he transitioned from gaming to exploring game hacks and easter eggs.\n\n## Highlights from the AMA\n\nHere are some of the questions AMA attendees asked Alexander, and his responses.\n\n**What are the tools you use in your research?**\n\nI use RubyMine as my IDE, as I find it helps with analyzing code. You can jump to  different parts of the code, and that helps with efficiency and allows you to search quickly and determine interesting behavior. I used to just use BurpSuite, but not so much anymore. I mainly focus on using JetBrains to review repositories on GitLab.\n\n**Have you explored using AI to assist in finding and/or exploiting vulnerabilities?**\n\nYes! When I learn about a new feature or subject, I may ask ChatGPT how it works. It may give some insights or leads – when I do SAML research I use it.\n\n**Tell us about moving into SAML and the experience of finding the awesome bugs in that area.**\n\nSAML is like a SaaS application within a SaaS application. There's a 100-page document on how SAML works, offering infinite possibilities. I focus on code analysis, reviewing the approximately 20 libraries available. While hacking SAML can be time-consuming due to setup and configuration, the payoff can be significant.\n\n**What’s next after SAML? Will you keep digging?**\n\nI will fix SAML. I want to fix libraries. Not sure what’s next - maybe SSO stuff!\n\n### Alexander's tips for the GitLab Bug Bounty Program\n\nAlexander offered the following advice for those interested in GitLab's Bug Bounty Program:\n\n1. Leverage GitLab's open source nature for code analysis.\n2. Study patch releases to learn reverse-engineering techniques.\n3. Review GitLab's public issues and disclosed reports for insights.\n\n### Getting to know our hacker\n\n**What do you do when you don't hack?**\n\nI play games, I also go out on walks and explore nature/hike. It’s a nice break from sitting at the computer.\n\n**How long do you think you would survive in a zombie apocalypse?**\n\nNot long. Without the internet, I don’t think I'd be able to adapt.\n\n**Is cereal a type of soup?**\n\nIt most definitely is. It has both liquid and food in it.\n\n## Watch the replay\n\nFor those interested in the full AMA, check out the YouTube live playback.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/EPV0eNOOfv4?si=byNqXWKZzZLXfLfW\" title=\"GitLab Ask a Hacker AMA with Alexander Siyou Tan (@ahacker1)\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nWe extend our gratitude to all participants and, of course, to Alexander for sharing his insights. Keep up with Alexander's latest activities on his [HackerOne profile](https://hackerone.com/ahacker1).\n\n## More \"Ask a Hacker\" AMAs\n\n- [Ask a hacker - 0xn3va](https://about.gitlab.com/blog/ask-a-hacker/)\n- [Ask a hacker - ajxchapman](https://about.gitlab.com/blog/ajxchapman-ask-a-hacker/)\n- [Ask a hacker - rpadovani](https://about.gitlab.com/blog/rpadovani-ask-a-hacker/)\n\n## About the GitLab Bug Bounty Program\n\nThe GitLab Bug Bounty Program aims to enhance the security of our products and services. Managed by our Application Security team, the program has achieved significant milestones since its public launch in December 2018, including:\n\n* Resolved 1,684 reports\n* Awarded over $4.7 million in bounties\n* Thanked 655 hackers for their findings\n\n> Learn more about the [GitLab Bug Bounty Program](https://hackerone.com/gitlab).\n",[842,843,675,268],"bug bounty","security",{"slug":845,"featured":92,"template":679},"ask-a-hacker-a-conversation-with-ahacker1","content:en-us:blog:ask-a-hacker-a-conversation-with-ahacker1.yml","Ask A Hacker A Conversation With Ahacker1","en-us/blog/ask-a-hacker-a-conversation-with-ahacker1.yml","en-us/blog/ask-a-hacker-a-conversation-with-ahacker1",{"_path":851,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":852,"content":858,"config":866,"_id":868,"_type":16,"title":869,"_source":17,"_file":870,"_stem":871,"_extension":20},"/en-us/blog/how-gitlab-empowers-translators-with-more-context",{"title":853,"description":854,"ogTitle":853,"ogDescription":854,"noIndex":6,"ogImage":855,"ogUrl":856,"ogSiteName":713,"ogType":714,"canonicalUrls":856,"schema":857},"How GitLab empowers translators with more context","Learn about the new translation context enhancement feature in GitLab. Join our translation community and help translate GitLab to your language.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097922/Blog/Hero%20Images/Blog/Hero%20Images/gitlabflatlogomap_gitlabflatlogomap.png_1750097921899.png","https://about.gitlab.com/blog/how-gitlab-empowers-translators-with-more-context","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab empowers translators with more context\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Oleksandr Pysaryuk\"}],\n        \"datePublished\": \"2024-12-09\",\n      }",{"title":853,"description":854,"authors":859,"heroImage":855,"date":861,"body":862,"category":14,"tags":863},[860],"Oleksandr Pysaryuk","2024-12-09","GitLab is continuously translated by our global community of translators and proofreaders. Through [Crowdin](https://docs.gitlab.com/ee/development/i18n/translation.html), they help make our product more accessible to the world by translating it into 78 languages. GitLab translation community members are volunteer translators, working professionals who are GitLab users, and even [university students contributing to translators as part of their classroom projects](https://about.gitlab.com/blog/behind-the-scenes-of-gitlab-korean-translation/).\n\n### How the GitLab open-core model supports translators\n\nWhile this community collaboration is powerful, translators often face a crucial challenge: understanding the full context of the text that they are translating.\n\nGreat translation isn't just about converting words – it's about preserving meaning, intent, and usability in a target language. Software translation requires a unique blend of skills. Great translators usually specialize in multiple linguistic domains as well as the technical domain of the product itself. They perform myriad translation-adjacent tasks such as:\n\n* ensuring accuracy and consistency of technical terminology\n* creating new glossary terms for new concepts\n* adhering to the style and tone\n* navigating the complexity of [CLDR pluralization rules](https://www.unicode.org/cldr/charts/46/supplemental/language_plural_rules.html)\n* understanding the translatability of composite messages and how to provide feedback to improve the source by making it localizable\n\nTranslators spend lots of time researching context, asking questions, and reading [GitLab product documentation](https://docs.gitlab.com/). Without proper context, even simple phrases can be mistranslated, potentially confusing or disrupting user workflows. What sets [GitLab apart is its open-core model](https://about.gitlab.com/blog/gitlab-is-open-core-github-is-closed-source/), which allows translators to access most of the product development context directly at the source. This transparency empowers them to actively contribute as true [co-creators of the GitLab global product](https://handbook.gitlab.com/handbook/company/mission/#mission).\n\n### Introducing our new context-enhancement feature\n\nTo support these needs and empower translators with context, GitLab has developed a new feature: we now [embed into each translatable string a contextual link](https://docs.gitlab.com/ee/development/i18n/translation.html#context) (more specifically, a link to our global in-product search) that lets translators locate all instances of that string in the codebase. These links allow translators to rely on [Git blame](https://docs.gitlab.com/ee/user/project/repository/files/git_blame.html) to trace every string's history – from its current location in code, through commits in merge requests, and all the way up to the original planning discussions.\n\nFor example, when you are translating **Rotate**, the **AccessTokens|** [namespace](https://docs.gitlab.com/ee/development/i18n/externalization.html#namespaces) suggests that the context is, well, *access tokens*. However, there is no additional visual context for what **Rotate** means, and translators are left to wonder, guess, and provide the best possible assumption in a target language.\n\nWith the new context enhancement, here is what translators are now able to do:\n\n1. Click the URL in the **See where this string is used in code** section.\n\n![see where this string is used in code section](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097928929.png)\n\n2. Review the [result of the code search](https://gitlab.com/search?project_id=278964&search=%22%28%5B%5E%3A%5D%28+%29%2B%3F%7C_%5C%5C%28%29%5B%27%5C%22%60%5DAccessTokens%5C%5C%7CRotate%5B%27%5C%22%60%5D%22+%28file%3A%5C.js%24+or+file%3A%5C.vue%24+or+file%3A%5C.rb%24+or+file%3A%5C.erb%24+or+file%3A%5C.haml%24%29+%28file%3A%5Eee%2Fapp%2F+or+file%3A%5Eee%2Flib%2F+or+file%3A%5Eee%2Fconfig%2F+or+file%3A%5Eee%2Flocale%2F+or+file%3A%5Eapp%2F+or+file%3A%5Elib%2F+or+file%3A%5Econfig%2F+or+file%3A%5Elocale%2F%29&regex=true), and click the **View blame** icon:\n\n![Screen with View blame icon](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097928930.png)\n\n3. Follow the link with the relevant merge request ([Introduce rotation of personal tokens in UI](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/169954)):\n\n![Link with relevant merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097928932.png)\n\n4. On the **Commits** page, follow the link to the actual merge request:\n\n![Commits page with link](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097928934.png)\n\n5. Watch the screen recording that the software engineer added to the merge request:\n\n![screen recording in merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097928936.png)\n\n6. Research even further by going to:\n   a. The linked issue [Introduce renew expired token capability in UI](https://gitlab.com/gitlab-org/gitlab/-/issues/241523) or its parent epic [Rotate Token through the UI](https://gitlab.com/groups/gitlab-org/-/epics/14563):\n\n![linked issue and parent epic](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097928938.png)\n\nb. The [related merge request that updates the GitLab product documentation](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/172916):\n\n![related merge request to update GitLab product documentation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097928940.png)\n\nAll these research steps will lead translators to better understand the technical concept of *access token rotation* and why the token rotation functionality was added, how it works, and what problem it solves for users.\n\nWith this rich research trail, translators get the maximum amount of context that will help provide the technically accurate and linguistically correct translation for the seemingly simple word **Rotate**.\n\nThis approach goes far beyond traditional translation aids like providing screenshots or exploring the product user interface. Translators can now fully understand the context by:\n\n* deriving context from paths and naming conventions used in code\n* viewing screenshots or video recordings that are added to original merge requests\n* reading original planning and development discussions\n* following the engineering, copywriting, and product management decision-making process that has led to specific wording\n\n### More AI-powered contextual features coming up\n\nThe GitLab Localization team isn't stopping here. We are working on [more context-enhancement features](https://gitlab.com/groups/gitlab-com/localization/-/epics/81), including AI-powered tools to help translators understand string usage and placement. Imagine a system where translators could interact with an agent by asking questions or proactively receiving immediate code-aware responses about where and how strings are used in the product UI.\n\n> ### Join our [community on Crowdin](https://docs.gitlab.com/ee/development/i18n/) as a translator or a [proofreader](https://docs.gitlab.com/ee/development/i18n/#proofreading), try these new context features, and let us know how we can make the [translation experience and our product even better](https://gitlab.com/gitlab-com/localization/localization-team/-/issues/259).\n",[268,864,676,865],"collaboration","contributors",{"slug":867,"featured":6,"template":679},"how-gitlab-empowers-translators-with-more-context","content:en-us:blog:how-gitlab-empowers-translators-with-more-context.yml","How Gitlab Empowers Translators With More Context","en-us/blog/how-gitlab-empowers-translators-with-more-context.yml","en-us/blog/how-gitlab-empowers-translators-with-more-context",{"_path":873,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":874,"content":880,"config":886,"_id":888,"_type":16,"title":889,"_source":17,"_file":890,"_stem":891,"_extension":20},"/en-us/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality",{"title":875,"description":876,"ogTitle":875,"ogDescription":876,"noIndex":6,"ogImage":877,"ogUrl":878,"ogSiteName":713,"ogType":714,"canonicalUrls":878,"schema":879},"What is Git? The ultimate guide to Git's role and functionality","Want to complete your projects with Git? Discover all of Git's benefits and features in our comprehensive guide.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673991/Blog/Hero%20Images/Git.jpg","https://about.gitlab.com/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What is Git? The ultimate guide to Git's role and functionality\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2024-11-14\",\n      }",{"title":875,"description":876,"authors":881,"heroImage":877,"date":882,"body":883,"category":14,"tags":884},[818],"2024-11-14","Git is a must-have tool in the world of modern software development. In this comprehensive guide, we explain in detail what the Git tool is, its role in source code versioning, and how it works. Whether you're a beginner or an expert, this guide will give you a deep understanding of Git and its many features.\n\n## What is Git?\n\nGit is a source control tool that has quickly become a must-have in the software development ecosystem. Git's ability to meticulously track project changes makes it an essential tool for developers aiming to efficiently manage their projects. Therefore, mastering Git has become a vital skill for anyone aiming to excel in the field of software development.\n\n### What is version control?\n\n[Version control](https://about.gitlab.com/topics/version-control/what-is-git-version-control/) enables you to track changes to a software's source code. Thus, a software's delivered version consists of a set of specific versions of each of its components and source code files. For example, an icon might have only been changed twice, while a code file might have undergone several dozen changes over time.\n\n## What are Git's features?\n\nIn development, maintaining rigorous management of changes to a software's source code is important. Without this, ensuring the consistency and reliability of development teams' work is impossible. Fine-tuned change management can also make it easier to identify the source of a problem. Similarly, it reduces the risk of conflicts and file overwriting. Indeed, Git facilitates and streamlines software versioning precisely for this purpose.\n\nTo better understand Git and how it works, below we've outlined some of the key features that make it easy to optimize source code management as well as collaboration across teams.\n\n### Visualization of your project history\n\nIn the software development ecosystem, [the commit history](https://about.gitlab.com/blog/keeping-git-commit-history-clean/) is a core pillar for tracking project progress on Git. That's why Git offers developers a detailed history of all changes made to the   \nsource code.\n\nFor each new commit, the following are recorded:\n\n* specific changes made to project files\n* an explanatory message from the developer who made the change\n\nThese elements help improve the development team's communication and mission, allowing them to more quickly understand the ins and outs of each change made to the code.\n\nIn addition to monitoring project developments, this history allows you to go back if necessary, cancel part of the changes or, conversely, fetch only part of the changes from one branch to another. This function therefore plays an essential role in maintaining the transparency, consistency, and quality of a project's source code in Git, as well as collaboration within the development team and operational efficiency to solve problems.\n\nCheck out our tutorial on [how to create your first Git commit](https://docs.gitlab.com/ee/tutorials/make_first_git_commit/).\n\n### Greater autonomy for teams\n\nAnother essential feature of the Git tool is [distributed development](https://git-scm.com/about/distributed). Thanks to its decentralized structure, Git allows development teams to work simultaneously on the same project. Each team member has their own copy of the project, where each of their changes can be versioned. This allows them to work autonomously on specific features while reducing conflict or overwriting risks. This approach offers great flexibility for developers who can then explore different ideas or experiment with new features without interfering with their colleagues' work.\n\nDistributed development also enhances resilience to server failures. Thus, even in the event of a failure, each person has a copy on which they can continue to work offline. Changes can then be synchronized once the server is available again, thereby reducing the risk of work disruption for development teams and update constraints for operational teams.\n\n### Optimizing development workflows\n\nOne of Git's most powerful features is the ability to [manage branches and their mergers (branching and merging)](https://git-scm.com/about/branching-and-merging). These allow teams to work in parallel in a collaborative and organized way. Each new code addition or bug fix can be independently developed and tested to ensure reliability. Developers can then simply merge changes into the project's main branch.\n\nBy adopting this approach, teams can track code evolution, collaborate easily and efficiently, reduce conflicts between different versions, and ensure continuous integration of developed features.\n\nUsing these two features, teams can develop projects continuously and in an agile manner while regularly deploying new code versions. This practice greatly facilitates change management while reducing the risk of errors.\n\n## What are Git's benefits?\n\nTo thoroughly understand Git, it's important to fully recognize the benefits it offers to your development teams:\n\n* **Decentralized version management:** With Git, each developer has a complete copy of the project history, allowing them to work independently.  \n* **A tool designed around security:** Unlike other source control tools, Git was designed from the outset to ensure the integrity of all elements of the repository with a cryptographic Secure Hash Algorithm (SHA1 and [SHA-256](https://about.gitlab.com/blog/gitlab-now-supports-sha256-repositories/) to date). This algorithm aims to protect the project's code and history from any modifications, whether malicious or not. In addition, each commit (creation of a new version) can be automatically signed (GPG) to ensure change traceability. This makes Git a particularly safe and secure tool, which guarantees the integrity and authenticity of your source code and its history.  \n* **A fast and effective tool:** The Git tool has been designed to maximize efficiency during development. Its speed allows developers to perform complex operations, such as commits, branching, and merging, in minimal time, even on large code bases. It also ensures a minimum fingerprint on the hard disk and during network exchanges. This efficiency then translates into rapid response times during backups, consultations, and project history changes.  \n* **Greater work flexibility:** Git supports a wide variety of development workflows. Whether you prefer centralized development models or more linear approaches, Git adapts easily. This ability to manage different workflows provides teams with numerous options for how they work.  \n* **Ease of integration:** Git excels in its ability to integrate with a wide array of existing development tools and platforms. The breadth of this compatibility allows teams to manage their projects more effectively by leveraging the best DevSecOps tools and practices.  \n* **A widely followed open-source project:** Another significant benefit of Git is that it's an open-source project supported by a dynamic and dedicated community which ensures its constant improvement. This active participation from individuals and companies in the Git community ensures the regular addition of new features and improvements through continuous updates.\n\n## What are Git's main commands?\n\nThe open-source Git project offers a wide variety of commands to make teamwork easier.  \nHere are some of the most commonly used commands.\n\n* **git init:** Initialize a new Git repository.  \n* **git clone \\[url\\]:** Clone an existing repository.  \n* **git add \\[file\\]:** Add a file to the index.  \n* **git commit:** Validate changes made.  \n* **git commit \\-m \"message\":** Validate changes with a message.  \n* **git status:** View the status of files in the working directory.  \n* **git push:** Send changes to remote repository.  \n* **git pull:** Fetch changes from the remote repository and merge them with the local repository.\n\nWhile these commands are essential to getting started with Git, it's important to note that there are plenty of other commands. See the [list of Git commands](https://git-scm.com/docs).\n\n## Git and GitLab\n\nGitLab is a collaborative open-source development platform covering all stages of the DevSecOps lifecycle and providing a Git server for efficient team collaboration.\n\nBeyond source code management, GitLab offers a complete suite enabling continuous integration and distribution, deliverables management, security and incident management, as well as all associated traceability, real-time task planning and tracking, deployment monitoring, software versioning, and the associated document space.\n\n## Git FAQs\n\n### Why use Git?\n\nGit is all about efficiency. Git's decentralized system based on branching and merging features allows development teams to work on the same project without interfering with others' work or, more importantly, creating version conflicts.\n\n### Is Git software?\n\nGit is an open-source project. Therefore, it's free and open to everyone. However, you need to [install Git](https://docs.gitlab.com/ee/topics/git/how_to_install_git/) on your device before you can start working.\n\n### What is a branch in Git?\n\nIn Git, a branch is a pointer to a change history. Thus, each main branch points to the last commit performed on it. It is therefore possible to have many parallel branches, each with its own history but the same root.\n\n### What is a commit?\n\nIn Git, a commit is a record of changes to a software's source code. Each commit is accompanied by an explanatory message that traces the history of all changes. This makes project tracking easier, and there's always the option to revert to earlier, functional versions if there's a problem.\n\n### What is the benefit of branches in Git?\n\nDeveloping features in branches allows developers to work simultaneously on several distinct features. In addition, this avoids compromising the main branch with unstable code. Moreover, implementing branches in Git is significantly more lightweight than in other version control systems.",[699,885,675],"DevSecOps",{"slug":887,"featured":6,"template":679},"what-is-git-the-ultimate-guide-to-gits-role-and-functionality","content:en-us:blog:what-is-git-the-ultimate-guide-to-gits-role-and-functionality.yml","What Is Git The Ultimate Guide To Gits Role And Functionality","en-us/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality.yml","en-us/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality",{"_path":893,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":894,"content":899,"config":904,"_id":906,"_type":16,"title":907,"_source":17,"_file":908,"_stem":909,"_extension":20},"/en-us/blog/whats-new-in-git-2-47-0",{"title":895,"description":896,"ogTitle":895,"ogDescription":896,"noIndex":6,"ogImage":793,"ogUrl":897,"ogSiteName":713,"ogType":714,"canonicalUrls":897,"schema":898},"What's new in Git 2.47.0?","Learn about the latest version of Git, including new global variables to configure reference and object hash formats. Discover contributions from GitLab's Git team and the wider Git community.","https://about.gitlab.com/blog/whats-new-in-git-2-47-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What's new in Git 2.47.0?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-10-07\",\n      }",{"title":895,"description":896,"authors":900,"heroImage":793,"date":901,"body":902,"category":14,"tags":903},[694],"2024-10-07","The Git project recently released [Git v2.47.0](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/).\nLet's look at a few notable highlights from this release, which includes\ncontributions from GitLab's Git team and the wider Git community.\n\n## New global configuration options\n\nIf you have been following recent Git releases, you are probably familiar with the new \"reftable\" reference backend that became available with\n[Git version 2.45](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/). Check out our [Beginner's guide to the Git reftable format](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/) to learn more. Previously, in order to initialize a repository with the \"reftable\" format, the `--ref-format` option needed to be passed to git-init(1):\n\n```sh\n$ git init --ref-format reftable\n```\n\nWith the 2.47 release, Git now has the `init.defaultRefFormat` configuration\noption, which tells Git which reference backend to use when initializing a\nrepository. This can be used to override the default \"files\" backend and begin using the \"reftable\" backend. To configure, execute the following:\n\n```sh\n$ git config set --global init.defaultRefFormat reftable\n```\n\nAs some of you may know, the object hash format used by Git repositories is\nalso configurable. By default, repositories are initialized to use the SHA-1\nobject format. An alternative is the SHA-256 format, which is more secure and future-proof. You can read more about this in one of our\n[previous blog posts on SHA-256 support in Gitaly](https://about.gitlab.com/blog/sha256-support-in-gitaly/#what-is-sha-256%3F). A SHA-256 repository can be created by passing the `--object-format` option to git-init(1):\n\n```sh\n$ git init --object-format sha256\n```\n\nIn this Git release another configuration option, `init.defaultObjectFormat`, has been added. This option tells Git which object format to use by default when initializing a repository. To configure, execute the following:\n\n```sh\n$ git config set --global init.defaultObjectFormat sha256\n```\n\nSomething to note, SHA-256 repositories are not interoperable with SHA-1\nrepositories and not all forges support hosting SHA-256 repositories. GitLab\nrecently announced [experimental support for SHA-256 repositories](https://about.gitlab.com/blog/gitlab-now-supports-sha256-repositories/) if you want to try it out.\n\nThese options provide a useful mechanism to begin using these repository\nfeatures without having to consciously think about it every time you initialize a new repository.\n\nThis project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## New subcommand for git-refs(1)\n\nIn the previous Git release, the [git-refs(1)](https://git-scm.com/docs/git-refs) command was introduced to provide low-level access to references in a\nrepository and provided the \"migrate\" subcommand to convert between reference backends. This release adds a new \"verify\" subcommand which allows the user to check the reference database for consistency. To verify the consistency of a repository, we often execute [git-fsck(1)](https://git-scm.com/docs/git-fsck).\n\nNotably, this command does not explicitly verify the reference database of the repository though. With the introduction of the \"reftable\" reference format, which is a binary format and thus harder to inspect manually, it is now even more important that tooling be established to fill this gap. Let's set up a repository with an invalid reference to demonstrate:\n\n```sh\n# The \"files\" backend is used so we can easily create an invalid reference.\n$ git init --ref-format files\n$ git commit --allow-empty -m \"init\"\n# A lone '@' is not a valid reference name.\n$ cp .git/refs/heads/main .git/refs/heads/@\n$ git refs verify\nerror: refs/heads/@: badRefName: invalid refname format\n```\n\nWe can see the invalid reference was detected and an error message printed to the user. While this tooling is not something the end-user will likely run, it is particularly useful on the server side to ensure repositories remain consistent. Eventually, the goal is to integrate this command as part of git-fsck(1) to provide a unified way to execute repository consistency checks.\n\nThis project was led by Jialuo She as part of the Google Summer of Code. To\nlearn more, you can read Jialuo's [GSoC report](https://luolibrary.com/2024/08/25/GSoC-Final-Report/).\n\n## Ongoing reftables work\n\nThis release also includes fixes for some bugs found in the \"reftable\" backend. One of these bugs is particularly interesting and revolves around how table compaction was being performed.\n\nAs you may recall, the reftable backend consists of a series of tables\ncontaining the state of all the references in the repository. Each atomic set of reference changes results in a new table being written and recorded in the \"tables.list\" file. To reduce the number of tables present, after each reference update, the tables are compacted to follow a geometric sequence by file size. After the tables are compacted, the \"tables.list\" file is updated to reflect the new on-disk state of the reftables.\n\nBy design, concurrent table writes and compaction is allowed. Synchronization at certain points is controlled through the use of lock files. For example, when compaction is starting the \"tables.list\" file is initially locked so the file can be consistently read and the tables requiring compaction can also be locked. Since the actual table compaction can take a while the lock is released, allowing concurrent writes to proceed. This is safe because concurrent writers know that they must not modify the now-locked tables which are about to be compacted. When the newly compacted tables have finished being written, the \"tables.list\" file is locked again and this time it is updated to reflect the new table state.\n\nThere is a problem though: What happens if a concurrent reference update writes a new table to the \"tables.list\" in the middle of table compaction after the initial lock was released, but before the new list file was written? If this race were to occur, the compacting process would not know about the new table and consequently rewrite the \"tables.list\" file without the new table. This effectively drops the concurrent update and could result in references not being added, updated, or removed as expected.\n\nLuckily, the fix to remediate this problem is rather straightforward. When the compacting process acquires the lock to write to the \"tables.list\" it must first check if any updates to the file have occurred and reload the file. Doing so ensures any concurrent table updates are also reflected appropriately. For more information on this fix, check out the corresponding\n[mailing-list thread](https://lore.kernel.org/git/cover.1722435214.git.ps@pks.im/).\n\nThis project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Fixes for git-maintenance(1)\n\nAs a repository grows, it is important that it is properly maintained. By\ndefault, Git executes\n[git-maintenance(1)](https://git-scm.com/docs/git-maintenance) after certain\noperations to keep the repository healthy. To avoid performing unnecessary\nmaintenance, the `--auto` option is specified which uses defined heuristics to determine whether maintenance tasks should be run. The command can be\nconfigured to perform various different maintenance tasks, but by default, it simply executes [git-gc(1)](https://git-scm.com/docs/git-gc) in the background and allows the user to carry on with their business.\n\nThis works as expected until maintenance is configured to perform non-default maintenance tasks. When this happens the configured maintenance tasks are performed in the foreground and the initial maintenance process doesn't exit until all tasks complete. Only the \"gc\" task detaches into the background as expected. It turns out this was because git-gc(1), when run with `--auto`, was accidentally detaching itself, and other maintenance tasks had no means to do so. This had the potential to slow down certain Git commands as auto-maintenance had to run to completion before they could exit.\n\nThis release addresses this issue by teaching git-maintenance(1) the `--detach` option, which allows the whole git-maintenance(1) process to run in the background instead of individual tasks. The auto-maintenance performed by Git was also updated to use this new option. For more information on this fix, check out the [mailing-list thread](https://lore.kernel.org/git/cover.1723533091.git.ps@pks.im/).\n\nA little earlier it was mentioned that the auto-maintenance uses a set of\nheuristics to determine whether or not certain maintenance operations should be performed. Unfortunately for the \"files\" reference backend, when\n[git-pack-refs(1)](https://git-scm.com/docs/git-pack-refs) executes with the\n`--auto` option, there is no such heuristic and loose references are\nunconditionally packed into a \"packed-refs\" file. For repositories with many\nreferences, rewriting the \"packed-refs\" file can be quite time-consuming.\n\nThis release also introduces a heuristic that decides whether it should pack\nloose references in the \"files\" backend. This heuristic takes into account the size of the existing \"packed-refs\" file and the number of loose references present in the repository. The larger the \"packed-refs\" file gets, the higher the threshold for the number of loose references before reference packing occurs. This effectively makes reference packing in the \"files\" backend less aggressive while still keeping the repository in a maintained state. Check out the [mailing-list thread](https://lore.kernel.org/git/cover.1725280479.git.ps@pks.im/)\nfor more info.\n\nThis project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Code refactoring and maintainability improvements\n\nIn addition to functional changes, there is also work being done to refactor\nand clean up the code. These improvements are also valuable because they help move the project closer toward the longstanding goal of libifying its internal components. To read more, here is a recent\n[update thread](https://lore.kernel.org/git/eoy2sjhnul57g6crprxi3etgeuacjmgxpl4yllstih7woyuebm@bd62ib3fi2ju/) regarding libification.\n\nOne area of improvement has been around resolving memory leaks. The Git project has quite a few memory leaks. For the most part, these leaks don't cause much trouble because usually a Git process only runs for a short amount of time and the system cleans up after, but in the context of libification it becomes something that should be addressed. Tests in the project can be compiled with a leak sanitizer to detect leaks, but due to the presence of existing leaks, it is difficult to validate and enforce that new changes do not introduce new leaks. There has been an ongoing effort to fix all memory leaks surfaced by existing tests in the project. Leak-free tests are subsequently marked with `TEST_PASSES_SANITIZE_LEAK=true` to indicate that they are expected to be free of leaks going forward. Prior to this release, the project had 223 test files containing memory leaks. This has now been whittled down to just 60 in this release.\n\nAnother ongoing effort has been to reduce the use of global variables\nthroughout the project. One such notorious global variable is `the_repository`, which contains the state of the repository being operated on and is referenced all over the project. This release comes with a number of patches that remove uses of `the_repository` in favor of directly passing the value where needed. Subsystems in the Git project that still depend on `the_repository` have `USE_THE_REPOSITORY_VARIABLE` defined allowing the global to be used. Now the refs, config, and path subsystems no longer rely on its use.\n\nThis project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab)\nwith the help of [John Cai](https://gitlab.com/jcaigitlab) and\n[Jeff King](https://github.com/peff).\n\n## Read more\n\nThis blog post highlighted just a few of the contributions made by GitLab and the wider Git community for this latest release. You can learn about these from the [official release announcement](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/)\nof the Git project. Also, check out our [previous Git release blog posts](https://about.gitlab.com/blog/tags/git/)\nto see other past highlights of contributions from GitLab team members.\n\n- [What’s new in Git 2.46.0?](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/)\n- [What's new in Git 2.45.0?](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/)\n- [A beginner's guide to the Git reftable format](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/)\n- [Git pull vs. git fetch: What's the difference?](https://about.gitlab.com/blog/git-pull-vs-git-fetch-whats-the-difference/)",[699,675,268],{"slug":905,"featured":92,"template":679},"whats-new-in-git-2-47-0","content:en-us:blog:whats-new-in-git-2-47-0.yml","Whats New In Git 2 47 0","en-us/blog/whats-new-in-git-2-47-0.yml","en-us/blog/whats-new-in-git-2-47-0",{"_path":911,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":912,"content":918,"config":924,"_id":926,"_type":16,"title":927,"_source":17,"_file":928,"_stem":929,"_extension":20},"/en-us/blog/what-is-gitflow",{"title":913,"description":914,"ogTitle":913,"ogDescription":914,"noIndex":6,"ogImage":915,"ogUrl":916,"ogSiteName":713,"ogType":714,"canonicalUrls":916,"schema":917},"What is GitFlow?","This article introduces the differences between GitFlow and GitLab Flow, explains what GitFlow is, how it works, its benefits, and answers frequently asked questions.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659838/Blog/Hero%20Images/AdobeStock_662057734.jpg","https://about.gitlab.com/blog/what-is-gitflow","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What is GitFlow?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2024-09-27\",\n      }",{"title":913,"description":914,"authors":919,"heroImage":915,"date":921,"body":922,"category":14,"tags":923},[920],"GitLab Team","2024-09-27","In GitFlow, developers create a separate \"`develop`\" (for development) branch in addition to the \"`main`\" (for operation) branch and set it as the default. However, with [GitLab Flow](https://about.gitlab.comtopics/version-control/what-is-gitlab-flow/), work can begin directly on the `main` branch. GitLab Flow incorporates pre-production branches, allowing for bug fixes before merging changes into the `main` branch and deploying to production. For example, teams can add as many pre-production branches as needed, such as flowing from `main` to test, test to acceptance, or acceptance to production. \n\nIn this article, you'll learn the differences between GitFlow and GitLab, what GitFlow is, how it works, its benefits, and get answers to frequently asked questions. \n\n## Table of contents\n- [What is GitFlow](#what-is-gitflow)\n- [How GitFlow works](#how-gitflow-works)\n- [How GitFlow and GitLab Flow differ](#how-gitflow-and-gitlab-flow-differ)\n- [GitFlow's workflow](#gitflow's-workflow)\n- [GitLab Flow's workflow](#gitlab-flow's-workflow)\n- [Benefits of using GitFlow and its features](#benefits-of-using-gitflow-and-its-features)\n- [GitFlow example](#gitflow-example)\n- [GitLab Flow and GitFlow FAQ ](#gitlab-flow-and-gitflow-faq)\n\n## What is GitFlow\n\nGitFlow is a Git workflow designed for managing branches in Git (a distributed version control system); it serves as a branching model for Git repositories. Created to simplify complex software release management, it was introduced by Vincent Driessen in 2010. It is particularly popular among large teams. \n\n## How GitFlow works\n\nCompared to trunk-based development, GitFlow features persistent branches and tends to involve larger commits. GitFlow can be used for projects with scheduled release cycles and aligns with [DevOps](https://about.gitlab.com/solutions/devops-platform/) best practices for continuous delivery. GitFlow provides a structured workflow where branches are defined for specific purposes, such as creating feature branches off the `develop` branch and the 'main' branch, preparing `release` branches, and eventually merging into `main`. This structure makes it easier for teams to understand where changes should be integrated within their development pipeline. \n\n## How GitFlow and GitLab Flow differ\n\nGitFlow is a Git branching model that utilizes multiple primary branches in addition to feature branches. [GitLab Flow](https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/) aims to address some of the complexities inherent in GitFlow, enabling team members to work more efficiently. Let's examine the workflow differences in more detail. \n\n### GitFlow's workflow\n\nThe GitFlow workflow involves the following five types of branches: \n\n1. main\n2. develop \n3. feature\n4. release \n5. hotfix\n\nWhen using GitFlow for code development, you work with the main branch and various supporting branches. There are two primary long-lived branches: the main branch for production-ready code, and the develop branch for integrating source code under development. Codes are stabilized in the `develop` branch, prepared to be released, and then merged into the main branch when ready. Supporting branches, such as feature, release, and hotfix branches, are created to handle specific development tasks. \n\n### GitLab Flow's workflow\n\nGitLab Flow streamlines development by preventing the overhead associated with releases, tagging, merging, and more. \n\nGitLab Flow is a simplified alternative to GitFlow, combining feature-driven development with issue tracking capabilities. Using GitLab Flow enables simple, straightforward, and efficient workflows. GitLab Flow incorporates best practices to help software development teams release features smoothly. \n\nGitLab Flow is the workflow used in GitLab's own development. It involves branches such as the `main` branch; a pre-release testing branch, `pre-production`; a branch for managing released code, `production`; and branches for feature development or bug fixes like `feature``hotfix`. Teams can add as many pre-production branches as they need. For example, creating flows such as from `main` to test, from test to approval, and from approval to production. \n\nWhile teams create feature branches, they also manage production branches. Once the main branch is ready for deployment, it will be merged into the production branch and released. GitLab Flow can also be utilized with release branches. Teams needing public APIs must manage different versions; GitLab Flow facilitates this by allowing the creation of individually manageable branches like `v1` and `v2`, making it convenient to revert to `v1` if bugs are detected during code review. \n\n## Benefits of using GitFlow and its features\n\n### 1: Rapid handling of bug fixes\n\nOne benefit of using GitFlow is the ability to quickly handle bug fixes in the production environment. GitFlow is employed as a Git (distributed version control system) workflow, particularly by large teams engaged in complex software development. \n\n### 2: Ensured testing\n\nWhen releasing software from a release branch, you can allocate time for users to test in a staging environment. This can occur independently of ongoing code development. Furthermore, as commits flow downstream through different stages, it helps ensure testing across all relevant environments. \n\n### 3: Streamlined software development process\n\nUsing GitFlow allows you to leverage Git to its full potential. This, in turn, helps streamline the software development process. \n\n### 4: More efficient collaboration, conflict resolution, and continuous delivery\n\nImplementing GitFlow enhances collaboration efficiency. Merge conflicts can be resolved quickly, enabling continuous delivery. \n\n## GitFlow example\nThe diagram below illustrates an example configuration of GitFlow. It should help clarify the overall flow, including the different branches and their structure.  \n\n![GitFlow example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673714/Blog/Content%20Images/AdobeStock_569852816.jpg)\n\n## GitLab Flow and GitFlow FAQ \n\n### Q: What is Git Feature Flow? \n\nA: It is one of the proposed development workflows that utilize Git. Git Feature Flow is suitable for handling simpler development requirements. \n\n### Q: Is GitLab Flow worth using? \n\nA: Yes. GitLab Flow reduces the overhead associated with activities like releasing, tagging, and merging. These can be common issues encountered in other Git workflows. For more details, see [these GitLab Flow best practices](https://about.gitlab.com/topics/version-control/what-are-gitlab-flow-best-practices/). \n\n### Q: How should I choose between GitLab Flow and GitFlow? \n\nA: Git Flow, due to its structure, is well-suited for large projects with clearly defined development stages. GitLab Flow, being more agile, is better suited for projects that prioritize continuous delivery and rapid releases. \n\n## Get started with GitLab\n\nStart your [free, 60-day trial of GitLab Ultimate and GitLab Duo Enterprise](https://about.gitlab.com/free-trial/) today!\n",[699,675],{"slug":925,"featured":6,"template":679},"what-is-gitflow","content:en-us:blog:what-is-gitflow.yml","What Is Gitflow","en-us/blog/what-is-gitflow.yml","en-us/blog/what-is-gitflow",{"_path":931,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":932,"content":937,"config":942,"_id":944,"_type":16,"title":945,"_source":17,"_file":946,"_stem":947,"_extension":20},"/en-us/blog/git-pull-vs-git-fetch-whats-the-difference",{"title":933,"description":934,"ogTitle":933,"ogDescription":934,"noIndex":6,"ogImage":813,"ogUrl":935,"ogSiteName":713,"ogType":714,"canonicalUrls":935,"schema":936},"Git pull vs. git fetch: What's the difference? ","Git pull is a Git command that performs both git fetch and git merge simultaneously. This article outlines the characteristics and appropriate uses of each.","https://about.gitlab.com/blog/git-pull-vs-git-fetch-whats-the-difference","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git pull vs. git fetch: What's the difference? \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2024-09-24\",\n      }",{"title":933,"description":934,"authors":938,"heroImage":813,"date":939,"body":940,"category":14,"tags":941},[818],"2024-09-24","The Git command is very popular as a [distributed version control system](https://about.gitlab.com/topics/version-control/benefits-distributed-version-control-system/) and is used when synchronization with a remote repository is necessary. The developer needs to choose the appropriate commands based on the project's needs. In this article, we will explain the basics and differences between git fetch and git pull, and provide a detailed explanation of their respective use cases. \n\nTable of contents \n- [Git fetch and git pull basics](#git-fetch-and-git-pull-basics)\n- [What is git fetch?](#what-is-git-fetch%3F)\n- [What is git pull?](#what-is-git-pull%3F)\n- [When to use git fetch](#when-to-use-git-fetch)\n- [When to use git pull](#when-to-use-git-pull)\n- [Git fetch and git pull FAQs](#git-fetch-and-git-pull-faqs)\n\n## Git fetch and git pull basics \n\nGit fetch and git pull are both Git commands used to retrieve update information from a remote repository. So, how do they differ? Git fetch downloads the changes from the remote repository to the local repository but does not make any changes to the current working directory. Since the changes are not merged into the local branch, you can check the changes from the remote repository without interrupting your current work. On the other hand, git pull retrieves the latest changes from the remote repository like git fetch, but it also automatically merges those changes into the current branch. In contrast to git fetch, git pull directly applies the changes from the remote repository to the local working directory.\n\n## What is git fetch? \nThe git fetch command retrieves the latest commit history from the remote repository, but it does not affect the local working directory. Even after fetching remote changes, they are not reflected in the local branch. It is primarily used when you want to retrieve the latest status from the remote repository and review the changes before they are reflected in the local repository. To apply the retrieved changes to the local branch, you need to manually run git merge or [git rebase](https://docs.gitlab.com/ee/topics/git/git_rebase.html).\n\n## What is git pull? \nThe git pull command combines `git fetch` and `git merge` (or `git rebase`) into a single command. This allows you to fetch changes from the remote repository and automatically integrate them into the current local branch. \n\nWhile git fetch retrieves changes from the remote repository without applying them to the local branch, running git pull automatically integrates the changes from the remote repository into the local branch. \n\nGit pull is suitable for quickly reflecting remote changes in the local branch, but it can lead to conflicts, so caution is needed, especially when working with multiple people. \n\n## When to use git fetch \nGit fetch is a command used to retrieve the latest information from a remote repository. The retrieved information is not directly reflected in the local branch. Using git pull will reflect all remote branches, including incorrect or problematic ones, in the local branch. \n\nWhen changes are made simultaneously on both remote and local branches, or when there are new users on the team, it is safer to use git fetch to retrieve the remote branch contents first and then perform merge or rebase. \n\n## When to use git pull \nGit pull is a command that performs more processes compared to git fetch. Git pull can perform both git fetch and additionally execute git merge or git rebase. For this reason, git pull is recommended when you want to quickly reflect changes from the remote repository in the local branch. \n\n## Git fetch and git pull FAQs\n\n### What is the difference between git pull and git fetch? \nGit pull is a command that performs git fetch followed by git merge or git rebase. While git fetch does not affect the local repository, git pull automatically synchronizes changes from the remote repository with the local repository. \n\n### What precautions should be taken when using git pull? \nWhen executing git pull, there may be conflicts between remote and local changes. Merge conflicts are particularly likely to occur, so if conflicts arise, they need to be resolved manually. Additionally, using git pull --rebase allows you to incorporate the latest changes while performing a rebase. \n\n### What is git fetch used for? \nGit fetch is useful for checking and retrieving the latest status of the remote repository. However, the changes retrieved are not automatically reflected in the local branch; git fetch is used to synchronize the local and remote repositories. \n\n## Read more\n- [What's new in Git 2.46](https://about.gitlab.com/blog/whats-new-in-git-2-46-0/)\n- [Learn Git](https://docs.gitlab.com/ee/topics/git/)\n- [Learn about GitLab Gitaly](https://docs.gitlab.com/ee/administration/gitaly/)",[699,675],{"slug":943,"featured":6,"template":679},"git-pull-vs-git-fetch-whats-the-difference","content:en-us:blog:git-pull-vs-git-fetch-whats-the-difference.yml","Git Pull Vs Git Fetch Whats The Difference","en-us/blog/git-pull-vs-git-fetch-whats-the-difference.yml","en-us/blog/git-pull-vs-git-fetch-whats-the-difference",{"_path":949,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":950,"content":955,"config":960,"_id":962,"_type":16,"title":963,"_source":17,"_file":964,"_stem":965,"_extension":20},"/en-us/blog/whats-new-in-git-2-46-0",{"title":951,"description":952,"ogTitle":951,"ogDescription":952,"noIndex":6,"ogImage":813,"ogUrl":953,"ogSiteName":713,"ogType":714,"canonicalUrls":953,"schema":954},"What’s new in Git 2.46.0?","Here are highlights of release contributions from GitLab's Git team and the wider Git community, including reference backend migration tooling and transactional symbolic reference updates.","https://about.gitlab.com/blog/whats-new-in-git-2-46-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What’s new in Git 2.46.0?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-07-29\",\n      }",{"title":951,"description":952,"authors":956,"heroImage":813,"date":957,"body":958,"category":14,"tags":959},[694],"2024-07-29","The Git project recently released [Git v2.46.0](https://lore.kernel.org/git/xmqqzfq0i0qa.fsf@gitster.g/T/#u). Let's look at a few notable highlights from this release, which includes contributions from GitLab's Git team and the wider Git community.\n\n## Tooling to migrate reference backends\n\nIn the previous [Git 2.45.0](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNotes/2.45.0.txt?ref_type=heads)\nrelease, the reftables format was introduced as a new backend for storing\nreferences. This new reference format solves some challenges that large\nrepositories face as the number of references scales. If you are not yet\nfamiliar with the reftables backend, check out our previous [Git release blog post](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/) where the feature was introduced and our beginner’s guide to [learn more about how reftables work](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/).\n\nThe reftable backend has a different on-disk format than the pre-existing files backend. Consequently, to use reftables on an existing repository requires a conversion between the different formats. To accomplish this, a new git-refs(1) command has been introduced with the `migrate` subcommand to perform reference backend migrations. Below is an example of how this command can be used.\n\n```shell\n# Initialize a new repository as “bare” so it does not contain reflogs.\n$ git init --bare .\n$ git commit --allow-empty -m \"init\"\n# Populate repository with references in the files backend.\n$ git branch foo\n$ git branch bar\n$ tree .git/refs\n.git/refs\n├── heads\n│   ├── bar\n│   ├── foo\n│   ├── main\n└── tags\n# Perform reference migration to reftables format.\n$ git refs migrate --ref-format=reftable\n# Check that reftables backend is now in use.\n$ tree .git/reftable\n.git/reftable\n├── 0x000000000001-0x000000000001-a3451eed.ref\n└── tables.list\n# Check the repository config to see the updated `refstorage` format.\n$ cat config\n[core]\n        repositoryformatversion = 1\n        filemode = true\n        bare = true\n        ignorecase = true\n        precomposeunicode = true\n[extensions]\n        refstorage = reftable\n```\n\nOnce a repository has been migrated, the on-disk format is changed to begin\nusing the reftable backend. Git operations on the repository continue to\nfunction and interact with remotes the same as before. The migration only\naffects how references are stored internally for the repository. If you wish to go back to the files reference backend, you can accomplish this with the same command by instead specifying `--ref-format=files`.\n\nThe migration tooling currently has some notable limitations. The reflogs in a repository are a component of a reference backend and would also require\nmigration between formats. Unfortunately, the tooling is not yet capable of\nconverting reflogs between the files and reftables backends. Also, a repository with worktrees essentially has multiple ref stores and the migration tool is not yet capable of handling this scenario. Therefore, if a repository contains reflogs or worktrees, reference migration is currently unavailable. These limitations may be overcome in future versions.\n\nBecause a bare Git repository does not have reflogs, it is easier to migrate. To migrate a standard non-bare repository, reflogs must be pruned first. Therefore, any repository without reflogs or worktrees can be migrated. With these limitations in mind, this tool can be used to begin taking advantage of the reftables backend in your existing repositories.\n\nThis project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Transactional symref updates\n\nThe [git-update-ref(1)](https://git-scm.com/docs/git-update-ref) command\nperforms reference updates in a Git repository. These reference updates can also be performed atomically in bulk with transactions by using\n`git update-ref --stdin` and passing update-ref instructions on stdin. Below is an example of how this is done.\n\n```shell\n$ git init .\n$ git branch -m main\n$ git commit --allow-empty -m \"foo\" && git commit --allow-empty -m \"bar\"\n# Retrieve the object ID of the two commits created.\n$ git rev-parse main~ main\n567aac2b3d1fbf0bd2433f669eb0b82a0348775e\n3b13462a9a42e0a3130b9cbc472ab479d3ef0631\n# Start transaction, provide update-ref instructions, and commit.\n$ git update-ref --stdin \u003C\u003CEOF\n> start\n> create refs/heads/new-ref 3b13462a9a42e0a3130b9cbc472ab479d3ef0631\n> update refs/heads/main 567aac2b3d1fbf0bd2433f669eb0b82a0348775e\n> commit\n> EOF\n$ git for-each-ref\n567aac2b3d1fbf0bd2433f669eb0b82a0348775e commit refs/heads/main\n3b13462a9a42e0a3130b9cbc472ab479d3ef0631 commit refs/heads/my-ref\n```\n\nFrom this example, once the transaction is committed, a new branch is created pointing to the “bar” commit and the main branch is updated to point to the previous “foo” commit. Committing the transaction performs the specified reference updates atomically. If an individual reference update fails, the transaction is aborted and no reference updates are performed.\n\nA notable absence here is instructions to support symref updates in these\ntransactions. If a user wants to update a symref along with other references\natomically in the same transaction, there is no tooling to do so. In this\nrelease, the `symref-create`, `symref-update`, `symref-delete`, and\n`symref-verify` instructions are introduced to provide this functionality.\n\n```shell\n# Create a symref that will be updated during the next operation.\n$ git symbolic-ref refs/heads/symref refs/heads/main\n# The --no-deref flag is required to ensure the symref itself is updated.\n$ git update-ref --stdin --no-deref \u003C\u003CEOF\n> start\n> symref-create refs/heads/new-symref refs/heads/main\n> symref-update refs/heads/symref refs/heads/new-ref\n> commit\n> EOF\n$ git symbolic-ref refs/heads/symref\nrefs/heads/new-ref\n$ git symbolic-ref refs/heads/new-symref\nrefs/heads/main\n```\n\nFrom the above example, a new symbolic reference is created and another is\nupdated in a transaction. These new symref instructions can be used in\ncombination with the pre-existing instructions to perform all manner of\nreference updates now in a single transaction. Check out the\n[documentation](https://git-scm.com/docs/git-update-ref) for more information regarding each of these new instructions.\n\nThis project was led by [Karthik Nayak](https://gitlab.com/knayakgl).\n\n## UX improvements for git-config(1)\n\nThe git-config(1) command allows repository and global options to be viewed and configured. The modes used to interact with configuration can be selected explicitly using flags or determined implicitly based on the number of arguments provided to the command. For example:\n\n```shell\n$ git config --list\n# Explicit retrieval of username configuration\n$ git config --get user.name\n# Implicit retrieval of username configuration\n$ git config user.name\n# Explicit setting of username configuration\n$ git config --set user.name \"Sidney Jones\"\n# Implicit setting of username configuration\n$ git config user.name \"Sidney Jones\"\n# An optional third argument is also accepted. What do you think this does?\n$ git config \u003Cname> [\u003Cvalue> [\u003Cvalue-pattern>]]\n```\n\nOverall, the [git-config(1)](https://git-scm.com/docs/git-config) user\ninterface is not consistent with how other more modern Git commands work where you usually use subcommands. For example, `git remote list`. This release introduces `list`, `get`, `set`, `unset`, `rename-section`, `remove-section`, and `edit` as subcommands for use with the config command while also keeping the old-style syntax available. This change aims to improve user experience by adapting the config command to follow more UI practices and better conform to other commands within Git. For example:\n\n```shell\n$ git config list\n$ git config get user.name\n$ git config set user.name \"Sidney Jones\"\n```\n\nThis project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Addressed performance regression\n\nGit operations that leverage attributes rely on reading `.gitattributes` files found in the repository’s working-tree. This is problematic for bare Git repositories because by definition they lack a working-tree. To get around this, Git has the `attr.tree` configuration that allows a source tree to be specified and used to lookup attributes from.\n\nIn Git release 2.43.0, Git started using the tree of `HEAD` as the source of Git attributes for bare repositories by default. Unfortunately, the additional overhead due to scanning for Git attributes files had severe performance impacts. This is because, when `attr.tree` is set, each attribute lookup requires walking the source tree to check for an associated `.gitattributes` file. The larger and deeper the source tree of the repository is, the more pronounced the performance regression becomes. For example, benchmarks run on the linux.git repository showed\ngit-pack-objects(1) taking 1.68 times longer to complete. This could lead to slowdowns when performing clones or fetches.\n\n```\n# attr.tree set to HEAD as done by default in Git version 2.43.0.\nBenchmark 1: git -c attr.tree=HEAD pack-objects --all --stdout \u003C/dev/null >/dev/null\n  Time (mean ± σ):     133.807 s ±  4.866 s    [User: 129.034 s, System: 6.671 s]\n  Range (min … max):   128.447 s … 137.945 s    3 runs\n\n# attr.tree is set to an empty tree to disable attribute lookup as done in Git versions prior to 2.43.0.\nBenchmark 2: git -c attr.tree=4b825dc642cb6eb9a060e54bf8d69288fbee4904 pack-objects --all --stdout \u003C/dev/null >/dev/null\n  Time (mean ± σ):     79.442 s ±  0.822 s    [User: 77.500 s, System: 6.056 s]\n  Range (min … max):   78.583 s … 80.221 s    3 runs\n```\n\nSome of the most notable Git commands that were affected were `clone`, `pull`, `fetch`, and `diff` when, as previously mentioned, used on repositories with large or deep trees. Consequently, the `attr.tree` configuration was partially reverted to no longer be set to `HEAD` by default to address the performance regression. To learn more, check out this\n[thread](https://lore.kernel.org/git/CAKOHPAn1btewYTdLYWpW+fOaXMY+JQZsLCQxUSwoUqnnFN_ohA@mail.gmail.com/) on the mailing list.\n\n## Unit-test migration\n\nHistorically, testing in the Git project has been done via end-to-end tests\nimplemented as shell scripts. The Git project has relatively recently\nintroduced a unit-testing framework written in C. This new testing framework\nbrings opportunities for more in-depth testing of low-level implementation\ndetails at the individual function call level and helps complement the existing end-to-end tests. There are some existing end-to-end tests that are a better fit as unit-tests and thus are good candidates to be ported.\n\nThis year, GitLab is again helping mentor [Google Summer of Code (GSoC)](https://summerofcode.withgoogle.com/) contributors working in the Git project. Thanks to efforts from these ongoing GSoC projects and also the wider Git community, some existing tests are being refactored and migrated to the unit-testing framework. During this last release cycle, there have been several contributions towards the goal of improving the testing in the Git project. To follow development progress for these GSoC contributor projects, check out [Chandra’s](https://chand-ra.github.io/) and [Ghanshyam’s](https://spectre10.github.io/posts/) blogs.\n\n## Bundle URI fixes\n\nUsually when a client fetches from a remote repository, all required objects\nare sent in a packfile computed by the remote server. To avoid some of this\ncomputation, servers can opt to advertise prebuilt “bundles” stored separately from the remote server which contain sets of references and objects that the client may need. The client can fetch these bundles first through a mechanism called [bundle-uri](https://git-scm.com/docs/bundle-uri).\n\nThanks to [Xing Xin](https://lore.kernel.org/git/pull.1730.git.1715742069966.gitgitgadget@gmail.com/), an issue was identified and fixed where Git, despite having downloaded some bundles, was still downloading everything from the remote as if there were no bundles. This was due to Git not correctly discovering all the downloaded bundles, which resulted in having to fetch the consecutive ones from the remote. With this fixed, remotes using the bundle-uri mechanism can avoid having to perform redundant work and improve performance.\n\n## Read more\n\nThis article highlighted just a few of the contributions made by GitLab and\nthe wider Git community for this latest release. You can learn about these from the [official release announcement](https://lore.kernel.org/git/xmqqzfq0i0qa.fsf@gitster.g/T/#u) of the Git project. Also, check out our [previous Git release blog posts](https://about.gitlab.com/blog/tags/git/) to see other past highlights of contributions from GitLab team members.",[699,675,268],{"slug":961,"featured":92,"template":679},"whats-new-in-git-2-46-0","content:en-us:blog:whats-new-in-git-2-46-0.yml","Whats New In Git 2 46 0","en-us/blog/whats-new-in-git-2-46-0.yml","en-us/blog/whats-new-in-git-2-46-0",{"_path":967,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":968,"content":974,"config":980,"_id":982,"_type":16,"title":983,"_source":17,"_file":984,"_stem":985,"_extension":20},"/en-us/blog/kubernetes-the-container-orchestration-solution",{"title":969,"description":970,"ogTitle":969,"ogDescription":970,"noIndex":6,"ogImage":971,"ogUrl":972,"ogSiteName":713,"ogType":714,"canonicalUrls":972,"schema":973},"Kubernetes: Get to know the container orchestration solution","Kubernetes, also known as K8s, is a must-have solution for deploying and maintaining applications, especially in the cloud. Learn the basics of Kubernetes with this introductory guide.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660215/Blog/Hero%20Images/kubernetes-container-orchestration-solution.jpg","https://about.gitlab.com/blog/kubernetes-the-container-orchestration-solution","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Kubernetes: Get to know the container orchestration solution\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2024-07-25\",\n      }",{"title":969,"description":970,"authors":975,"heroImage":971,"date":976,"body":977,"category":14,"tags":978,"updatedDate":979},[920],"2024-07-25","Kubernetes automates the tasks of deploying and managing containerized applications on a large scale. Over time, Kubernetes has become an essential tool for developing applications in many areas, such as [microservices](https://about.gitlab.com/topics/microservices/), web applications, and databases. Its performance and scalability make it a recognized standard in container management today.\n\nDiscover everything you need to know about Kubernetes in this article.\n\n## What is Kubernetes?\n\nKubernetes is an open-source system for efficiently orchestrating the containers of a software application. Containerization is a widely acclaimed approach to developing applications, especially in the areas of digital transformation and the cloud.\n\nIf you're not familiar with the concept of containers, note that it is an application development method that groups the components of an application into standardized units – or containers – that are independent of the devices and operating systems they are located on. By isolating applications from their environment, this technology facilitates their deployment and portability, as well as reduces interoperability conflicts.\n\nThis is where we use the Kubernetes software. Certainly, containers allow applications to be divided into smaller and autonomous modules, thus facilitating their deployment. However, for containers to interact within an application, a management system encompassing these modules is necessary. That's exactly what Kubernetes does. Kubernetes provides a platform to control where and how containers run, so you can orchestrate and schedule their execution to manage containerized applications on a large scale.\n\n> Browse [GitLab articles about Kubernetes](https://about.gitlab.com/blog/tags/kubernetes/).\n\n## How does a Kubernetes architecture work?\n\nTo understand how a Kubernetes architecture works, it is essential to become familiar with certain concepts, starting with that of the cluster, which is the most extensive within the architecture. A Kubernetes cluster is defined as the set of virtual or physical machines on which a containerized application is installed.\n\n![Components of Kubernetes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673941/Blog/Content%20Images/components-of-kubernetes.png)\n\nSource: [Kubernetes](https://kubernetes.io/docs/concepts/overview/components/).\n\nThis cluster comprises different elements:\n- Node: This is a work unit in a Kubernetes cluster. It is a virtual or physical machine that performs tasks on behalf of the application.\n- Pod: A pod is the smallest deployable unit in Kubernetes. It is a group of containers working together on the same node. Containers inside a pod share the same network and can communicate with each other via localhost.\n- Service: A Kubernetes service exposes a pod to the network or other pods. It offers a stable and well-defined access point to applications hosted by pods.\n- Volume: A folder abstraction that solves problems of sharing and retrieving files within a container.\n- Namespace: A namespace allows you to group and isolate resources to form a virtual cluster.\n\nThe Kubernetes architecture is based on two main types of nodes: the master node and the worker nodes. The master node is responsible for the overall management of the Kubernetes cluster and communication with the worker nodes. Among its key components, the API is the central point of contact for all communications between users and the cluster. The [etcd](https://kubernetes.io/docs/concepts/overview/components/#etcd) is the key-value database where the configurations, the system state and the object metadata, are stored. The controller manager coordinates background operations such as pod replication, and the scheduler places pods on nodes based on available resources.\n\nWorker nodes, on the other hand, are the machines that run and manage the applications contained in the pods. Within them, the [kubelet](https://kubernetes.io/docs/concepts/overview/components/#kubelet) is the agent that runs on each node and communicates with the master to receive the commands and transmit the status of the pods. The network proxy or [kube-proxy](https://kubernetes.io/docs/concepts/overview/components/) maintains network rules on nodes to allow access to services from outside the Kubernetes cluster. Finally, the container runtime is the software responsible for the execution and management of containers within the pods.\n\n### Docker's role\n\nAmong all the components of a K8s cluster, the choice of runtime within the worker nodes is important. Different software is available for this, such as rkt or CRI-O, but Docker is the most commonly used tool.\n\n### What is the difference between Docker and Kubernetes?\n\nDocker is an open-source solution that is specifically used at the container level. It allows containers to be packaged in a standardized and lightweight format, which increases their portability in different environments. It is therefore a complementary tool to K8s that facilitates the management of containers themselves, while Kubernetes simplifies their integration and communication within the application.\n\n## What are the benefits of Kubernetes?\n\nLaunched by Google in 2014, the first stable version of Kubernetes appeared in July 2015. Since then, the popularity of this software has not wavered, making K8s a benchmark in the field of container orchestration, especially for microservice-oriented architectures. So then, why use Kubernetes? This success is primarily due to the excellent performance of this software in container orchestration.\n\nThe benefits of Kubernetes are plenty, as follows:\n- Automation: Kubernetes facilitates the automation of tasks related to the deployment, scaling, and updating of containerized applications.\n- Flexibility: The software adapts to different container technologies, as well as various hardware architectures and operating systems.\n- Scalability: K8s facilitates the deployment and management of thousands of containers, regardless of their status: running, paused, or stopped.\n- Migration: It is possible to easily migrate applications to Kubernetes without having to change the source code.\n- Multi-cluster support: Kubernetes centrally manages multiple container clusters distributed across different infrastructures.\n- Update management: The software supports rolling update deployments to update applications without service disruption.\n\n## A robust and scalable ecosystem\n\nKubernetes stands out for its ability to manage containers efficiently and securely, while maintaining its independence from cloud infrastructure providers. Its modular architecture adapts to the specific needs of each company and supports a very wide range of applications and services (web services, data processing, mobile applications, etc.).\n\nIn the race for digital transformation, Kubernetes also wins over people, thanks to its rich and scalable ecosystem within the open-source community. Managed by the Cloud Native Computing Foundation ([CNCF](https://www.cncf.io/)), K8s is supported by thousands of developers around the world. They contribute to the development of the project and the continuous improvement of its features.\n\n## What are the limitations of Kubernetes?\n\nThe benefits of Kubernetes make it a safe choice for many development teams in the cloud-native application space. Nevertheless, it is worth pointing out some of its limitations. Kubernetes requires a solid technical background and training in new development concepts and methods. The software can be complex to configure at the beginning of a project. However, configuration is crucial, especially to secure the platform. Having an experienced development team for K8s projects is therefore a significant asset.\n\nAnother challenge is the implementation and maintenance of a K8s architecture, which also requires time and resources, especially to update its various components and software. This raises the question of possible oversizing. In the case of a small application, or a project with no particular challenge in terms of scalability, a more basic architecture may suffice while being more economical.\n\n## Using Kubernetes within your teams\n\nTens of thousands of companies have adopted a Kubernetes architecture to carry out their digital transition. K8s is used by companies of all sizes, from startups to multinationals.\n\nThere are many examples of successful integrations, such as for Haven Technologies. Haven Technologies has migrated its SaaS services to K8s and relies in particular on a Kubernetes strategy with the GitLab DevSecOps platform to help its teams improve efficiency, security, and speed of software development. Check out [our client story](https://about.gitlab.com/customers/haven-technologies/) to learn more!\n\n## Kubernetes, Git, and GitLab\n\nKubernetes, Git, and GitLab are essential elements of the DevOps landscape. Kubernetes offers great flexibility to deploy and manage the various components of an application, while GitLab, which is built around Git and its native version control system, allows rigorous and accurate tracking of source code and changes, while providing a comprehensive suite of tools to manage the entire software development lifecycle.\n\nThis combination, together with a [GitOps approach](https://about.gitlab.com/topics/gitops/), which aims to automate the provisioning of modern cloud infrastructures, creates an agile environment for application development and deployment, thus making it possible to provide powerful, flexible, and scalable software. For more details, discover all [GitLab solutions to launch an application with Kubernetes](https://about.gitlab.com/solutions/kubernetes/).\n\n## Kubernetes FAQ\n### What are the competing solutions to K8s?\n\nThere are several alternatives to Kubernetes, including Docker Swarm, and Marathon. However, Kubernetes is considered the most mature and popular solution on the market. Its broad user base, abundant documentation, and active community support make Kubernetes an excellent choice for those looking to adopt a container orchestration system.\n\n### What is a Kubernetes cluster?\n\nA Kubernetes cluster is composed of a master node and several worker nodes. The master node is responsible for coordinating the tasks in the cluster, while the worker nodes execute these orchestration tasks and host the containers. K8s clusters are highly scalable – nodes can be added or removed to adapt cluster resources to the needs of the application.\n\n### How to get started with Kubernetes?\n\nTo begin, it is necessary to install the Kubernetes software on a compatible environment (Linux, macOS, or Windows). Kubernetes can be installed in a traditional hosting environment, but also in a cloud environment (Google Kubernetes Engine or Amazon EKS, for example). Users can download and install Kubernetes directly from their official site, and then proceed with the initial configuration necessary to connect the master and worker nodes. Once this step is completed, users are ready to deploy a first application using Kubernetes.\n\n### Why choose Kubernetes?\n\nKubernetes offers great flexibility and total portability between different cloud platforms or on-site infrastructures. By automating orchestration tasks, K8s helps to optimize resources, reduce operating costs, and free up time for developers and system administrators. Finally, the Kubernetes ecosystem is vast and is continuously developed by a large open-source community, enabling rapid innovation.\n\n## Learn more\n\n- [How to stream logs through the GitLab Dashboard for Kubernetes](https://about.gitlab.com/blog/how-to-stream-logs-through-the-gitlab-dashboard-for-kubernetes/)\n- [Kubernetes overview: Operate cluster data on the frontend](https://about.gitlab.com/blog/kubernetes-overview-operate-cluster-data-on-the-frontend/)\n- [Simplify your cloud account management for Kubernetes access](https://about.gitlab.com/blog/simplify-your-cloud-account-management-for-kubernetes-access/)\n",[780,675],"2024-08-22",{"slug":981,"featured":6,"template":679},"kubernetes-the-container-orchestration-solution","content:en-us:blog:kubernetes-the-container-orchestration-solution.yml","Kubernetes The Container Orchestration Solution","en-us/blog/kubernetes-the-container-orchestration-solution.yml","en-us/blog/kubernetes-the-container-orchestration-solution",{"_path":987,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":988,"content":994,"config":1002,"_id":1004,"_type":16,"title":1005,"_source":17,"_file":1006,"_stem":1007,"_extension":20},"/en-us/blog/a-ci-component-builders-journey",{"title":989,"description":990,"ogTitle":989,"ogDescription":990,"noIndex":6,"ogImage":991,"ogUrl":992,"ogSiteName":713,"ogType":714,"canonicalUrls":992,"schema":993},"A CI/CD component builder's journey","Learn how a creator of shared, includable templates upskilled by migrating the templates to GitLab CI/CD components and the CI/CD Catalog.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663857/Blog/Hero%20Images/blog-image-template-1800x945__12_.png","https://about.gitlab.com/blog/a-ci-component-builders-journey","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A CI/CD component builder's journey\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"}],\n        \"datePublished\": \"2024-06-04\",\n      }",{"title":989,"description":990,"authors":995,"heroImage":991,"date":997,"body":998,"category":14,"tags":999},[996],"Darwin Sanoy","2024-06-04","I've always found it fascinating that my father, a heavy-duty mechanic by trade, would make his own tools for challenging jobs for which his industry had not yet built a fit-to-purpose tool. Little did I realize I'd become a tool builder in IT, which has been one of my loves for many years now.\n\nI have been building GitLab CI/CD includable, shared templates since starting with GitLab over four years ago. They were designed in a specific way for others to depend directly on them – similar to the dependency managers you see in application languages like Node.js NPM, Python Pypi, and .NET NuGet.\n\nGitLab itself has had long experience in building these shared CI dependencies through [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) and all of our security scanning suite of tools.\n\nWith the introduction of [GitLab CI/CD Catalog](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/), this long-running approach is formalized into a way for everyone to publish GitLab CI/CD components for use by anyone in the world.\n\nSome of they key upgrades compared to the shared templates approach include:\n\n- **Independent component versions** are a new versioning mechanism that no longer relies on inheriting containers versions. GitLab CI/CD component versions bundle together the CI code and any number of containers (or no containers) behind a single CI/CD component version. The concepts of stable, production-grade DevSecOps require the ability to peg dependency versions in automation – for exactly the same reasons and benefits that this is done in production-grade application code.\n\n- **Global visibility (with control)** is available through the catalog at GitLab.com (or global to your company on a self-managed instance). Individual component visibility is also subject to the security settings of it's source project - so you can publish components to secure groups.\n\n- **Catalog metadata,** like most code-sharing mechanisms, is needed data to make decisions about which components to use.\n\n## Let's show some code\n\nI much prefer to show than tell, so let's look at a few component examples - all of which also publish their sources publicly (click on the title to access the component).\n\n### 1. [Hello World](https://gitlab.com/explore/catalog/guided-explorations/ci-components/hello-world)\nI noticed that there was not yet a Hello World component that could show the minimum viable component, both the results and the source. This particular example shows how to \"componentize\" just CI code.\n\n### 2. [Hello World Container](https://gitlab.com/explore/catalog/guided-explorations/ci-components/hello-world-container)\nFrequently a CI/CD component will require a container to be fully functional. This example includes a container that is published in the same project as the component itself.\n\n### 3. [GitVersion Ultimate Auto Semversioning](https://gitlab.com/explore/catalog/guided-explorations/ci-components/ultimate-auto-semversioning)\n\nThis component automates the venerable \"GitVersion\" utility, which completely automates selecting the next semversion for your software without having to store the last version – even for busy repositories where many production-possible candidates are being worked on at once. One of the building principles this component follows is the principle of \"least configuration\" or \"default to doing the most useful thing with zero configuration.\" In this case, if your project does not contain a `GitVersion.yml`, the component creates the one that an individual unfamiliar with GitVersion might find to be the most useful starting point.\n\n### 4. [Amazon CodeGuru Secure SAST Scanner](https://gitlab.com/explore/catalog/guided-explorations/ci-components/aws/amazon-codeguru-secure-sast)\nThis component is a security scanner and, as such, follows some security scanning best practices I have implemented during recent years. For instance, if it detects that you are licensed for GitLab Ultimate, it has the scanner output GitLab's SAST JSON format, which integrates the findings just like native GitLab scanner findings. The findings appear in MRs and dashboards and can be the target of security policy merge approvals. If, however, you are not licensed for GitLab Ultimate, the scanner outputs JUNIT XML so that you have some basic, non-diffed findings visualization in the pipeline \"Test Results\" tab. It also only activates if there are file types it can scan and disables if the GitLab SAST_DISABLED property is turned on.\n\n### 5. [Checkov IaC SAST](https://gitlab.com/explore/catalog/guided-explorations/ci-components/checkov-iac-sast)\nCheckov IaC SAST is another security scanner component that also follows the above security scanner principles, but specifically for the file types it is capable of scanning. A critical best practice of many of these components is pegging container tags for stability - but doing so through a \"component input\" with a default value. This allows component users to test with and peg to a newer or older version than you last tested with. So your shared dependency then offers stability, but with flexibility.\n\n### 6. [Super-Linter](https://gitlab.com/guided-explorations/ci-components/super-linter)\nSuper-Linter is a community-driven conglomeration of many linters for many languages. It originally started life as a GitHub Action, so this particular example demonstrates some of the ease of porting open source GitHub Actions to GitLab CI/CD components. A best practice aspect to many of my components is to always link to working example code with the component in action. This also allows you to do easy testing when performing updates.\n\n### 7. [Kaniko](https://gitlab.com/explore/catalog/guided-explorations/ci-components/kaniko)\nKaniko is a container that can build containers without Docker-in-Docker (DinD) privileged mode requirement. This component supports many OpenContainers labels and multi-arch builds.\n\n### 8. [CI Component Publishing Utilities](https://gitlab.com/explore/catalog/guided-explorations/ci-components/ci-component-pub)\nAs I built more components, I noticed that my \"component publishing CI code\" was being duplicated many times - and that makes it a candidate for becoming a component itself. All the other components here leverage this component. It also uses components itself, so it uses **GitVersion Ultimate Auto Semversioning** to get the next version.\n\nAnd if you're wondering, yes, CI Component Publishing Utilities publishes itself. In many of my components I have expanded the standard \"Inputs\" README section to \"Inputs and Configuration\" and I have added a column to show whether configurations are happening via inputs or variables. While you generally want to favor inputs, there are times when variables give more flexibility or you just want to document that the user can get perform key configurations of the underlying utilities via environment variables that the utility already supports. CI Component Publishing Utilities also uses the **Kaniko** CI component to build a container with the same version if it finds a Dockerfile at the root of your project (or you tell it where one is with a variable). This synchronizes the version of components and containers that support them. It also handles multi-arch container builds - see the documentation linked above to learn more!\n\n## Getting started with component templates\n\nThe Hello World components function as my own personal templates for starting a new component. They incorporate the CI Component Publishing Utilities and a reasonably good README.\n\nFor components that contain only CI code, I start by copying the source of [Hello World](https://gitlab.com/explore/catalog/guided-explorations/ci-components/hello-world) and for ones that require a container, I start with [Hello World Container](https://gitlab.com/explore/catalog/guided-explorations/ci-components/hello-world-container). I generally copy just the source into a new project so that I have a clean commit history.\n\nWhen I feel the component is stable and well developed I do a manual pipeline run and force the version to 1.1.0 or greater. The CI Component Publishing Utilities will then auto-increment the version from there.\n\n## CI component Builders Guides and practices\n\n[Darwins CI Component Builders Guide](https://gitlab.com/guided-explorations/ci-components/gitlab-profile) - I was also interested in publishing my approach to building components and what better way to get visibility than as a CI/CD component? BTW, the [GitLab Pipeline Authoring](https://about.gitlab.com/direction/verify/pipeline_composition/) team that created the CI/CD component architecture and [CI/CD Catalog](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) has some great best practices published at [CI components best practices](https://docs.gitlab.com/ee/ci/components/#best-practices). The practices I publish reference these ones, but I also have quite a few I follow that are specific to my own lessons learned.\n\n## Finding the CI/CD components and their sources\n\nThe [GitLab CI/CD Catalog](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) is still undergoing innovation in searchability. However, the description from the source project is free-form searchable, so by including standard text in the descriptions of all my component source projects, I have created the ability for users to [find all of the ones I've created in the catalog](https://gitlab.com/explore/catalog?search=Part+of+the+DarwinJS+Builder+Component+Library).\n\nTo make my component source findable regardless of its location on GitLab.com:\n- I add a repository topic to all the projects called [DarwinJS Component Builder Library](https://gitlab.com/explore/projects/topics/DarwinJS+Component+Builder+Libary).\n- I tag with the organic tag I found called [`GitLab CICD Components`](https://gitlab.com/explore/projects/topics/GitLab+CICD+Components).\n\nBoth of the above techniques can help you provide an index to your components and their source if you are inclined to do so.\n\nI hope that my CI/CD component building journey will be helpful to you now and in the future.\n\n> Learn more about the CI/CD Catalog and components:\n>  \n> - [CI/CD Catalog goes GA: No more building pipelines from scratch](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/)\n> \n> - [FAQ: GitLab CI/CD Catalog](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/)\n>\n> - [Documentation: CI/CD components and CI/CD Catalog](https://docs.gitlab.com/ee/ci/components/)\n> \n> - [Introducing CI/CD components and how to use them in GitLab](https://about.gitlab.com/blog/introducing-ci-components/)\n>",[110,1000,1001],"CI","CD",{"slug":1003,"featured":6,"template":679},"a-ci-component-builders-journey","content:en-us:blog:a-ci-component-builders-journey.yml","A Ci Component Builders Journey","en-us/blog/a-ci-component-builders-journey.yml","en-us/blog/a-ci-component-builders-journey",{"_path":1009,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1010,"content":1016,"config":1022,"_id":1024,"_type":16,"title":1025,"_source":17,"_file":1026,"_stem":1027,"_extension":20},"/en-us/blog/a-beginners-guide-to-the-git-reftable-format",{"title":1011,"description":1012,"ogTitle":1011,"ogDescription":1012,"noIndex":6,"ogImage":1013,"ogUrl":1014,"ogSiteName":713,"ogType":714,"canonicalUrls":1014,"schema":1015},"A beginner's guide to the Git reftable format","In Git 2.45.0, GitLab upstreamed the reftable backend to Git, which completely changes how references are stored. Get an in-depth look at the inner workings of this new format.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664595/Blog/Hero%20Images/blog-image-template-1800x945__9_.png","https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A beginner's guide to the Git reftable format\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2024-05-30\",\n      }",{"title":1011,"description":1012,"authors":1017,"heroImage":1013,"date":1018,"body":1019,"category":14,"tags":1020},[718],"2024-05-30","Until recently, the \"files\" format was the only way for Git to store references. With the [release of Git 2.45.0](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/), Git can now store references in a \"reftable\" format. This new format is a binary format that is quite a bit more complex, but that complexity allows it to address several shortcomings of the \"files\" format. The design goals for the \"reftable\" format include:\n\n- Make the lookup of a single reference and iteration through ranges of references as efficient and fast as possible.\n- Support for consistent reads of references so that Git never reads an in-between state when an update to multiple references has been applied only partially.\n- Support for atomic writes such that updating multiple references can be implemented as an all-or-nothing operation.\n- Efficient storage of both refs and the reflog.\n\nIn this article, we will go under the hood of the \"reftable\" format to see exactly how it works.\n\n## How Git stores references\n\nBefore we dive into the details of the \"reftable\" format, let's quickly recap how Git has historically stored references. If you are already familiar with this, you can skip this section.\n\nA Git repository keeps track of two important data structures:\n\n- [Objects](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects), which contain the actual data of your repository. This includes commits, the directory tree structure, and the blobs that contain your source code. Objects point to each other, forming an object graph. Furthermore, each object has an object ID that uniquely identifies the object.\n\n- References, such as branches and tags, which are pointers into the object graph so that you can give objects names that are easier to remember and keep track of different tracks of your development history. For example, a repository may contain a `main` branch, which is a reference named `refs/heads/main` that points to a specific commit.\n\nReferences are stored in the reference database. Until Git 2.45.0, there was only the \"files\" database format. In this format, every reference is stored as a normal file that contains either one of the following:\n\n- A regular reference that contains the object ID of the commit it points to.\n- A symbolic reference that contains the name of another reference, similar to how a symbolic link points to another file.\n\nAt regular intervals, these references get packed into a single `packed-refs` file to make lookups more efficient.\n\nThe following examples should give an idea of how the \"files\" format operates:\n\n```shell\n$ git init .\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 6917c17] Initial commit\n\n# HEAD is a symbolic reference pointing to refs/heads/main.\n$ cat .git/HEAD\nref: refs/heads/main\n\n# refs/heads/main is a regular reference pointing to a commit.\n$ cat .git/refs/heads/main\n6917c178cfc3c50215a82cf959204e9934af24c8\n\n# git-pack-refs(1) packs these references into the packed-refs file.\n$ git pack-refs --all\n$ cat .git/packed-refs\n# pack-refs with: peeled fully-peeled sorted\n6917c178cfc3c50215a82cf959204e9934af24c8 refs/heads/main\n```\n\n## High-level structure of reftables\n\nAssuming that you've got Git 2.45.0 or newer installed, you can create a repository with the \"reftable\" format by using the `--ref-format=reftable` switch:\n\n```shell\n$ git init --ref-format=reftable .\nInitialized empty Git repository in /tmp/repo/.git/\n$ git rev-parse --show-ref-format\nreftable\n\n# Irrelevant files have been removed for ease of understanding.\n$ tree .git\n.git\n├── config\n├── HEAD\n├── index\n├── objects\n├── refs\n│   └── heads\n└── reftable\n\t├── 0x000000000001-0x000000000002-40a482a9.ref\n\t└── tables.list\n\n4 directories, 6 files\n```\n\nFirst, looking at the repository configuration, you will see it has an `extension.refstorage` key:\n\n```shell\n$ cat .git/config\n[core]\n    repositoryformatversion = 1\n    filemode = true\n    bare = false\n    logallrefupdates = true\n[extensions]\n    refstorage = reftable\n```\n\nThis configuration indicates to Git that the repository has been initialized with the \"reftable\" format and tells Git to use the \"reftable\" backend to access it.\n\nWeirdly enough, the repository still has a few files that look as if the \"files\" backend was in use:\n\n- `HEAD` would usually be a symbolic reference pointing to your currently checked-out branch. While it is not used by the \"reftable\" backend, it is required for Git clients to detect the directory as a Git repository. Therefore, when using the \"reftable\" format, `HEAD` is a stub with contents `ref: refs/heads/.invalid`.\n\n- `refs/heads` is a file with contents `this repository uses the reftable format`. Git clients that do not know about the \"reftable\" format would usually expect this path to be a directory. Consequently, creating this path as a file intentionally causes such older Git clients to fail if they tried to access the repository with the \"files\" backend.\n\nThe actual references are stored in the `reftable/` directory:\n\n```shell\n$ tree .git/reftable\n.git/reftable/\n├── 0x000000000001-0x000000000001-794bd722.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000001-794bd722.ref\n```\n\nThere are two files here:\n\n- `0x000000000001-0x000000000001-794bd722.ref` is a table containing references and the reflog data in a binary format.\n\n- `tables.list` is, well, a list of tables. In the current state of the repository, the file contains a single line, which is the name of the table. This file tracks the current set of active tables in the \"reftable\" database and is updated whenever new tables get added to the repository.\n\nUpdating a reference creates a new table:\n\n```shell\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 1472a58] Initial commit\n\n$ tree .git/reftable\n.git/reftable/\n├── 0x000000000001-0x000000000002-eb87d12b.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000002-eb87d12b.ref\n```\n\nAs you can see, the previous table has been replaced with a new one. Furthermore, the `tables.list` file has been updated to contain the new table.\n\n## The structure of a table\n\nAs mentioned earlier, the actual data of the reference database is contained in tables. Roughly speaking, a table is split up into multiple sections:\n\n- The \"header\" contains metadata about the table. Along with some other information, this includes the version of the format, the block size, and the hash function used by the repository (for example, SHA1 or SHA256).\n- The \"ref\" section contains your references. These records have a key that equals the reference name and point to either an object ID for regular references, or to another reference for symbolic references.\n- The \"obj\" section contains reverse mapping from object IDs to the references that point to those object IDs. These allow Git to efficiently look up which references point to a given object ID.\n- The \"log\" section contains your reflog entries. These records have a key that equals the reference name plus an index that represents the number of the log entry. Furthermore, they contain the old and new object IDs as well as the message for that reflog entry.\n- The \"footer\" contains offsets to the various sections.\n\n![long table with all the reftable sections](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_1_-_Reftable_overview.svg)\n\nEach of the section types are structured in a similar manner. Sections contain a set of records that are sorted by each record's key. For example, when you have two ref records `refs/heads/aaaaa` and `refs/heads/bbb`, you have two ref records with these reference names as their respective keys, and `refs/heads/aaaaa` would come before `refs/heads/bbb`.\n\nFurthermore, each section is divided into blocks of a fixed length. This block length is encoded in the header and serves two purposes:\n\n- Given the start of the section as well as the block size, the reader implicitly knows where each of the blocks starts. This allows Git to easily seek into the middle of a section without reading preceding blocks, which enables binary searches over blocks to speed up the lookup of records.\n- It ensures that the reader knows how much data to read from the disk at a time. Consequently, the block size is by default set to 4KiB, which is the most common sector size for hard disks. The maximum block size is 16MB.\n\nWhen we peek into, for example, a \"ref\" section, it looks roughly like the following graphic. Note how its records are ordered lexicographically inside the blocks, but also across the blocks.\n\n![reference block uncompressed](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_2_-_Ref_block_uncompressed.svg)\n\nEquipped with the current information, we can locate a record by using the following steps:\n\n1. Perform a binary search over the blocks by looking at the keys of their respective first records, identifying the block that must contain our record.\n\n2. Perform a linear search over the records in that block.\n\nBoth of these steps are still somewhat inefficient. If we have many blocks we may have to read logarithmically many of them in our binary search to find the desired one. And when blocks contain many records, we potentially have to read all of them during the linear search.\n\nThe \"reftable\" format has additional built-in mechanisms to address these performance concerns. We will touch on these over the next few sections.\n\n### Prefix compression\n\nAs you may have noticed, all of the record keys share the same prefix `refs/`. This is a common thing in Git:\n\n- All branches start with `refs/heads/`.\n- All tags start with `refs/tags/`.\n\nTherefore, we expect that subsequent records will most likely share a significant prefix of their key. This is a good opportunity to save some precious disk space. Because we know that most keys will share a common prefix, it makes sense to optimize for this.\n\nThe optimization uses prefix compression. Every record encodes a prefix length that tells the reader how many bytes to reuse from the key of the preceding record. If we have two records, `refs/heads/a` and `refs/heads/b`, the latter can be encoded by specifying a prefix length of 11 and then only storing the suffix `b`. The reader will then take the first 11 bytes of `refs/heads/a`, which is `refs/heads/`, and append the suffix `b` to it.\n\n![prefix compression](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_3_-_Ref_block_prefix_compression.svg)\n\n### Restart points\n\nAs explained earlier, the best way to search for a reference in a block with our current understanding of the \"reftable\" format is to do a linear search. This is because records do not have a fixed length, so it is impossible for us to tell where records would start without scanning through the block from the beginning. Also, even if records were of fixed length, we would not be able to seek into the middle of a block because the prefix compression also requires us to read preceding records.\n\nDoing a linear search would be quite inefficient because blocks may contain hundreds or even thousands of records. To address this issue, the \"reftable\" format encodes so-called restart points into every block. Restart points are uncompressed records where the prefix compression is reset. Consequently, records at restart points always contain their full key and it becomes possible to directly seek to and read the record without having to read preceding records. These restart points are listed in the footer of each block.\n\nEquipped with this information, we can avoid performing a linear search over the block. Instead, we can now do a binary search over the restart points where we search for the first restart point with a key larger than the sought-after key. From there, it follows that the desired record must be located in the section spanning from the _preceding_ restart point to the identified one.\n\nThus, our initial procedure to look up a record (binary search for the block, linear search for the record) is now:\n\n1. Perform a binary search over the blocks, identifying the block that must contain our record.\n\n2. Perform a binary search over the restart points, identifying the sub-section of the block that must contain our record.\n\n3. Perform a linear search over the records in that sub-section.\n\n![Linear search for a record](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_4_-_Restart_points.svg)\n\n### Indices\n\nWhile the search for records inside a block is now reasonably efficient, it's still inefficient to locate the block itself. A binary search may be reasonably performant when you have a couple of blocks, but repositories with millions of references may have hundreds or even thousands of blocks. Without any additional data structure, this would cause logarithmically many disk seeks on average.\n\nTo avoid this, every section may be followed by an index section that provides an efficient way to look up a block. Each index record holds the following information:\n\n- The location of the block that it is indexing.\n- The key of the last record of the block that it is indexing.\n\nWith three or less blocks, a binary search will always require, at most, two disk reads to find the desired target block. This is the same number of reads we would have to do with an index: one to read the index itself and one to read the desired block. Consequently, indices are only written when they would actually save some reads, which is the case with four or more indexed blocks.\n\nNow the question is: What happens when the index itself becomes so large that it spans over multiple blocks? You might have guessed it: We write another index that indexes the index. These multi-level indices really only become necessary once you have repositories with hundreds of thousands of references.\n\nEquipped with these indices, we can now make the procedure to look up records even more efficient:\n1. Determine whether there is an index by looking at the footer of the table.\n\t- If there is one, perform a binary search over the index to find the desired block. This block may point into an index block itself, in which case we need to repeat this step until we hit a record of the desired type.\n\t- Otherwise, perform a binary search over the blocks as we did before.\n2. Perform a binary search over the restart points, identifying the sub-section of the block that must contain our record.\n3. Perform a linear search over the records in that sub-section.\n\n## Multiple tables\n\nUp to this point, we have only discussed how to read a _single_ table. But as the name `tables.list` indicates, you can actually have a list of tables in your \"reftable\" database.\n\nEvery time you update a reference in your repository, a new table is written and appended to `tables.list`. Thus, you will eventually end up with multiple tables:\n\n```shell\n$ tree .git/reftable/\n.git/reftable/\n├── 0x000000000001-0x000000000007-8dcd8a77.ref\n├── 0x000000000008-0x000000000008-30e0f6f6.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000007-8dcd8a77.ref\n0x000000000008-0x000000000008-30e0f6f6.ref\n```\n\nReading the actual state of a repository requires us to merge these multiple tables into a single virtual table.\n\nYou might be wondering: If a table is written for each reference update and the same reference is updated multiple times, how does the \"reftable\" format know the most up-to-date value of a given reference? Intuitively, one could assume the value would be the one from the newest table containing the reference.\n\nIn fact, every single record has a so-called update index that encodes the \"priority\" of a record. For example, if two ref records with the same name exist, then the one with the higher update index overrides the one with the lower update index.\n\nThese update indices are visible in the file structure above. The long hex strings (for example `0x000000000001`) are the update indices, where the left-hand side of the table name is the minimum update index contained in the table and the right-hand is the maximum update index.\n\nMerging the tables then happens via a [priority queue](https://en.wikipedia.org/wiki/Priority_queue) that is ordered by the key of the ref record as well as its update index. Assuming we want to scan through all ref records, we would:\n\n1. For every table, add its first record to the priority queue.\n\n![Adding first record to the priority queue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_5_-_Priority_queue_1.svg)\n\n2. Yield the head of the priority queue. Because the queue is ordered by update index, it must be the most up-to-date version. Add the next item from that table to the priority queue.\n\n![Yielding the head of the priority queue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_6_-_Priority_queue_2.svg)\n\n3. Drop all records from the queue that have the same name. These records are shadowed, which means that they will not be shown. For each table for which we are dropping records, add the next record to the priority queue.\n\n![Dropping all records from queue that have the same name](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_7_-_Priority_queue_3.svg)\n\nNow we can rinse and repeat to read records for other keys.\n\nTables may contain special \"tombstone\" records that mark a record as having been deleted. This allows us to delete records without having to rewrite all tables to not contain the record anymore.\n\n### Auto-compaction\n\nWhile the idea behind the priority queue is simple enough, it would be rather inefficient to merge together hundreds or even only dozens of tables in this way. So while it is true that every update to your references appends a new table to your `tables.list` file, it is only part of the story.\n\nThe other part is auto-compaction: After a new table has been appended to the list of tables, the \"reftable\" backend checks whether some of the tables should be merged. This is done by using a simple heuristic: We check whether the list of tables forms a [geometric sequence](https://en.wikipedia.org/wiki/Geometric_progression) with the file sizes. Every table `n` must be at least twice as large as the next-most-recent table `n + 1`. If that geometric sequence is violated, the backend will compact tables so that the geometric sequence is restored.\n\nOver time, this will lead to structures that look like the following:\n\n```shell\n$ du --apparent-size .git/reftable/*\n429    .git/reftable/0x000000000001-0x00000000bd7c-d9819000.ref\n101    .git/reftable/0x00000000bd7d-0x00000000c5ac-c34b88a4.ref\n32    .git/reftable/0x00000000c5ad-0x00000000cc6c-60391f53.ref\n8    .git/reftable/0x00000000cc6d-0x00000000cdc1-61c30db1.ref\n3    .git/reftable/0x00000000cdc2-0x00000000ce67-d9b55a96.ref\n1    .git/reftable/0x00000000ce68-0x00000000ce6b-44721696.ref\n1    .git/reftable/tables.list\n```\n\nNote how for every single table, the property `size(n) > size(n+1) * 2` holds.\n\nOne of the consequences of auto-compaction is that the \"reftable\" backend maintains itself. We no longer have to run `git pack-refs` in a repository.\n\n## Want to learn more?\n\nYou should now have a good understanding of how the new \"reftable\" format works under the hood. If you want to dive even deeper into the format, you can refer to the [technical documentation](https://git-scm.com/docs/reftable) provided by the Git project.\n\n> Read our [Git 2.45.0 recap](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/) to find out what else is in this version of Git.",[699,781,675,1021],"performance",{"slug":1023,"featured":92,"template":679},"a-beginners-guide-to-the-git-reftable-format","content:en-us:blog:a-beginners-guide-to-the-git-reftable-format.yml","A Beginners Guide To The Git Reftable Format","en-us/blog/a-beginners-guide-to-the-git-reftable-format.yml","en-us/blog/a-beginners-guide-to-the-git-reftable-format",{"_path":1029,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1030,"content":1036,"config":1041,"_id":1043,"_type":16,"title":1044,"_source":17,"_file":1045,"_stem":1046,"_extension":20},"/en-us/blog/whats-new-in-git-2-45-0",{"title":1031,"description":1032,"ogTitle":1031,"ogDescription":1032,"noIndex":6,"ogImage":1033,"ogUrl":1034,"ogSiteName":713,"ogType":714,"canonicalUrls":1034,"schema":1035},"What’s new in Git 2.45.0?","Here are some highlights of contributions from GitLab's Git team and the wider Git community to the latest Git release, including reftables and better tooling for references.\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659507/Blog/Hero%20Images/AdobeStock_623844718.jpg","https://about.gitlab.com/blog/whats-new-in-git-2-45-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What’s new in Git 2.45.0?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2024-04-30\",\n      }",{"title":1031,"description":1032,"authors":1037,"heroImage":1033,"date":1038,"body":1039,"category":14,"tags":1040},[718],"2024-04-30","The Git project recently released [Git Version 2.45.0](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/). Let's look at the highlights of this release, which includes contributions from GitLab's Git team and the wider Git community.\n\n## Reftables: A new backend for storing references\n\nEvery Git repository needs to track two basic data structures:\n- The object graph that stores the data of your files, the directory structure, commit messages, and tags.\n- References that are pointers into that object graph to associate specific objects with a more accessible name. For example, a branch is a reference whose name starts with a `refs/heads/` prefix.\n\nThe on-disk format of how references are stored in a repository has remained largely unchanged since Git’s inception and is referred to as  the \"files\" format. Whenever you create a reference, Git creates a so-called \"loose reference\" that is a plain file in your Git repository whose path matches the ref name. For example:\n\n```shell\n$ git init .\nInitialized empty Git repository in /tmp/repo/.git/\n\n# Updating a reference will cause Git to create a \"loose ref\". This loose ref is\n# a simple file which contains the object ID of the commit.\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) c70f266] Initial commit\n$ cat .git/refs/heads/main\nc70f26689975782739ef9666af079535b12b5946\n\n# Creating a second reference will end up with a second loose ref.\n$ git branch feature\n$ cat .git/refs/heads/feature\nc70f26689975782739ef9666af079535b12b5946\n$ tree .git/refs\n.git/refs/\n├── heads\n│   ├── feature\n│   └── main\n└── tags\n\n3 directories, 2 files\n```\n\nEvery once in a while, Git packs those references into a \"packed\"\nfile format so that it becomes more efficient to look up references. For example:\n\n```shell\n# Packing references will create \"packed\" references, which are a sorted list of\n# references. The loose reference does not exist anymore.\n$ git pack-refs --all\n$ cat .git/refs/heads/main\ncat: .git/refs/heads/main: No such file or directory\n$ cat .git/packed-refs\n# pack-refs with: peeled fully-peeled sorted\nc70f26689975782739ef9666af079535b12b5946 refs/heads/feature\nc70f26689975782739ef9666af079535b12b5946 refs/heads/main\n```\n\nWhile this format is rather simple, it has limitations:\n- In large mono repos with many references, we started to hit scalability issues. Deleting references is especially inefficient because the entire “packed-refs” file must be rewritten to drop the deleted reference. In our largest repositories, this can lead to rewriting multiple gigabytes of data on every reference deletion.\n- It is impossible to perform an atomic read of references without blocking concurrent writers because you have to read multiple files to figure out all references.\n- It is impossible to perform an atomic write because it requires you to create or update multiple files, which cannot be done in a single step.\n- Housekeeping of references does not scale well because you have to rewrite the full \"packed-refs\" file.\n- Because loose references use the filesystem path as their name, they are subject to filesystem-specific behavior. For example, case-insensitive file systems cannot store references for which only the case differs.\n\nTo address these issues, Git v2.45.0 introduces a new \"reftable\" backend, which uses a new binary format to store references. This new backend has been in development for a very long time. It was initially proposed by [Shawn Pearce](https://sfconservancy.org/blog/2018/jan/30/shawn-pearce/) in July 2017 and was initially implemented in [JGit](https://www.eclipse.org/jgit/). It is used extensively by the [Gerrit project](https://www.gerritcodereview.com/). In 2021, [Han-Wen Nienhuys](https://hanwen.home.xs4all.nl/) upstreamed the library into Git that allows it to read and write the [reftable format](https://git-scm.com/docs/reftable).\n\nThe new \"reftable\" backend that we upstreamed in Git v2.45.0 now finally brings together the reftable library and Git such that it is possible to use the new format as storage backend in your Git repositories.\n\nAssuming that you run at least Git v2.45.0, you can create new repositories with the \"reftable\" format by passing the `--ref-format=reftable` switch to either `git-init(1)` or `git-clone(1)`. For example:\n\n```shell\n$ git init --ref-format=reftable .\nInitialized empty Git repository in /tmp/repo/.git/\n$ git rev-parse --show-ref-format\nreftable\n$ find -type f .git/reftable/\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n.git/reftable/tables.list\n\n$ git commit --allow-empty --message \"Initial commit\"\n$ find -type f .git/reftable/\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n.git/reftable/0x000000000002-0x000000000002-87006b81.ref\n.git/reftable/tables.list\n```\n\nAs you can see, the references are now stored in `.git/reftable` instead of in the `.git/refs` directory. The references and the reference logs are stored in “tables,” which are the files ending with `.ref`, whereas the `tables.list` file contains the list of all tables that are currently active. The technical details of how this work will be explained in a separate blog post. Stay tuned!\n\nThe “reftable” backend is supposed to be a  drop-in replacement for the “files” backend. Hence, from a user’s perspective, everything should just work the same.\n\nThis project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab). Credit also goes to Shawn Pearce as original inventor of the format and Han-Wen Nienhuys as the author of the reftable library.\n\n## Better tooling for references\n\nWhile the \"reftable\" format solves many of the issues we have, it also\nintroduces some new issues. One of the most important issues is accessibility of the data it contains.\n\nWith the \"files\" backend, you can, in the worst case, use your regular Unix tools to inspect the state of references. Both the \"packed\" and the \"loose\" references contain human-readable data that one can easily make sense of. This is different with the \"reftable\" format, which is a binary format. Therefore, Git needs to provide all the necessary tooling to extract data from the new \"reftable\" format.\n\n### Listing all references\n\nThe first problem we had is that it is basically impossible to learn about all the references that a repository knows about. This is somewhat puzzling at first: you can create and modify references via Git, but it cannot exhaustively list all references that it knows about?\n\nIndeed, the \"files\" backend can't. While it can trivially list all \"normal\"\nreferences that start with the `refs/` prefix, Git also uses so-called\n[pseudo refs](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpseudorefapseudoref). These files live directly in the root of the Git directory and would be files like, for example, `.git/MERGE_HEAD`. The problem here is that those pseudo refs live next to other files that Git stores like, for example, `.git/config`.\n\nWhile some pseudo refs are well-known and thus easy to identify, there is\nin theory no limit to what references Git can write. Nothing stops you from\ncreating a reference called \"foobar\".\n\nFor example:\n\n```shell\n$ git update-ref foobar HEAD\n$ cat .git/foobar\nf32633d4d7da32ccc3827e90ecdc10570927c77d\n```\n\nNow the problem that the \"files\" backend has is that it can only enumerate\nreferences by scanning through directories. So to figure out that\n`.git/foobar` is in fact a reference, Git would have to open the file and check whether it is formatted like a reference or not.\n\nOn the other hand, the \"reftable\" backend trivially knows about all references that it contains: They are encoded in its data structures, so all it needs to do is to decode those references and return them. But because of the restrictions of the \"files\" backend, there is no tooling that would allow you to learn about all references that exist.\n\nTo address the issue, we upstreamed a new flag to `git-for-each-ref(1)` called `--include-root-refs`, which will cause it to also list all references that exist in the root of the reference naming hierarchy. For example:\n\n```shell\n$ git for-each-ref --include-root-refs\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    HEAD\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    MERGE_HEAD\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    refs/heads/main\n```\n\nFor the \"files\" backend, this new flag is handled on a best-effort basis where we include all references that match a known pseudo ref name. For the \"reftable\" backend, we can simply list all references known to it.\n\nThis project was led by [Karthik Nayak](https://gitlab.com/knayakgl).\n\n### Listing all reflogs\n\nWhenever you update branches, Git, by default, tracks those branch updates in a so-called reflog. This reflog allows you to roll back changes to that branch in case you performed an unintended change and can thus be a very helpful tool.\n\nWith the \"files\" backend, those logs are stored in your `.git/logs` directory:\n\n```shell\n$ find -type f .git/logs/\n.git/logs/HEAD\n.git/logs/refs/heads/main\n```\n\nIn fact, listing files in this directory is the only way for you to learn what references actually have a reflog in the first place. This is a problem for the \"reftable\" backend, which stores those logs together with the references. Consequently, there doesn't exist any way for you to learn about which reflogs exist in the repository at all anymore when you use the \"reftable\" format.\n\nThis is not really the fault of the \"reftable\" format though, but an omission in the tooling that Git provides. To address the omission, we introduced a new `list` subcommand for `git-reflog(1)` that allows you to list all existing reflogs:\n\n```shell\n$ git reflog list\nHEAD\nrefs/heads/main\n```\n\nThis project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n### More efficient packing of references\n\nTo stay efficient, Git repositories need regular maintenance. Usually,\nthis maintenance is triggered by various Git commands that write data into the Git repositories by executing `git maintenance run --auto`. This command \nonly optimizes data structures that actually need to be optimized so that Git doesn’t waste compute resources.\n\nOne data structure that gets optimized by Git's maintenance is the reference\ndatabase, which is done by executing `git pack-refs --all`. For the \"files\"\nbackend, this means that all references get repacked into the \"packed-refs\" file and the loose references get deleted, whereas for the \"reftable\" backend all the tables will get merged into a single table.\n\nFor the \"files\" backend, we cannot reasonably do much better. Given that we have to rewrite the whole \"packed-refs\" file anyway, it makes sense that we would want to pack _all_ loose references.\n\nBut for the \"reftable\" backend this is suboptimal as the \"reftable\" backend is self-optimizing. Whenever Git appends a new table to the \"reftable\" backend, it will perform auto-compaction and merge tables together as needed. Consequently, the reference database should always be in a well-optimized state and thus merging all tables together is a wasted effort.\n\nIn Git v2.45.0, we thus introduced a new `git pack-refs --auto` mode, which asks the reference backend to optimize on an as-needed basis. While the \"files\" backend continues to work the same even with the `--auto` flag set, the \"reftable\" backend will use the same heuristics as it already uses for its auto-compaction. In practice, this should be a no-op in most cases.\n\nFurthermore, `git maintenance run --auto` has been adapted to pass the `-tauto` flag to `git-pack-refs(1)` to make use of this new mode by default.\n\nThis project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Read more\n\nThis blog post put a heavy focus on the new \"reftable\" backend, which allows us to scale better in large repositories with many references, as well as related tooling that we have introduced alongside it to make it work well. There, of course, have been various performance improvements, bug fixes and smaller features introduced with this Git release by the wider Git community, as well. You can learn about these from the [official release announcement](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/) of the Git project.\n\n## GitLab's previous Git release contributions\n* [GitLab's contributions to Git 2.44.0](https://about.gitlab.com/blog/gitlabs-contributions-to-git-2-44-0/)\n* [GitLab's contributions to Git 2.43.0](https://about.gitlab.com/blog/the-contributions-we-made-to-the-git-2-43-release/)\n* [GitLab's contributions to Git 2.42.0](https://about.gitlab.com/blog/contributions-to-git-2-42-release/)\n* [GitLab's contributions to Git 2.41.0](https://about.gitlab.com/blog/contributions-to-latest-git-release/)\n",[699,268],{"slug":1042,"featured":6,"template":679},"whats-new-in-git-2-45-0","content:en-us:blog:whats-new-in-git-2-45-0.yml","Whats New In Git 2 45 0","en-us/blog/whats-new-in-git-2-45-0.yml","en-us/blog/whats-new-in-git-2-45-0",{"_path":1048,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1049,"content":1055,"config":1060,"_id":1062,"_type":16,"title":1063,"_source":17,"_file":1064,"_stem":1065,"_extension":20},"/en-us/blog/gitlabs-contributions-to-git-2-44-0",{"title":1050,"description":1051,"ogTitle":1050,"ogDescription":1051,"noIndex":6,"ogImage":1052,"ogUrl":1053,"ogSiteName":713,"ogType":714,"canonicalUrls":1053,"schema":1054},"GitLab's contributions to Git 2.44.0","Find out the topics that GitLab’s Git team – as well as the wider community – contributed to the latest Git release, including fast scripted rebases via git-replay.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666069/Blog/Hero%20Images/AdobeStock_639935439.jpg","https://about.gitlab.com/blog/gitlabs-contributions-to-git-2-44-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab's contributions to Git 2.44.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2024-02-26\",\n      }",{"title":1050,"description":1051,"authors":1056,"heroImage":1052,"date":1057,"body":1058,"category":14,"tags":1059},[718],"2024-02-26","The Git project recently released [Git 2.44.0](https://git-scm.com/downloads). In this blog post, we will highlight the contributions made by GitLab's Git team, as well as those from the wider Git community.\n\n## Fast scripted rebases via `git-replay`\n\nThe `git-rebase` command can be used to reapply a set of commits onto a different base commit. This can be quite useful when you have a feature branch where the main branch it was originally created from has advanced since creating the feature branch.\n\nIn this case, `git-rebase` can be used to reapply all commits of the feature branch onto the new commits of the main branch.\n\nSuppose you have the following commit history with the main development branch `main` and your feature branch `feature`:\n\n![main and feature branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678099/Blog/Content%20Images/Screenshot_2024-02-20_at_2.15.37_PM.png)\n\nYou have originally created your feature branch from `m-2`, but since then the `main` branch has gained two additional commits. Now `git-rebase` can be used to reapply your commits `f-1` and `f-2` on top of the newest commit `m-4`:\n\n![applying git-rebase](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678099/Blog/Content%20Images/Screenshot_2024-02-20_at_2.16.28_PM.png)\n\nYou can see this functionality in GitLab when you create a merge request. When you want to reapply the commits of your merge request onto new commits in the target branch, all you have to do is [to create a comment that contains the `/rebase` command](https://docs.gitlab.com/ee/topics/git/git_rebase.html#rebase-from-the-ui). The magic then happens behind the scenes.\n\nThere is one problem though: `git-rebase` only works on repositories that have a worktree (a directory where a branch, tag or commit has been checked out). The repositories we host at GitLab are “bare” repositories, which don’t have a worktree. This means that the files and directories tracked by your commits are only tracked as Git objects in the `.git` directory of the repository. This is mostly done to save precious disk space and speed up operations.\n\nIn the past, we used [libgit2](https://libgit2.org/) to implement rebases. But for various reasons, we decided to remove this dependency in favor of only using Git commands to access Git repositories. But this created a problem for\nus because we could neither use libgit2 nor `git-rebase` to perform rebases. While we could create an ad-hoc worktree to use `git-rebase`, this would have been prohibitively expensive in large monorepos.\n\nLuckily, [Elijah Newren](https://www.linkedin.com/in/elijah-newren-0a41665/) has upstreamed a new merge algorithm called `merge-ort` in Git 2.33. Despite being significantly faster than the old `recursive` merge strategy in almost all cases, it also has the added benefit that it can perform merges in-memory. In practice, this also allows us to perform such rebases in-memory.\n\nEnter `git-replay`, which is a new command that does essentially the same thing as `git-rebase` but in-memory, thus not requiring a worktree anymore. This is an\nimportant building block to allow us to develop faster rebasing of merge requests in the future.\n\nYou may ask: Why a new command instead of updating `git-rebase`? The problem here was that `git-rebase` is essentially a user-focused command (also called a\n\"porcelain\" command in Git). Thus it performs several actions that are not required by a script at all, like, for example, executing hooks or checking out files into the worktree. The new `git-replay` command is a script-focused\ncommand (also called a \"plumbing\" command in Git) and has a different set of advantages and drawbacks. Furthermore, besides doing rebases, we plan to use it to do cherry-picks and reverts in the future, too.\n\nThis topic was a joint effort by [Elijah Newren](https://www.linkedin.com/in/elijah-newren-0a41665/) and\n[Christian Couder](https://www.gitlab.com/chriscool).\n\n## Commit-graph object existence checks\n\nYou may know that each commit can have an arbitrary number of parents:\n\n- The first commit in your repository has no parents. This is the \"root\" commit.\n- Normal commits have a single parent.\n- Merge commits have at least two, but sometimes even more than two parents.\n\nThis parent relationship is part of what forms the basis of Git's object model and establishes the object graph. If you want to traverse this object graph, Git must look up an entry point commit and from there walk the parent chain of commits.\n\nTo fully traverse history from the newest to the oldest commit, you must look up and parse all commit objects in between. Because repositories can consist of hundreds of thousands or even millions of such commits, this can be\nquite an expensive operation. But users of such repositories still want to be able to, for example, search for a specific commit that changes a specific file\nwithout waiting several minutes for the search to complete.\n\nThe Git project introduced a commit-graph data structure a long time ago that essentially caches a lot of the parsed information in a more accessible data structure. This commit-graph encodes the parent-child relation and some additional information, like, for example, a [bloom filter](https://en.wikipedia.org/wiki/Bloom_filter) of changed\nfiles.\n\nThis commit-graph is usually updated automatically during repository housekeeping. Because housekeeping only runs every so often, the commit-graph can be missing entries for recently added commits. This is perfectly fine and expected to happen, and Git knows to instead look up and parse the commit object in such a case.\n\nNow, the reverse case also theoretically exists: The commit-graph contains cached information of an object that does not exist anymore because it has been deleted without regenerating the commit-graph. The consequence would\nbe that lookups of this commit succeed even though they really shouldn't. To avoid this, in Git 2.43.0, we upstreamed a change into Git that detects commits\nthat exist in the commit-graph but no longer in the object database.\n\nThis change requires us to do an existence check for every commit that we parse via the commit-graph. Naturally, this change leads to a performance regression, which was measured to be about 30% in the worst case. This was\ndeemed acceptable though, because it is better to return the correct result slowly than to return the wrong result quickly. Furthermore, the commit-graph still results in a significant performance improvement compared to not using the commit-graph at all. To give users an escape hatch in case they do not want this performance regression, we also introduced a `GIT_COMMIT_GRAPH_PARANOIA` environment variable that can be used to disable this check.\n\nAfter this change was merged and released though, we heard of cases where the impact was even worse than 30%: counting the number of commits via `git rev-list --count` in the Linux repository regressed by about 100%. After some\ndiscussion upstream, we changed the default so that we no longer verify commit existence for the commit-graph to speed up such queries again. Because repository housekeeping should ensure that commit-graphs are consistent, this change should stop us from needlessly pessimizing this uncommon case.\n\nThis change was implemented by\n[Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Making Git ready for a new ref backend\n\nA common theme among our customers is that large monorepos with many refs create significant performance problems with many workloads. The range of problems here are manyfold, but the more refs a repository has, the more pronounced the problems become.\n\nMany of the issues are inherent limitations of the way Git stores refs. The so-called `files` ref backend uses a combination of two mechanisms:\n- \"Loose refs\" are simple files that contain the object ID they point to.\n- \"Packed refs\" are a single file that contains a collection of refs.\n\nWhenever you update or create a ref, Git creates them as a loose ref. Every once in a while, repository housekeeping then compresses all loose refs into the `packed-refs` file and deletes the corresponding loose refs. A typical repo looks as follows:\n\n```shell\n $ git init --ref-format=files repo\nInitialized empty Git repository in /tmp/repo/.git/\n $ cd repo/\n $ git commit --allow-empty --message \"initial commit\"\n $ tree .git/\n.git/\n├── config\n├── HEAD\n├── index\n└── refs\n\t├── heads\n\t│   └── main\n\t└── tags\n $ cat .git/HEAD\nref: refs/heads/main\n $ cat .git/refs/heads/main\nbf1814060ed3a88bd457ac4dca055d000ffe4482\n\n $ git pack-refs --all\n $ cat .git/packed-refs\n# pack-refs with: peeled fully-peeled sorted\nbf1814060ed3a88bd457ac4dca055d000ffe4482 refs/heads/main\n```\n\nWhile this model has served the Git project quite well, relying on a filesystem like this has several limitations:\n- Deleting a single ref requires you to rewrite the `packed-refs` file, which can be gigabytes in size.\n- It is impossible to do atomic reads because you cannot atomically scan multiple files at once when a concurrent writer may modify some refs.\n- It is impossible to do atomic writes because creating or updating several refs requires you to write to several files.\n- Housekeeping via `git-pack-refs` does not scale well because of its all-into-one repacking nature.\n- The storage format of both loose and packed refs is inefficient and wastes disk space.\n- Filesystem-specific behavior can be weird and may restrict which refs can be created. For example, Case-insensitivity on filesystems like FAT32 can cause issues, when trying to create two refs with the same name that only differ in their case.\n\nSeveral years ago, [Shawn Pearce](https://sfconservancy.org/blog/2018/jan/30/shawn-pearce/) had proposed the \"reftable\" format as an alternative new format to store refs in a repository. This new format was supposed to help with most or all of the above issues and is essentially a\nbinary format specifically catered towards storing references in Git.\n\nThis new \"reftable\" format has already been implemented by\n[JGit](https://www.eclipse.org/jgit/) and is used extensively by the [Gerrit project](https://www.gerritcodereview.com/). And, in 2021, [Han-Wen Nienhuys](https://www.linkedin.com/pub/dir/han-wen/nienhuys) upstreamed a library to read and write reftables into the Git project. What is still missing though is the backend that ties together the reftable library and\nGit, and unfortunately progress has stalled here. As we experience much of the pain that the reftable format is supposed to address, we decided to take over the work from Han-Wen and continue the upstreaming process.\n\nBefore we can upstream the reftable backend itself though, we first had to prepare several parts of Git for such a new backend. While the Git project already has a concept of different ref backends, the boundaries were very blurry because until now there only exists a single \"files\" backend.\n\nThe biggest contribution by GitLab in this release was thus a joint effort to prepare all the parts of Git for the new backend that were crossing boundaries:\n- Some commands used to read or write refs directly via the filesystem without going through the ref backend.\n- The ref databases of worktrees created via `git-worktree` were initialized ad-hoc instead of going through the ref backend.\n- Cloning a repository created the ref database with the wrong object format when using SHA256. This did not matter with the \"files\" backend because the format was not stored anywhere by the ref backend itself. But because the reftable backend encodes the format into its binary format, this was a problem.\n- Many tests read or write refs via the filesystem directly.\n- We invested quite some time already into bug fixing and performance optimizations for the reftable library itself.\n- We introduced a new `refStorage` extension that tells Git in which format the repository stores its refs. This can be changed when creating a new repository by specifying `--ref-format` flag in `git-init` or `git-clone`. For now, only the “files” format is supported.\n\nThe overarching goal was to get the work-in-progress reftable backend into a state where it passes the complete test suite. And even though the reftable backend is not yet part of Git 2.44.0, I am happy to report that we have\nsucceeded in this goal: Overall, we have contributed more than 150 patches to realize it. Given the current state, we expect that the new reftable backend will become available with Git v2.45.0.\n\nWe will not cover the new reftable format in this post because it is out of scope, but stay tuned for more details soon!\n\nThis project was a joint effort by\n[John Cai](https://gitlab.com/jcaigitlab),\n[Justin Tobler](https://gitlab.com/justintobler),\n[Karthik Nayak](https://gitlab.com/knayakgl),\n[Stan Hu](https://gitlab.com/stanhu),\n[Toon Claes](https://gitlab.com/toon),\nand [Patrick Steinhardt](https://gitlab.com/pks-gitlab), who has led the effort. Credit also goes to\n[Shawn Pearce](https://sfconservancy.org/blog/2018/jan/30/shawn-pearce/) as original inventor of the format and [Han-Wen Nienhuys](https://www.linkedin.com/pub/dir/han-wen/nienhuys) as the\nauthor of the reftable library.\n\n## Support for GitLab CI\n\nAs all the preparations for the new `reftable` backend demonstrate, we have significantly increased our investments into the long-term vision and health of\nthe Git project. And because a very important part of our product depends on the Git project to remain healthy, we want to continue investing into the Git project like this.\n\nFor us, this means that it was high time to improve our own workflows in the context of the Git project. Naturally, we were already using GitLab CI as part of the process instead of the GitHub Workflows support that existed in\nthe Git project. But we were using a [`.gitlab-ci.yml` definition](https://docs.gitlab.com/ee/ci/yaml/) that was not part of the upstream repository and instead maintained outside the Git project.\n\nWhile this worked reasonably well, there were two significant downsides:\n- Test coverage was significantly lower than that of the GitHub Workflows definition. Notably, we did not test on macOS, had no static analysis, and didn't test with non-default settings. This often led to failures in the GitHub Workflows pipeline that we could have detected earlier if we had better CI integration.\n- Other potential contributors to Git who may already be using GitLab on a daily basis didn't have easy access to a GitLab CI pipeline.\n\nTherefore, we decided to upstream a new GitLab CI definition that integrates with the preexisting CI infrastructure that the Git project already had. Because we reuse a lot of pre-existing infrastructure, this ensures that both GitLab CI and GitHub Workflows run tests mostly in the same way.\n\nAnother benefit of GitLab CI support is that, for the first time, we now also exercise an architecture other than `x86_64` or `i686`: the [macOS runners we provide at GitLab.com](https://docs.gitlab.com/ee/ci/runners/saas/macos_saas_runner.html) use an Apple M1, which is based on the `arm64` architecture.\n\nThis change was contributed by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## More to come\n\nThis blog post gives just a glimpse into what has happened in the Git project, which lies at the heart of [source code management](https://about.gitlab.com/solutions/source-code-management/) at GitLab. Stay tuned for more insights into future contributions and the reftable backend in particular!",[699,675,1000],{"slug":1061,"featured":6,"template":679},"gitlabs-contributions-to-git-2-44-0","content:en-us:blog:gitlabs-contributions-to-git-2-44-0.yml","Gitlabs Contributions To Git 2 44 0","en-us/blog/gitlabs-contributions-to-git-2-44-0.yml","en-us/blog/gitlabs-contributions-to-git-2-44-0",{"_path":1067,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1068,"content":1074,"config":1080,"_id":1082,"_type":16,"title":1083,"_source":17,"_file":1084,"_stem":1085,"_extension":20},"/en-us/blog/pair-gitlab-and-the-good-docs-project-template-to-improve-release-notes",{"title":1069,"description":1070,"ogTitle":1069,"ogDescription":1070,"noIndex":6,"ogImage":1071,"ogUrl":1072,"ogSiteName":713,"ogType":714,"canonicalUrls":1072,"schema":1073},"Pair GitLab and The Good Docs Project template to improve release notes","Creating compelling, detailed, human-readable notes for software releases is important. Using GitLab and this template from The Good Docs Project makes it easier.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099541/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_432673748_5xWPNsktdz2QChWhl16jGq_1750099540656.jpg","https://about.gitlab.com/blog/pair-gitlab-and-the-good-docs-project-template-to-improve-release-notes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Pair GitLab and The Good Docs Project template to improve release notes\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Aaron Peters, Member, Good Docs Project\"}],\n        \"datePublished\": \"2024-01-23\",\n      }",{"title":1069,"description":1070,"authors":1075,"heroImage":1071,"date":1077,"body":1078,"category":14,"tags":1079},[1076],"Aaron Peters, Member, Good Docs Project","2024-01-23","Release notes allow software users to quickly understand the changes that come with the latest version of software. They also allow software publishers to highlight changes as important, or provide crucial information about the impact an upgrade may have. Some tools allow developers to \"generate\" release notes based on sources of data (such as completed items in DevOps systems), but notes produced this way tend to simply list changes without context. Writing release notes, however, provides teams with the opportunity to \"tell the story\" of the changes the new software version will bring.\n\nThough this process certainly requires a greater investment of time than publishing a basic changelog does, your users will certainly appreciate the results: release notes that explain the key elements of the release (such as new features, improvements, and known issues) in a well-organized, human-readable way.\n\n[The Good Docs Project's](https://thegooddocsproject.dev/welcome/) release notes template is designed to help you do exactly that. And the combination of GitLab's work management platform and our own [Release Notes template](https://gitlab.com/tgdp/templates/-/tree/main/release-notes?ref_type=heads) makes the job of putting out good, informative release notes easier.\n\n## The anatomy of quality release notes\n\nRelease notes that provide readers with a good picture of the version's changes require two primary inputs:\n\n- **A list of the changes included in the release**\n  At The Good Docs Project, all the management of the work of our contributors occurs in GitLab. So it's easy to refer to our release plans to identify which additions and improvements were completed and included in the release.\n- **A description of those changes including reasoning, importance, and impact**\n  This is where our project's Release Notes template can assist. Rather than staring at a blank page, wondering where to start, users can begin to fill in our template step-by-step, adjusting to taste.\n\nWe'll walk through each of these steps in the following sections as they occurred when creating the release notes to [our recent Dragon release](https://gitlab.com/tgdp/templates/-/releases/v1.1.0).\n\n## Gathering a release's changes\n\nAt The Good Docs Project, we use GitLab features — including setting milestones, creating/assigning issues, and tagging releases — to get our work out into the community (our prior blog post here at GitLab describes this process). The platform allows our worldwide contributor base to easily discover new things to work on and update everyone on their progress once they select something. When the time comes to package a release, it brings the added benefit of a tidy list of issues included in the project at the time of release.\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176084/Blog/hxo08y06apkumwuwm80c.png\" alt=\"The Milestone screen in GitLab provides an easy-to-scan list of work included in the release\" width=\"100%\" height=\"auto\">\n\nWhen creating the release notes for our project's Dragon milestone, we reviewed all the items included in the **Closed** column on the Milestone screen. This allowed us to pick the most important changes to highlight, while leaving out issues that wouldn't significantly impact a user's experience.\n\n## Crafting the release notes\n\nEquipped with a list of all the key updates in the release, we start writing the release notes. Our project's [Release Notes template](https://gitlab.com/tgdp/templates/-/blob/main/release-notes/template-release-notes.md?ref_type=heads) provides a ready-made Markdown skeleton comprised of key sections based on our contributors' research and experience. The accompanying [usage guide](https://gitlab.com/tgdp/templates/-/blob/main/release-notes/guide-release-notes.md?ref_type=heads) and [example of the template in action](https://gitlab.com/tgdp/templates/-/blob/main/release-notes/example-release-notes.md?ref_type=heads) provides additional tips and suggestions for writing effective release notes. The latter references our **Chronologue** project, a fictional telescope and application that can see through time, which is naturally well-documented.\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176091/Blog/jcpfxjqb5jpidssm3jlr.png\" alt=\"The Release Notes template comes ready to populate with 'the story' of your latest release\" width=\"100%\" height=\"auto\">\n\nOf course, our template is simply a starting point. Teams should always feel free to add sections where they make sense, remove them where they don't, and make the style of it their own. For example, we left out the **Bug fixes** and **Known issues** sections in our latest Dragon release notes, instead focusing on the new additions and improvements this release brought.\n\n## Adding release notes to the release\n\nGitLab's build tools also make it easy to add our notes while actually creating the release. First, we tagged one of our project's commits, then created a release from the tag. On GitLab's **Releases > New** screen, we can copy and paste the Markdown we wrote to automatically format the release notes.\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176096/Blog/otwduhvokgnqclon4ugx.png\" alt=\"Our templates are already in Markdown format, so when it's time to paste them into the release it works automagically!\" width=\"100%\" height=\"auto\">\n\nAnd just like that our release notes are done. With the assistance of the template, they required just an hour to write. And after an additional half-hour of work creating the release, we're ready to send our work out to the community. Our experience using the combination of GitLab and our templates has made the process of shipping our templates a piece of cake.\n\nIf you'd like to check out our templates, feel free to browse [our GitLab project](https://gitlab.com/tgdp).\nOr visit our [community page](https://thegooddocsproject.dev/community/) to learn how to join us in leveling up the state of technical documentation.\n\n*The [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) are building the future of open source on GitLab. [Connect with them](https://gitlab.com/gitlab-com/marketing/developer-relations/open-source-program/gitlab-open-source-partners) on Gitlab.com.*\n",[675,480,268,781],{"slug":1081,"featured":92,"template":679},"pair-gitlab-and-the-good-docs-project-template-to-improve-release-notes","content:en-us:blog:pair-gitlab-and-the-good-docs-project-template-to-improve-release-notes.yml","Pair Gitlab And The Good Docs Project Template To Improve Release Notes","en-us/blog/pair-gitlab-and-the-good-docs-project-template-to-improve-release-notes.yml","en-us/blog/pair-gitlab-and-the-good-docs-project-template-to-improve-release-notes",{"_path":1087,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1088,"content":1093,"config":1099,"_id":1101,"_type":16,"title":1102,"_source":17,"_file":1103,"_stem":1104,"_extension":20},"/en-us/blog/the-contributions-we-made-to-the-git-2-43-release",{"title":1089,"description":1090,"ogTitle":1089,"ogDescription":1090,"noIndex":6,"ogImage":1033,"ogUrl":1091,"ogSiteName":713,"ogType":714,"canonicalUrls":1091,"schema":1092},"The contributions we made to the Git 2.43 release","Git 2.43 included some improvements from GitLab's Git team. Here are some highlights from the work the team has done on Git and why it matters.","https://about.gitlab.com/blog/the-contributions-we-made-to-the-git-2-43-release","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The contributions we made to the Git 2.43 release\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"John Cai\"}],\n        \"datePublished\": \"2024-01-11\",\n      }",{"title":1089,"description":1090,"authors":1094,"heroImage":1033,"date":1096,"body":1097,"category":14,"tags":1098},[1095],"John Cai","2024-01-11","[Git 2.43](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNotes/2.43.0.txt)\nwas officially released on November 20, 2023, and included some improvements from GitLab's Git team. Here are some highlights from the work our team has\ndone on Git and why it matters.\n\n## Segmenting objects across packfiles\n\nIn Git 2.43, [Christian Couder](https://about.gitlab.com/company/team/#chriscool)\nadded a `--filter` option to the `git repack` command. Supported filter (see the\n[filter-spec docs](https://git-scm.com/docs/git-rev-list#Documentation/git-rev-list.txt---filterltfilter-specgt)) can be added to the `git repack --filter` flag. This will cause the filtered out objects to be\npacked into a separate packfile.\n\nA `--filter-to` option was also added. Providing this option will cause Git to write the filtered packfile to the specified location on the filesystem.\n\n### Why it matters\n\nGitaly servers host Git repositories and incur storage costs. In many repositories however, not all the objects need to be accessed all the time. Allowing Git to\noffload some repository data onto a different packfile paves the way for storage optimizations whereby we can choose to segment the Git repository data and place\ncertain kinds of objects on cheaper storage such as slower disks or object storage.\n\n## Checking object existence\n\nIn Git, to check the existence of an object one would have to rely on Git returning an error if it couldn’t find an object. However, to date, there has not been a generic way in Git to check the existence of an object. There were certain edge cases that were not handled well by the underlying Git code. For example, if a reference exists as a symbolic reference, but its target branch does not exist.\n\n[Patrick Steinhardt](https://about.gitlab.com/company/team/#pks-gitlab) added the `--exists` option to `git show` as a generic way to check for object existence.\n\n### Why it matters\n\nThe Gitaly team has started work to upstream the [reftable backend](https://gitlab.com/groups/gitlab-org/-/epics/11652) into the Git project. This new flag enables consistent validation of object existence to fix a number of tests to work with the reftables backend.\n\n## Find missing commit objects \n\n`git rev-list`'s `--missing` option provides information about objects that are referenced but are missing from a repository. Up to this release however, this option only worked with blobs and trees. Missing commits would cause `git rev-list` to fail with a fatal error.\n\nIn Git 2.43, [Karthik Nayak](https://about.gitlab.com/company/team/#knayakgl)\nextended the `--missing` option to work with commit objects.\n\n### Why it matters\n\nGitaly's next-generation repository replication implementation relies on a [write\nahead log](https://gitlab.com/groups/gitlab-org/-/epics/8911) (WAL) that logs every write to a repository.\n\nThe upcoming WAL creates separate log entries per transaction – as such, some transactions contain reference updates. In these transactions, it is necessary to identify new git objects being added to the repository. The WAL implementation uses a quarantine directory to stage these new objects. \n\nWe can now use git-rev-list(1) along with the --missing flag, to identify all the objects that are newly added and required and also boundary commits that connect the quarantine directory to the main object directory.\n\n## Read gitattributes from HEAD in bare repos\n\nStarting in 2.43, [John Cai](https://about.gitlab.com/company/team/#jcaigitlab)\nmade a change that allows [Git attributes](https://git-scm.com/docs/gitattributes) to start to read attributes from the tree that HEAD points to by default, in bare repositories.\n\n### Why it matters\n\nTo reduce some tech debt around how git attributes are read in a repository, we added the ability to pass a tree object directly to Git through the [`--attr-source` flag](https://git-scm.com/docs/git#Documentation/git.txt---attr-sourcelttree-ishgt).\n\nPassing in `HEAD` to `--attr-source` would fail however, when `HEAD` pointed to and unborn branch, Gitaly would have needed to use a separate call to check if `HEAD` were unborn before passing it in.\n\nThis change not only causes Git to read attributes from `HEAD` by default, which means we don't need to pass in anything, but also silently ignores it if `HEAD` is unborn, which is the behavior we want in Gitaly. This way, we don't need to make any code changes in Gitaly for this to work.\n\nThis leads to simplification on the Gitaly side, as we seek to remove some [technical debt around gitattributes](https://gitlab.com/groups/gitlab-org/-/epics/9006)\nput in during a time when Git lacked support around reading gitattributes in bare repositories.\n\n## Bug fixes\n\n[Patrick Steinhardt](https://about.gitlab.com/company/team/#pks-gitlab) fixed a bug in `git rev-list –stdin`.  \n\nSteinhardt also addressed an existing issue in [commit-graphs](https://git-scm.com/docs/commit-graph) whereby commits parsed from the commit-graph weren’t always checked for existence. A `GIT_COMMIT_GRAPH_PARANOIA` environment variable can now be turned on to always check for object existence.",[268,675,699],{"slug":1100,"featured":6,"template":679},"the-contributions-we-made-to-the-git-2-43-release","content:en-us:blog:the-contributions-we-made-to-the-git-2-43-release.yml","The Contributions We Made To The Git 2 43 Release","en-us/blog/the-contributions-we-made-to-the-git-2-43-release.yml","en-us/blog/the-contributions-we-made-to-the-git-2-43-release",{"_path":1106,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1107,"content":1113,"config":1119,"_id":1121,"_type":16,"title":1122,"_source":17,"_file":1123,"_stem":1124,"_extension":20},"/en-us/blog/google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare",{"title":1108,"description":1109,"ogTitle":1108,"ogDescription":1109,"noIndex":6,"ogImage":1110,"ogUrl":1111,"ogSiteName":713,"ogType":714,"canonicalUrls":1111,"schema":1112},"Google Summer of Code 2024: Contribute to GitLab and Git to prepare","Learning how to contribute to GitLab and Git can help you get ready to apply for Google's program for open source development.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663000/Blog/Hero%20Images/tanukilifecycle.png","https://about.gitlab.com/blog/google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Google Summer of Code 2024: Contribute to GitLab and Git to prepare\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nick Veenhof\"},{\"@type\":\"Person\",\"name\":\"Christian Couder\"}],\n        \"datePublished\": \"2023-12-20\",\n      }",{"title":1108,"description":1109,"authors":1114,"heroImage":1110,"date":1116,"body":1117,"category":14,"tags":1118},[1115,798],"Nick Veenhof","2023-12-20","Google Summer of Code ([GSoC](https://summerofcode.withgoogle.com/)), a program that helps bring new contributors into open source software development, is just around the corner. So now is the time to start learning [how to contribute to GitLab](https://about.gitlab.com/community/contribute/) or Git and prepare ideas for GSOC 2024. GitLab has participated in GSOC for more than five years of the program's 20-year history, and the mentorship opportunity aligns well with our \"[Everyone can contribute](https://handbook.gitlab.com/handbook/company/mission/)\" mission.\n\nIn 2023, GitLab team members mentored GSoC contributors working on GitLab and Git open source projects throughout the 12-week program. One example was the “Unify ref-filter formats with other --pretty formats” Git project. \n\n## Implementing new formatting options for Git commands\n\nKousik Sanagavarapu was selected as a 2023 GSOC contributor and was mentored by [Christian Couder](https://gitlab.com/chriscool), staff backend engineer on the GitLab Gitaly::Git team.\n\nKousik’s work focused on implementing some [new formatting options for Git commands](https://summerofcode.withgoogle.com/programs/2023/projects/rck3kmq2) like `git branch`, `git tag` and `git for-each-ref`. These commands use a formatting mechanism called the “ref-filter” format. The formatting options Kousik worked on were already available for other commands like `git log`, that use a different formatting mechanism called the “pretty” format. So the work involved porting these options from the “pretty” format to the “ref-filter” format.\n\nThanks to Kousik’s work, it’s now possible to use a number of new placeholders like %(signature), %(authoremail:mailmap), or %(describe) in the –format option of `git branch`, `git tag`, and `git for-each-ref` to get more information about the commits that branches, tags, or refs in general point to. [Read the documentation](https://git-scm.com/docs/git-for-each-ref/2.43.0#_field_names) for a description of these placeholders.\n\nThese improvements are available in the recently released Git 2.43.\n\n## How GSOC works\n\nOpen source organizations who participate – such as GitLab and Git – have to propose projects and provide mentors. Selected contributors are helped by the mentors and paid by Google during 12 or more weeks while they work on their projects. Contributors are evaluated three times by mentors: after a “Community Bonding” period, in the middle of the coding period, and after the coding period for a final evaluation.  \n\n## How to participate as a contributor\n\nTo apply to become a contributor for GSOC 2024, check out the [GSoC website](https://summerofcode.withgoogle.com/) and the [Google Open Source blog](https://opensource.googleblog.com). Interested parties should register [when selected organizations are announced](https://opensource.googleblog.com/2023/02/mentor-organizations-announced-for.html), which will happen in a few months. \n\nContributors will then be selected by the mentors after they have made a small contribution and after they have prepared an application document that details how they plan to achieve the proposed project they want to work on.\n\nProspective contributors can start learning about GitLab or Git right now to be fully ready to make a small contribution and prepare an application. [As Google says](https://opensource.googleblog.com/2023/02/mentor-organizations-announced-for.html), “The most successful applications come from contributors who start preparing now.” \n\nGitLab has a lot of documentation and tutorials [to learn how to contribute](https://about.gitlab.com/community/contribute/), while Git has a [Hacking Git page](https://git.github.io/Hacking-Git/) with a lot of helpful links.\n\n## How GitLab team members participate\n\nGitLab participates in GSOC as an open source organization and team members from different functional areas volunteer to mentor contributors and propose projects for them to work on.  \n\nIn 2023, GitLab team members mentored contributors on a number of GitLab-related projects, including  Pajamas Migration with the GitLab Foundations Team and improving the documentation for the contributor journey to GitLab.\n\n## How Git developers participate\n\nThe Git project also participates in GSoC as an open source organization, and Git developers who are interested in mentoring propose projects, and then select GSoC contributors.\n\nLast summer, in addition to the \"Unify ref-filter formats with other --pretty formats\" project, Git developers proposed the \"[More Sparse Index integrations](https://summerofcode.withgoogle.com/programs/2023/projects/Rkbc1Abe)\" project.\n\n## Mentoring and GitLab \n\nGitLab’s mission is “Everyone can contribute” and we understand that helping potential contributors through mentoring can achieve this goal. In addition to participating in external programs like GSOC and [Outreachy](https://about.gitlab.com/blog/outreachy-sponsorship-winter-2020/), GitLab has internal mentoring programs, including a [CEO Shadow program](https://handbook.gitlab.com/handbook/ceo/shadow/) and a [Mentorship program for women](https://handbook.gitlab.com/handbook/company/culture/inclusion/tmrg-gitlab-women/mentorship-program/).\n\nLearn more about [mentoring at GitLab](https://handbook.gitlab.com/handbook/people-group/learning-and-development/mentor/).",[675,268,865,699,864],{"slug":1120,"featured":6,"template":679},"google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare","content:en-us:blog:google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare.yml","Google Summer Of Code 2024 Contribute To Gitlab And Git To Prepare","en-us/blog/google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare.yml","en-us/blog/google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare",{"_path":1126,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1127,"content":1133,"config":1140,"_id":1142,"_type":16,"title":1143,"_source":17,"_file":1144,"_stem":1145,"_extension":20},"/en-us/blog/how-eclipse-foundation-champions-open-source-with-gitlab",{"title":1128,"description":1129,"ogTitle":1128,"ogDescription":1129,"noIndex":6,"ogImage":1130,"ogUrl":1131,"ogSiteName":713,"ogType":714,"canonicalUrls":1131,"schema":1132},"How the Eclipse Foundation champions open source with GitLab","In this interview, learn how adopting GitLab helps the Eclipse Foundation be a more effective champion for open source.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679184/Blog/Hero%20Images/eclipsefoundationcover.png","https://about.gitlab.com/blog/how-eclipse-foundation-champions-open-source-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How the Eclipse Foundation champions open source with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Bryan Behrenshausen\"}],\n        \"datePublished\": \"2023-10-19\",\n      }",{"title":1128,"description":1129,"authors":1134,"heroImage":1130,"date":1136,"body":1137,"category":14,"tags":1138},[1135],"Bryan Behrenshausen","2023-10-19","\nThe Eclipse Foundation is a pillar of the open source ecosystem. Home to more than 415 open source projects, the not-for-profit organization has been championing open source collaboration and innovation for more than two decades.\n\nGitLab plays a significant role in the Eclipse Foundation's operations, and the organization recently joined the GitLab [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) community. To mark the occasion, I caught up with Denis Roy, IT director at the Eclipse Foundation, to chat about the organization's history, vision, and passion for open source development.\n\n**We're so excited to welcome the Eclipse Foundation to the GitLab Open Source Partners community. You've been champions of open source for quite some time. Tell us about your history and the mission that guides you today.**\n\nThe Eclipse Foundation was born in 2004, as a not-for-profit, [open source](https://go.gitlab.com/spHNym) software foundation with the goal of driving the evolution of the Eclipse Platform and its ecosystem of tools, plugins, and addons in a vendor-neutral, open, and transparent community. Since then, the Eclipse Foundation has become one of the world's largest open source software foundations. The foundation offers a mature, scalable, and business-friendly environment for open source software collaboration and innovation, hosting more than 415 open source projects, including runtimes, tools, and frameworks for a wide range of technology domains such as the Internet of Things, automotive, geospatial, systems engineering, and many others.\n\n> Connect with the GitLab Open Source Partners on [Gitlab.com](https://gitlab.com/gitlab-com/marketing/community-relations/open-source-program/gitlab-open-source-partners).\n\n**How does the Eclipse Foundation use GitLab? What has using GitLab helped you accomplish?**\n\nGitLab has allowed us to modernize our development platform, because it offers an integrated, cohesive environment to help maximize developer productivity while reducing the administrative overhead related to managing such a complex set of tools. With a single package to upgrade and maintain, and tight integration between code repositories, issue trackers, wikis, code review, and CI tools, it's easier for the Eclipse Foundation's IT team to stay up to date. This has allowed us to reduce our reliance on customized, in-house code.\n\nWhen we began our work in 2004, open source code hosting options were rudimentary and limited. At the time, we created our own forge by using a handful of tools that were not designed with interoperability in mind, including [CVS](https://www.nongnu.org/cvs/), [Bugzilla](https://www.bugzilla.org/), and [MediaWiki](https://www.mediawiki.org/wiki/MediaWiki). When it came time to refresh our offering, it was an easy decision to replace our home-grown forge with GitLab, since GitLab offers a seamless integration of all these developer tools, and many more, within a single, easy-to-use package. This creates a very useful environment for our developers and allows the project teams to be productive while offering a familiar interface for interacting and building their user communities.\n\nAt this time, [the Eclipse Foundation's GitLab instance](https://gitlab.eclipse.org) hosts more than 70 [open source software projects](https://gitlab.eclipse.org/eclipse) and dozens of other projects that [help us manage and support our community](https://gitlab.eclipse.org/eclipsefdn).\n\n**How big is the Eclipse Foundation's IT team? What have you seen the team achieve after the migration to GitLab?**\n\nThe Foundation's IT team consists of a dozen people, split almost evenly between infrastructure, release engineering, security, and web development. Our migration to GitLab is still a work in progress, but it's allowing the Eclipse Foundation IT team to consolidate our code repositories, issues, and documentation onto a single platform with a modern and friendly UI. The same is also true for the Eclipse OSS projects that have, or are currently migrating from, \"pure Git\" to GitLab.\n\nWith GitLab, the team is seeing a notable decrease in both administrative overhead and user support, as using, managing, and maintaining GitLab on premise is straightforward and very robust. We're able to stay up-to-date with new GitLab releases easily, which scores extra points with our security team. We're able to use that freed time towards activities that benefit our community and provide extra value.\n\n**What's on the horizon for the Eclipse Foundation? What are your most important initiatives right now?**\n\nOne of the big initiatives we’re working on right now is improving the security of our open source projects. We’ve made a significant investment in security over the past year, including auditing some of our top projects for security concerns and we are looking to establish a [working group](https://www.eclipse.org/org/workinggroups/eclipse-cyber-risk-concept.php) to help us gain the resources we need to enhance our security processes across all of our operations.\n\nWe're also focused on growing the [Eclipse Software Defined Vehicle](https://sdv.eclipse.org/) community, which continues to gain momentum with new members like General Motors, Qualcomm, and Microsoft. The automotive industry is becoming increasingly willing to collaborate on open source software, and experience the technological and business benefits of doing so.  \n\n**How can GitLab community members get more involved in the Eclipse Foundation's work?**\n\nIt's easy! Browse the list of [Eclipse Projects](https://projects.eclipse.org/) and discover the Developer Resources section. Or browse the list of projects on Eclipse's [GitLab instance](https://gitlab.eclipse.org/eclipse) and send in those those merge requests!\n\n## Learn more\nThe [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) are building the future of open source on GitLab. Connect with them on [Gitlab.com](https://gitlab.com/gitlab-com/marketing/community-relations/open-source-program/gitlab-open-source-partners).\n",[675,268,1139],"features",{"slug":1141,"featured":6,"template":679},"how-eclipse-foundation-champions-open-source-with-gitlab","content:en-us:blog:how-eclipse-foundation-champions-open-source-with-gitlab.yml","How Eclipse Foundation Champions Open Source With Gitlab","en-us/blog/how-eclipse-foundation-champions-open-source-with-gitlab.yml","en-us/blog/how-eclipse-foundation-champions-open-source-with-gitlab",{"_path":1147,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1148,"content":1154,"config":1160,"_id":1162,"_type":16,"title":1163,"_source":17,"_file":1164,"_stem":1165,"_extension":20},"/en-us/blog/behind-the-scenes-of-gitlab-korean-translation",{"title":1149,"description":1150,"ogTitle":1149,"ogDescription":1150,"noIndex":6,"ogImage":1151,"ogUrl":1152,"ogSiteName":713,"ogType":714,"canonicalUrls":1152,"schema":1153},"Behind the scenes of GitLab's Korean translation","How a student project helped maintain linguistic consistency and deliver a unified user experience for the Korean GitLab community.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664472/Blog/Hero%20Images/gitlabflatlogomap.png","https://about.gitlab.com/blog/behind-the-scenes-of-gitlab-korean-translation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Behind the scenes of GitLab's Korean translation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Inchul Yoo, Sunjung Park\"}],\n        \"datePublished\": \"2023-10-05\",\n      }",{"title":1149,"description":1150,"authors":1155,"heroImage":1151,"date":1157,"body":1158,"category":14,"tags":1159},[1156],"Inchul Yoo, Sunjung Park","2023-10-05","\nGitLab is translated into many languages by community members, ensuring our product reaches a much wider audience. In recent months, software and computer engineering students from Ajou University in South Korea contributed translations as part of their classroom project, led by Prof. Hwanyong Lee. Their contributions, together with many other members of our community, resulted in [100% of strings in the GitLab UI being translated into Korean](https://translate.gitlab.com/project/gitlab-ee/ko). \n\n![photo of Korean translation contributors](https://about.gitlab.com/images/blogimages/translation-contributors-swag.jpg){: .medium.center}\n\nIn this blog post, [Inchul Yoo](https://gitlab.com/iyoo), solutions architect at GitLab, and [Sunjung Park](https://gitlab.com/sunjungp), senior product Designer at GitLab, who also volunteer as proofreaders for the Korean translation of GitLab in the [GitLab Crowdin project](https://crowdin.com/project/gitlab-ee), had the privilege to interview Prof. Lee. He shared the students' experience in contributing to GitLab and discussed areas where additional collaboration is needed for translation.\n\nThank you for your contributions to GitLab: \n- Dahee Kim (김다희, 아주대학교)\n- Myeong Seok Nam (남명석, 아주대학교)\n- Jongho Baik (백종호, 아주대학교)\n- Seoyoung Lee (이서영, 아주대학교)\n- Sungmin Lee (이승민, 아주대학교)\n- Jaeyoon Lee (이재윤, 아주대학교)\n- Hwanyong Lee (이환용 교수, 아주대학교)\n\n## Interview with Prof. Hwanyong Lee\n\n**Could you tell us about Ajou University and the department?**\n\nAjou University aims to cultivate software talents with diverse roles in the field of software as its primary focus. Using GitLab, students have opportunities to learn through practical experience covering most aspects of the DevOps lifecycle, including issue management, version control, building, and deploying software.\n\n**When did you start using GitLab, and for what purpose?**\n\nSince 2018, when Ajou University became a software-focused institution, we started to utilize GitLab for educational purposes, including tasks such as assignments and submissions. Currently, our GitLab instance hosts over 9,000 projects and serves more than 2,200 students.\n\n**What motivated you to translate all of GitLab's product interface text into Korean?**\n\nOutside of my professional responsibilities, I have been actively contributing to diverse open source projects. Given my role as a professor, I saw an opportunity to underscore the significance of open source contributions to my students and inspire them to engage in such activities. During this semester, I established the objective of involving students in open source projects, specifically focusing on Korean localization. Remarkably, more than 10 students eagerly volunteered to participate in the translation efforts of more than 10 open source projects into Korean.\n\n**How many students participated in the GitLab translation project, and how long did it take?**\n\nThere were seven students in total, both majoring and minoring in software and computer engineering. We distributed the tasks among them to collaborate on the project. The entire project was completed in approximately half a semester, which took about two months.\n\n**Each student may have different translations for the same words. How did you handle this?**\n\nWe managed this by creating our own glossary to ensure uniform translations. We collaborated to achieve consistency in the wording, and we synced regularly to discuss and resolve any ambiguous or contentious issues.\n\n**What was the most challenging aspect of the project?**\n\nOne of the biggest challenges we faced was the continuous addition of new strings and phrases with each new GitLab update. Keeping up with these additions proved to be quite challenging. Additionally, there were instances where there was no direct Korean equivalent for English terms, or where additional contextual explanations were required, making the translation process more complex.\n\nWhen students identified inconsistencies that were not covered by the glossary, I encouraged them to bring these up in the regular sync. We tried to determine which translated terms were commonly used. And we used the [Korean TTA standards (Telecommunications Technology Association) dictionary](https://terms.tta.or.kr/main.do) as a primary point of reference.\n\n**Could you provide some closing thoughts regarding the contribution?**\n\nThe students were surprised to discover their ability to actively participate in the open source software they rely on, leading to a newfound sense of pride. This transformation signified a shift in the focus to embracing the concept of community and recognizing the genuine value of open source software through their contributions to shared community-driven objectives.\n\n### Learn how you can contribute to translation\nContributing to translation is a journey that goes beyond words; it's about building a global community and making technology more accessible. As Professor Lee mentioned, students discovered they could actively engage in open source software, and this filled them with pride. It's a rewarding journey that goes beyond language, and it's an opportunity to make a meaningful impact on the tech world.\n\nSoftware can only be as usable and accessible to its users as it is understandable by them. Translation helps bridge the linguistic and cultural gaps that might be preventing your software from being adopted by a given community. Together with contributors, proofreaders also play an important role in helping new contributors succeed by ensuring the consistency and quality of translations. Did you know that the term \"merge request\" can be translated into Korean in various ways?\n\nA good place to start is the [Translate GitLab page](https://docs.gitlab.com/ee/development/i18n/), where you can learn how you can contribute to GitLab's externalization, translation, proofreading, and merging. If you have any questions, please join translate.gitlab.com or post questions on the [Crowdin discussions forum](https://translate.gitlab.com/project/gitlab-ee/discussions).\n\nTo participate in discussions building a glossary list for Korean translation, join us at [gitlab.com/korean-translation/gitlab](https://gitlab.com/korean-translation/gitlab)! Once we finalize the glossary list and establish grammar rules, we aim to consistently elevate the quality of our translations.\n",[675,268,1139],{"slug":1161,"featured":6,"template":679},"behind-the-scenes-of-gitlab-korean-translation","content:en-us:blog:behind-the-scenes-of-gitlab-korean-translation.yml","Behind The Scenes Of Gitlab Korean Translation","en-us/blog/behind-the-scenes-of-gitlab-korean-translation.yml","en-us/blog/behind-the-scenes-of-gitlab-korean-translation",{"_path":1167,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1168,"content":1174,"config":1179,"_id":1181,"_type":16,"title":1182,"_source":17,"_file":1183,"_stem":1184,"_extension":20},"/en-us/blog/open-source-tools-for-citizen-journalists",{"title":1169,"description":1170,"ogTitle":1169,"ogDescription":1170,"noIndex":6,"ogImage":1171,"ogUrl":1172,"ogSiteName":713,"ogType":714,"canonicalUrls":1172,"schema":1173},"How the Colmena project uses GitLab to support citizen journalists","Find out why the Colmena project, a GitLab Open Source Partner, relies on a DevSecOps platform to develop and deliver open source tools for citizen journalism.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683016/Blog/Hero%20Images/citizenjournalism.png","https://about.gitlab.com/blog/open-source-tools-for-citizen-journalists","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How the Colmena project uses GitLab to support citizen journalists\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Bryan Behrenshausen\"}],\n        \"datePublished\": \"2023-09-27\",\n      }",{"title":1169,"description":1170,"authors":1175,"heroImage":1171,"date":1176,"body":1177,"category":14,"tags":1178},[1135],"2023-09-27","\nIn an increasingly crowded media ecosystem, finding an audience — and being heard — can be difficult, especially for indigenous communities with limited access to global platforms. But using the open source [Colmena project](https://blog.colmena.media/), anyone can collaboratively plan, record, edit, and distribute hyperlocal and community-focused media products that reach audiences worldwide.\n\nThe Colmena project (which takes its name from the Spanish word for \"beehive\") is a [GitLab Open Source Partner](https://go.gitlab.com/030Ue3). I recently spoke with community members [Nils Brock](https://gitlab.com/nilsbrock), [Vivienne Gager](https://gitlab.com/vivienne.maria), and [Santiago Garcia Gago](https://gitlab.com/SantiagoGG) about how they use GitLab to help people find their voices, tell their stories, and help their communities.\n\nWe conducted our interview iteratively, asynchronously, and collaboratively [via merge request](https://gitlab.com/gitlab-com/marketing/developer-relations/open-source-program/gitlab-open-source-partners/publications-and-presentations/-/merge_requests/9).\n\n**Welcome to the the GitLab Open Source Partners community! We're so delighted you're here. Tell our readers more about Colmena. What is it?**\n\nBrock, Gager, and Garcia Gago: Colmena is open technology for journalists. Think of it as a mobile digital newsroom for field reporters and media outlets. Our software enables users to create and share content. But here is what's special: The solution is developed together with local and community media from the Global South, is free to use, and is completely open source. \n\nThe backbone of Colmena is a custom-made digital newsroom for production teams, which includes all essential features for content creation, with special consideration for audio productions and transmissions. So we have audio streaming and podcast production workflows, a mobile recording option (face-to-face and online interviews), and mobile text and audio editing tools. All tools are set up for cross-media collaboration and are highly customizable. It's also important to note that Colmena is already available in eight languages, including English, Arabic, and Ukranian.\n\nBut Colmena doesn't need to stop there. We are always open for new suggestions.\n\n**Where can users download Colmena? How can they use it?**\n\nAs a lightweight app (a so-called \"progressive web application,\" or PWA), Colmena performs on a wide range of mobile and desktop devices for easy online/offline creation and collaboration. On the server side, we have established a secure and federated architecture, offering cloud-based sharing, storage, and publishing wherever you want, be it your own website on social media or other platforms.\n\n**How did the project get started? What mission, vision, and values drive it?**\n\nThe initiative [was born as a response to the COVID-19 pandemic](https://p.dw.com/p/3ydGf), and it's led by DW Akademie and the Mexican NGO Redes por la Diversidad, Equidad y Sustentabilidad A.C. The project is supported by the German Federal Ministry of Economic development and Cooperation (BMZ) as part of the Global Crisis Initiative (GKI).\n\n[Our vision](https://p.dw.com/p/40B1S) is to provide safe and inclusive digital tools for the communication, creation, and sharing of human rights-based content, to defend and extend freedom of expression to all parts of the world. And as the driving force behind the Colmena project, our mission is to sustainably maintain and develop the open source Colmena software as a commons, based on the needs of community-centered communication, networking, and media practices of the global majority.\n\nCollaboration is an important aspect of Colmena's development model. We develop the application working closely with [media partners](https://p.dw.com/p/4B1ID), to whom we refer as \"communities of practice\" (CoPs). Generally, one or two members of each CoP serve as representatives of their media outlets in the Colmena project. One might say they have the most important role in the project. Colmena is a collective response to their needs, and we want to design it to overcome challenges they face.\n\n**How does the Colmena project use GitLab to accomplish all this?**\n\nWe use of GitLab for the Colmena Project in three different ways. The first use is quite technical: We use it as [a development platform and code repository](https://git.colmena.network/maia). All repositories for the Colmena PWA are public; we keep only the \"infra\" project private (since that's where the data of our development servers are stored).\n\nSecondly, [GitLab's wiki feature](https://docs.gitlab.com/ee/user/project/wiki/) serves us quite well as a documentation space for both our general work team and additional collaborators, who are the coordinators of our CoPs and the media partners involved in the co-creation of Colmena. [In the wiki](https://git.colmena.network/maia/frontend/-/wikis/home), for instance, we socialize information for the onboarding of new team members — like general information on the project, additional literature, and manuals of the tools we use in the project and documentation of conducted workshops for internal knowledge sharing. Before we had this documentation stored in a Nextcloud instance, but using GitLab for this work creates deeper understanding between the users, coordinators, and the development team about Colmena development processes and workflows.\n\nFinally, we maintain [an open \"support\" project](https://git.colmena.network/maia/support/-/issues?scope=all&state=all). In this project, the coordinators of the CoPs, who work with 30 media outlets from different countries, collect suggestions or detected bugs and report them. The development team evaluates and responds to each of them. If they need specialized attention — for example, development of a new feature or some bug fixing — we move these these issues to the corresponding development projects. We are currently migrating this repository from our self-hosted instance [to Gitlab.com](https://gitlab.com/colmena-project/communities-of-practice).\n\n**Why did the Colmena project choose GitLab as its development platform?**\n\nColmena was born as a free and open source software project; many of the developers and members of the coordination team have been involved in free software and community media projects before (for example, in the [Network of Community Radios and Free Software](https://liberaturadio.org/)). Our project always wanted to maintain this philosophy when looking for suitable software development platforms. That's why we chose GitLab: It shares our ideals regarding software development and knowledge sharing. Furthermore, Colmena is proud to use GitLab together with other free software projects that we have been using for ages, such as [Inkscape, Debian, and VLC](https://go.gitlab.com/030Ue3).\n\nBesides the shared philosophy, however, GitLab offers us technical options that other platforms do not. For example, it can be self-hosted, allows for management of groups and subgroups is, and features integrated planning tools like [epics](https://docs.gitlab.com/ee/user/group/epics/) and [roadmaps](https://docs.gitlab.com/ee/user/group/roadmap/) that really benefit the development process.\n\n**How can potential contributors learn more about Colmena?**\n\nIf you want to get in touch with us, please visit [our website](https://colmena.media) or write the team directly at `info@colmena.media`. You can also [browse the project and contirbute on GitLab](https://gitlab.com/colmena-project).\n\n## Watch the webcast \nWatch our interview with the Colmena project.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/4wIg2M1EoHI\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Learn more\nThe [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) are building the future of open source on GitLab. Connect with them on [Gitlab.com](https://gitlab.com/gitlab-com/marketing/community-relations/open-source-program/gitlab-open-source-partners).\n",[675,268,1139],{"slug":1180,"featured":6,"template":679},"open-source-tools-for-citizen-journalists","content:en-us:blog:open-source-tools-for-citizen-journalists.yml","Open Source Tools For Citizen Journalists","en-us/blog/open-source-tools-for-citizen-journalists.yml","en-us/blog/open-source-tools-for-citizen-journalists",{"_path":1186,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1187,"content":1192,"config":1198,"_id":1200,"_type":16,"title":1201,"_source":17,"_file":1202,"_stem":1203,"_extension":20},"/en-us/blog/debian-customizes-ci-tooling-with-gitlab",{"title":1188,"description":1189,"ogTitle":1188,"ogDescription":1189,"noIndex":6,"ogImage":1110,"ogUrl":1190,"ogSiteName":713,"ogType":714,"canonicalUrls":1190,"schema":1191},"Debian customizes CI tooling with GitLab","Debian developer Santiago Ruano Rincón explains the Linux distribution's custom solution for improving and expediting the open source software packaging process.","https://about.gitlab.com/blog/debian-customizes-ci-tooling-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Debian customizes CI tooling with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Santiago Ruano Rincón\"}],\n        \"datePublished\": \"2023-09-19\",\n      }",{"title":1188,"description":1189,"authors":1193,"heroImage":1110,"date":1195,"body":1196,"category":14,"tags":1197},[1194],"Santiago Ruano Rincón","2023-09-19","\nI still remember the day I broke a widely used critical tool for open source developers around the world.\nAs part of the [Debian Linux distribution project](https://www.debian.org/), I maintain [grep](https://tracker.debian.org/pkg/grep), the GNU/Linux application used to search for text patterns in files.\nI had just uploaded a new Debian release of grep to the Debian archive, when some hours later, a Debian friend called me to let me know other Debian developers were unable to boot their personal computers.\n\nThat was late in 2005 – ever since then I'd wished for a way to prevent that scenario from happening again.\n\nToday, that solution exists.\nIt's part of Salsa, Debian's GitLab implementation, which powers Debian development for more than 900 developers in the global Debian community.\nThanks to GitLab's robust CI/CD functionality, those developers are able to test their packages *before* releasing them to the public Debian archive — saving them from causing the kind of turmoil I accidentally caused.\n\n> [Join us at Open Source Summit Europe 2023](https://go.gitlab.com/dPQ92t) to learn more about GitLab's dedication to open source.\n\nIn this article, I'll explain how that tool, called [Salsa CI](https://salsa.debian.org/salsa-ci-team/pipeline/), helps Debian developers using GitLab streamline software development, accelerate package maintenance, and significantly reduce time-consuming re-work.\n\n## Debian with extra Salsa\nSalsa CI is one of the Debian community's custom-built continuous integration tools.\nIt's part of the Debian GitLab instance ([Salsa](https://wiki.debian.org/Salsa)), and helps Debian maintainers manage roughly [9,000 projects](https://codesearch.debian.net/search?q=pipeline-jobs+path%3Adebian%2F.*.yml&literal=0&perpkg=1).\n\n### How Salsa CI works\nAs a Linux distribution, Debian packages open source software from multiple upstream sources. \nWhen new upstream source code is released, maintainers can test that code to ensure it will build and run reliably for Debian users as part of the Debian release cycle.\n* Packages appear first in [Debian Unstable](https://wiki.debian.org/DebianUnstable).\n* If those packages don't introduce regressions or serious bugs, they can migrate to [Debian Testing](https://wiki.debian.org/DebianTesting).\n* When a new Debian release is published, those packages move to [Debian Stable](https://wiki.debian.org/DebianStable).\n\nSalsa CI helps increase the probability that packages can pass from Unstable to Testing reliably, quickly, and without issue.\nIn effect, it emulates the Debian build process, adding several quality checks to identify errors before they would affect Debian users. \nWhen new source code triggers a Salsa CI pipeline, 17 different jobs run to build and test it automatically.\nSalsa CI checks to see whether the to-be-uploaded packages build on multiple architectures (at the moment, amd64 and i386, and optionally on Arm), runs [autopkgtest test suites](https://wiki.debian.org/ContinuousIntegration/autopkgtest) to try to identify potential regressions, and checks for common errors with our custom linter, [lintian](https://wiki.debian.org/Lintian), among other tests.\nYou can view all the details at Debian's public GitLab instance (I maintain the `grep` package for Debian, so I'll offer that one as [an example of Salsa CI in action](https://salsa.debian.org/debian/grep/-/pipelines/576674)).\n\n![An overview of Salsa CI running on Debian's grep package](https://about.gitlab.com/images/blogimages/debian-grep-salsa-overview.png){: .shadow}\n\n## Life before Salsa CI\nMaintainers have been iterating on the Salsa CI pipeline for more than four years now. \nBut I have not forgotten what life as a package maintainer in the Debian community was like without it.\n\nMost of the work Salsa CI performs today is work that community members would otherwise need to perform manually. \nSo it proceeded slowly and was prone to more errors.\nWhile use of Salsa CI isn't compulsory for Debian maintainers, many choose to use it for their work because it saves them an incredible amount of time and effort — and because it leads to fewer breaking packages.\nMaintainers no longer need to run their own package tests locally; instead, Salsa performs this work remotely.\n\nAnd it works quickly.\nIdentifying issues with [Debian's primary CI system](https://ci.debian.net) when testing packages might require several hours, days, or even a month. \nSalsa CI reduces that time horizon to several *minutes* (or hours, in the worst cases), depending on the complexity of the package. For example:\n* Without Salsa CI, maintainers manually upload their packages and must wait for build results from the Debian build network (and they must do this for each architecture they wish to test). Usually, if a build fails, maintainers test on bespoke \"[porterboxes](https://wiki.debian.org/PorterBoxHowToUse)\" tailored to specific architectures. Using Salsa CI, however, maintainers can test x86 and Arm package builds easily — after a single `git push` command.\n\n* Running `autopkgtest` on [ci.debian.net](https://ci.debian.net/) (the official and central CI infrastructure for Debian) tests only the packages that have been built by the build servers and installed in the archive. `autopkgtest` is run for migration reference monthly. In Salsa CI, however, `autopkgtest` runs immediately after the amd64 build job has finished, decreasing review cycle times.\n\n## Salsa CI in the open source ecosystem\nOverall, the Debian community has been pleased with the progress Salsa CI maintainers have made since the tool's creation four years ago.\nOther open source communities are taking notice, too.\nFor instance, Salsa CI has become the basis for even more complex CI pipelines in projects like [Kali Linux](https://go.gitlab.com/G1XROS).\nWe're delighted to see that something we created to solve our own issues and improve our own work is making a positive impact on the open source ecosystem more broadly.\n\n*Editor's note: Debian developers [Alexander Wirt](https://gitlab.com/formorer) and [Otto Kekäläinen](https://gitlab.com/ottok) contributed to this article.*\n\n[Join us at Open Source Summit Europe 2023](https://go.gitlab.com/dPQ92t) to learn more about GitLab's dedication to open source.\n{: .note}\n",[675,268,1139],{"slug":1199,"featured":6,"template":679},"debian-customizes-ci-tooling-with-gitlab","content:en-us:blog:debian-customizes-ci-tooling-with-gitlab.yml","Debian Customizes Ci Tooling With Gitlab","en-us/blog/debian-customizes-ci-tooling-with-gitlab.yml","en-us/blog/debian-customizes-ci-tooling-with-gitlab",{"_path":1205,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1206,"content":1211,"config":1217,"_id":1219,"_type":16,"title":1220,"_source":17,"_file":1221,"_stem":1222,"_extension":20},"/en-us/blog/migrating-arch-linux-packaging-infrastructure-gitlab",{"title":1207,"description":1208,"ogTitle":1207,"ogDescription":1208,"noIndex":6,"ogImage":1110,"ogUrl":1209,"ogSiteName":713,"ogType":714,"canonicalUrls":1209,"schema":1210},"Migrating Arch Linux's packaging infrastructure to GitLab","Arch Linux developer Levente Polyak explains how the project recently migrated its packaging infrastructure to GitLab and what Arch Linux gained as a result.","https://about.gitlab.com/blog/migrating-arch-linux-packaging-infrastructure-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Migrating Arch Linux's packaging infrastructure to GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Levente Polyak\"}],\n        \"datePublished\": \"2023-09-11\",\n      }",{"title":1207,"description":1208,"authors":1212,"heroImage":1110,"date":1214,"body":1215,"category":14,"tags":1216},[1213],"Levente Polyak","2023-09-11","\nThree years ago, the Arch Linux community began a migration to the GitLab DevSecOps Platform to modernize our software development tooling and processes.\nWe recently announced a major moment on that journey: [migrating our entire packaging toolchain to Git and GitLab](https://archlinux.org/news/git-migration-completed/).\nThis move completely reshaped our packaging workflow, tooling, and storage — the very backbone of our package creation process.\n\nThe move has been pivotal for our continued success as a project.\nOur [package repositories](https://archlinux.org/packages/) contain nearly 14,000 packages at the time of this writing, and [GitLab's collaborative features](/pricing/feature-comparison/) empower our package maintainers to seamlessly collaborate, promoting efficient and effective teamwork.\nUsing GitLab as a central platform also enhances visibility across the project.\nWe can now effortlessly trace the history of changes, collaborate on enhancements and bugs, and follow the evolution of each package — all in a single place.\n\n> [Join GitLab at Open Source Summit Europe 2023](https://go.gitlab.com/dPQ92t) to learn more about our dedication to open source.\n\nI'm a devoted free open source software engineer and currently have the privilege of serving as the project leader of Arch Linux.\nIn this article, I'll explain how and why we undertook this complex, but ultimately worthwhile, endeavor.\n\n## Understanding Arch Linux's infrastructure\nTo understand the complexity of this migration, you'll first need to understand the history of Arch's infrastructure.\n\nCentral to our distribution are our [PKGBUILD](https://wiki.archlinux.org/title/PKGBUILD) packaging sources, which are the essential blueprints that shape each package installable with [pacman](https://archlinux.org/pacman/) from our official repositories. Previously, our [packaging infrastructure](https://wiki.archlinux.org/title/Creating_packages) relied on [Subversion](https://subversion.apache.org/) for managing our packaging sources.\n\nFor more than a decade of [Arch Linux's development](https://archlinux.org/releng/releases/), Subversion served as a reliable companion for working with our packaging source code. However, the open source software development landscape has transformed significantly since the advent of the Arch Linux project; technologies have advanced and collaboration dynamics have evolved (note, for example, the popularization of [DevOps](https://about.gitlab.com/topics/devops/) processes and practices).\n\nRecognizing the need to adapt and optimize, we started a journey that would shape the future of how members of the Arch Linux community work together. To enhance collaboration and pave the way for future improvements to Arch, we decided to undertake migration of our packaging sources to individual Git repositories, and we chose to host them with GitLab.\n\n## Migrating 14,000 Arch Linux packages\nThis would be no small task.\nCurrently, the Arch Linux community maintains 13,930 installable packages, all of which are now managed in 12,138 individual Git repositories.\nBut we knew the benefits would be worth the effort involved in such an enormous migration.\n\nFor example, one of the standout advantages of Git is its ability to empower packagers with a new level of insight into their work.\nThe ease of inspecting local history would become a game-changer, especially as packaging evolved into a collective effort, with multiple maintainers collaborating to refine and enhance individual packages (Subversion requires a client-server connection to inspect the history).\n\nBut the decision to migrate was not just about adopting Git.\nIt also reflected our aspiration to provide our community with an environment that fosters extensive collaboration. Our history with Subversion had shown its limitations in this regard (more on that in a moment).\nThe synergy between Git packaging repositories and the GitLab platform was evident; it opened doors to enhanced collaboration, offered powerful version control features, and laid the groundwork for more efficient packaging processes.\n\nThe migration of Arch Linux's packaging infrastructure to GitLab was the pinnacle of several factors aligning perfectly.\nThe need for a more robust collaboration platform, the growing prominence of Git, and the desire to utilize the benefits of modern version control converged to make this move a natural progression for Arch.\n\nWe decided it was time to get it done.\n\n## Three years and a weekend\nArch Linux has been gradually adopting and migrating operations to GitLab over the course of three years.\nExtending that migration to our packaging infrastructure was the next vital step of the process — and the pivotal moment of switching to GitLab hosting and workflow for packaging occurred within [the span of a single weekend](https://archlinux.org/news/git-migration-announcement/).\n\nA change of this magnitude touches the very core of our distribution, and it was only possible with thorough, meticulous preparation.\nFor weeks, our migration team diligently crafted [a runbook](https://md.archlinux.org/utjjQ-bQTsipIKntPrpf8g#) that ensured every major aspect and change were considered, minimizing risk and boosting our confidence.\n\nWhen our concentrated migration effort began, the migration team focused entirely on this rollout, everyone collaborating in a [Jitsi](https://meet.jit.si/) video call with screen sharing.\nThe strategic choice of a weekend for performing the migration aligned perfectly with our volunteer-driven community, offering sufficient time for a buffer and quick resolution to any unforeseen hiccups.\n\nThe first challenge was transferring our extensive Subversion history to GitLab. For some time, we had been running `git-svn` with a timer to be able to provide some packaging history to another repository.\nOur [custom tooling](https://gitlab.archlinux.org/archlinux/arch-svn-package-to-git/) made use of `git-svn` imports, which was a gigantic monorepo containing all packages as individual branches.\n\nOur migration solution was a carefully crafted script that used [git-filter-repo](https://github.com/newren/git-filter-repo), of which we could run several instances in parallel and which also supported the ability to convert only repositories that changed since the last run (determined by deltas).\nThe script also filtered history, commit messages, rewrote author data to incorporate our GitLab user handles, filtered unwanted files, and more.\nAdditionally, we tagged all previous releases where we could determine the origin of the exact commit.\n\nBut the migration wasn't confined to a mere transfer of Subversion history to GitLab; it involved revisiting workflows, tools, and all software that interacted *with* the version control system.\nFrom redefining workflows to embracing new tools, every step was vital to ensuring that Arch Linux developed in a coherent way.\n\nWe also wanted to seize the moment as an opportunity to reimagine and revamp package maintainer tooling.\nSo we also created [pkgctl](https://man.archlinux.org/man/pkgctl.1.en), a modern interface that not only refreshed and streamlined our tooling but also enhanced user and contributor experience.\n\nFortunately, the entire migration flowed seamlessly.\nBy the end of the weekend, we had succeeded.\n\n## Benefits of a journey with GitLab\nOur packaging migration was the latest milestone in Arch Linux's overall journey with GitLab.\nMigrating our packaging infrastructure to GitLab allows us to maximize and enjoy those improvements even more.\n\nSince the Arch Linux community began [migrating to GitLab in 2020](https://gitlab.com/gitlab-com/marketing/developer-relations/open-source-program/gitlab-open-source-partners/community-support/-/issues/11), Arch maintainers and contributors have enjoyed a significantly improved experience interacting with and contributing to the project.\nThe advantages not only enhance our current workflows but also open up exciting possibilities for the future.\n\nHere's a rundown of the benefits we've seen from our overall migration so far.\n\n### Deeper collaboration\nBefore the migration, for example, lack of a dedicated collaborative platform for our packaging sources posed challenges to both users and package maintainers. While [Flyspray](https://wiki.archlinux.org/title/Flyspray), our bug tracker, was valuable, its scope was limited to tracking issues rather than facilitating meaningful collaboration.\nProposed changes were often submitted as patch files in attachments, resulting in a cumbersome experience for users suggesting improvements and maintainers reviewing these changes.\n\nThe process of iterating through these patch files was tedious because we lacked the ability to comment on specific lines (not to mention the ability to discuss diverse sub-topics in individual threads).\n\nToday, GitLab's standard [merge request](https://docs.gitlab.com/ee/user/project/merge_requests/) feature has improved this process dramatically. It helps us collaborate smoothly, allowing [threaded discussions](https://docs.gitlab.com/ee/user/discussions/index.html), precise comments, and [code suggestions](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/suggestions.html) on individual code segments. Although merge requests are a simple, staple feature, their impact on streamlining our processes is invaluable, serving as the bedrock of GitLab's collaborative strength.\n\nThe ability to seamlessly integrate issue tracking and merge requests within the same platform fosters a more cohesive and efficient workflow for our entire community. We're looking forward to tracking and managing packaging-related issues, bugs, and enhancements directly within GitLab soon.\n\n### Better automation\nOur use of [GitLab CI/CD](https://docs.gitlab.com/ee/ci/) has played a crucial role in automating our development work across our software projects.\n\nWe utilize CI/CD pipelines for everything from running tests to auditing dependencies—even publishing release artifacts, such as Rust crates, automatically using a tag pipeline. The efficiency we gain through this functionality is invaluable for ensuring the integrity and quality of our projects. We've realized some security improvements, too. Automating our usage of dependencies means we become aware of tracked security issues in our software projects used dependencies via commit pipelines, as well as scheduled pipelines (so we can bump and potentially deploy/release our software projects in case its necessary).\n\n### Stronger community\nAdopting GitLab has helped us better serve our community. The [Service Desk feature](https://docs.gitlab.com/ee/user/project/service_desk/) has emerged as a game-changer, offering a streamlined channel to manage specific user requests.\nThis integration with GitLab enhances the workflow without sacrificing overview.\n\nAnd recently, we've significantly increased our use of [GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/).\nWe rely on Pages for publishing documentation, monthly reports, our Web Key Directory and static sites, and we're enthusiastic about expanding its application in the future.\n\n## More than new tools\nArch Linux's migration wasn't just about adopting the latest tools. Our motivation for migrating — and the positive consequences of the upgrade — reflect the values of open source communities like ours, where working together is essential for moving forward.\nBy adopting GitLab, Arch Linux is improving our project's overall atmosphere, creating a space where contributions are welcomed, reviewed, and integrated more easily, and in a way that conforms to contemporary best practices.\n\nWe're proud to be [GitLab Open Source Partners](https://go.gitlab.com/BM5JwV), and we extend our gratitude to GitLab for providing a platform that seamlessly aligns with our vision.\n\n[Join GitLab at Open Source Summit Europe 2023](https://go.gitlab.com/dPQ92t) to learn more about our dedication to open source.\n{: .note}\n",[675,268,1139],{"slug":1218,"featured":6,"template":679},"migrating-arch-linux-packaging-infrastructure-gitlab","content:en-us:blog:migrating-arch-linux-packaging-infrastructure-gitlab.yml","Migrating Arch Linux Packaging Infrastructure Gitlab","en-us/blog/migrating-arch-linux-packaging-infrastructure-gitlab.yml","en-us/blog/migrating-arch-linux-packaging-infrastructure-gitlab",{"_path":1224,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1225,"content":1230,"config":1235,"_id":1237,"_type":16,"title":1238,"_source":17,"_file":1239,"_stem":1240,"_extension":20},"/en-us/blog/why-manjaro-builds-with-gitlab",{"title":1226,"description":1227,"ogTitle":1226,"ogDescription":1227,"noIndex":6,"ogImage":1110,"ogUrl":1228,"ogSiteName":713,"ogType":714,"canonicalUrls":1228,"schema":1229},"Why the Manjaro Linux distribution builds with GitLab","Watch this interview with the Manjaro project to learn why the Linux distribution chooses to build with GitLab.","https://about.gitlab.com/blog/why-manjaro-builds-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why the Manjaro Linux distribution builds with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Bryan Behrenshausen\"}],\n        \"datePublished\": \"2023-08-29\",\n      }",{"title":1226,"description":1227,"authors":1231,"heroImage":1110,"date":1232,"body":1233,"category":14,"tags":1234},[1135],"2023-08-29","\nThe [Manjaro](https://manjaro.org/) project is the newest member of the [GitLab Open Source Partners](https://go.gitlab.com/BM5JwV) community. Linux users know the Manjaro project as an [open source](https://go.gitlab.com/wYTY0o) operating system that is fast, reliable, and user-friendly. We recently caught up with project leaders [Philip Müller](https://gitlab.com/philm) and [Bernhard Landauer](https://gitlab.com/oberon-manjaro) to learn how GitLab helps the Manjaro community accomplish its great work.\n\n> [Join us at Open Source Summit Europe 2023](https://go.gitlab.com/dPQ92t) to learn more about GitLab's dedication to open source.\n\n## Why the Manjaro project moved to GitLab\nIn 2018, the Manjaro community decided to [adopt GitLab](https://gitlab.manjaro.org) as its development platform, citing several key motivations:\n* **Achieve greater data sovereignty.** By migrating to a new development platform, Manjaro wanted to gain greater control over project development infrastructure. The community now hosts its own dedicated GitLab instance, where all critical Manjaro development occurs. The move has meant greater freedom and autonomy for the community. \"It feels really good to self-host and have our own control,\" Landauer said.\n\n* **Empower a small group of volunteers.** Like so many other open source projects, Manjaro relies on the dedicated work of volunteer contributors from across the world. Müller explained that the project needed a toolkit that could equip a core group of 16 developers to maintain [more than 3,000 packages](https://gitlab.manjaro.org/packages) and foster a community of roughly 8,000 participants. GitLab's sophisticated [CI/CD functionality](https://docs.gitlab.com/ee/ci/) helps the community scale to empower its relatively small developer team to manage ever-increasing complexity.\n\n* **Expand monitoring capabilities.** Using GitLab grants community leads much greater visibility into the project's operations, Müller said. By configuring various activity feeds, maintainers can more efficiently monitor potential pipeline issues and build failures across projects in the Manjaro namespace. Adopting GitLab also produced an interesting network effect for Manjaro: Using the same platform as peers, dependencies, and upstream projects meant greater overall visibility into Manjaro's open source ecosystem. \"Projects like [GNOME and KDE are switching](https://go.gitlab.com/BM5JwV) also over to GitLab,\" Müller said. \"We can look at what the upstream is doing.\"\n\n## Watch the interview\nTo learn more about Manjaro's use of GitLab, watch the full interview.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Rn5IiI3--Ag\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n[Join us at Open Source Summit Europe 2023](https://go.gitlab.com/dPQ92t) to learn more about GitLab's dedication to open source.\n{: .note}\n",[675,268,1139],{"slug":1236,"featured":6,"template":679},"why-manjaro-builds-with-gitlab","content:en-us:blog:why-manjaro-builds-with-gitlab.yml","Why Manjaro Builds With Gitlab","en-us/blog/why-manjaro-builds-with-gitlab.yml","en-us/blog/why-manjaro-builds-with-gitlab",{"_path":1242,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1243,"content":1249,"config":1255,"_id":1257,"_type":16,"title":1258,"_source":17,"_file":1259,"_stem":1260,"_extension":20},"/en-us/blog/coordinating-documentation-projects-gitlab",{"title":1244,"description":1245,"ogTitle":1244,"ogDescription":1245,"noIndex":6,"ogImage":1246,"ogUrl":1247,"ogSiteName":713,"ogType":714,"canonicalUrls":1247,"schema":1248},"Coordinating major documentation projects with GitLab","Members of The Good Docs Project explain how to plan, coordinate, and release major documentation projects using GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669791/Blog/Hero%20Images/abstractprocess.png","https://about.gitlab.com/blog/coordinating-documentation-projects-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Coordinating major documentation projects with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Alyssa Rock\"},{\"@type\":\"Person\",\"name\":\"Aaron Peters, Member, Good Docs Project\"}],\n        \"datePublished\": \"2023-08-24\",\n      }",{"title":1244,"description":1245,"authors":1250,"heroImage":1246,"date":1252,"body":1253,"category":14,"tags":1254},[1251,1076],"Alyssa Rock","2023-08-24","\n[The Good Docs Project](https://thegooddocsproject.dev/) recently achieved a significant milestone: releasing [version v1.0.0 of our project](https://gitlab.com/tgdp/templates/-/releases/v1.0.0). It was an exciting moment for [our community of contributors](https://go.gitlab.com/16yEa3) dedicated to improving the quality of software documentation by sharing best practices — the first time we felt confident putting our production-ready documentation templates into the world for other software projects to review, use, and help us improve.\n\nOrganizing and executing a release of this magnitude requires extensive planning and sophisticated project management tools. Luckily, our community uses GitLab, so we had everything we needed at our disposal.\n\nIn this article, we'll explain how we used GitLab to meet our goal of bringing Version 1.0 (codenamed \"Capilano\") to the world. Our release process consists of four general phases:\n* [Scheduling](#scheduling-a-release)\n* [Planning](#planning-a-release)\n* [Tracking](#tracking-a-release)\n* [Releasing](#release-day)\n\nWe'll share how we use GitLab in each of those phases to achieve a successful project release.\n\n## Scheduling a release\n[The Good Docs Project](https://about.gitlab.com/blog/meet-partner-the-good-docs-project/) releases template updates twice a year: on June 15 and December 15. Each of our releases receives both a number and a codename in honor of a famous bridge (because we're \"bridging the documentation gap for our users\"). Last December, for example, we issued [Version 0.3.0, codenamed \"Brooklyn Bridge\"](https://thegooddocsproject.dev/blog/template-release-0.3.0-using-our-own-templates/) release. In June, we finished [Version 1.0.0, which was codenamed \"Capilano\"](https://gitlab.com/tgdp/templates/-/releases/v1.0.0) for [a bridge in Canada](https://en.wikipedia.org/wiki/Capilano_Suspension_Bridge)). And now we're starting work on the [Dragon](https://gitlab.com/groups/tgdp/-/milestones/4) release, which gets its name from [a bridge on the River Han in Vietnam](https://en.wikipedia.org/wiki/Dragon_Bridge_(Da_Nang)).\n\n![The Good Docs Project Release Process](https://about.gitlab.com/images/blogimages/tgdp-release-cycle.jpg){: .shadow}\n\nOur release schedule prioritizes *work time* over *work scope*. We set goals we wish to accomplish with every release, then use the release deadline as a motivational tool to get projects done. However, we [don't delay releases](https://handbook.gitlab.com/teamops/measurement-clarity/#prioritize-due-dates-over-scope) for a particular release initiative per se. Instead, we try to accurately scope and track our release initiatives to ensure they complete in time for their desired release.\n\n## Planning a release\nFor the first month of our six-month release cycle, each of The Good Docs Project's working groups or teams determines initiatives for the cycle. They usually hold an initial brainstorming session, which involves using a synchronous collaboration tool (like Miro) to determine which ideas to include as official goals for the release. But after confirming and committing what we want to do with each release, we migrate all those objectives to GitLab, where we communicate them to the rest of the community. That process generally looks like this:\n* Open an issue in a release's respective repository and we tag it with the milestone for that release\n* Attach [scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) to indicate which working group is assigned to that task\n* Assign an initial [health status](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#health-status) of \"On track\"\n* Assign the issue [a weight](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html) to indicate its importance\n\nThen, in a general community meeting where we end the release planning process, everyone identifies what they'll commit to, and we begin using the milestone to track progress and [a global project board to track the health status](https://gitlab.com/groups/tgdp/-/boards/5867329?milestone_title=Dragon%20release) when we do stand-ups to [report on progress](https://gitlab.com/groups/tgdp/-/milestones/4).\n\nTo prioritize effectively, we draw on guidance from our team of template product managers, who [perform extensive user research](https://tinyurl.com/template-brainstorming-report) into the templates our users or potential users think we should add to the roadmap. We attend conferences and engage with both technical writers and developers to hear what they want from our product. This team of product managers then distills this information into a long-term product roadmap that informs which template issues are strategically important to our project. We then translate that roadmap into issues in [our project backlog](https://gitlab.com/tgdp/templates/-/issues/?sort=updated_desc&state=opened&first_page_size=100).\n\n## Tracking a release\nGaining access to [GitLab's project management features](/pricing/feature-comparison/) was one of our primary motivations for adopting the platform in the first place. These features allow us to track and monitor our progress toward a release. We love that with GitLab we can manage multiple sub-projects and repositories under our organization, but still view all the issues on a \"single pane of glass.\" This allows working groups and teams to work in their individual repositories, but gives us a high-level overview of their work at the organizational level, using features like milestones and scoped labels.\n\nTo track our releases, we configure a project milestone that runs for the full release time period. The milestone shows all the initiatives we're working on, as well as our progress toward each on [an organization-wide burndown chart](https://gitlab.com/groups/tgdp/-/milestones/3#tab-issues). We use [scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) (labels that can only be assigned to one value at a time) on each issue to track which working group is working on that initiative. We also use GitLab's [health status feature](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#health-status) to track whether the initiative is on track or at risk of falling behind schedule. On top of that, we create a project board that helps us visualize all the project's active issues and initiatives, filtered by each working group. Our project board provides insights into the work each group is doing and gives us a sense of the release's overall progress toward our release goals.\n\nThese boards are a focal point of our weekly general meetings. We review the milestone and project board, then check in with working group and team leads to make sure their work toward the release is going well. These meetings are opportunities to identify potential blockers preventing (or threatening to prevent) the work from getting done — or to communicate if any of our earlier estimates need to be adjusted. We build some flexibility into our release planning and tracking processes in case we need to make mid-release changes or course corrections. For example, we determine which individual template projects we'll add them to a release *during the release process itself, rather than during the release planning stage we descibed earlier. Since those projects are dependent on volunteer work that can't always be controlled by the project leads, we wait to officially add them to a release until we can be certain a template project will be ready for release day.\n\n## Release day\nWhen release day finally arrives, our [Tech Team](https://thegooddocsproject.dev/who-we-are/#tech-team) meets to tag the release in the templates repository and build our artifacts, including all our zip files and tarballs for our templates. To do that, the team:\n* Verifies that all merge requests are complete\n* Creates a tag for the templates repository for the main branch and adds a tag message indicating it is for a release\nAdds a release title, tags it with our milestone for that release, confirms the date, and adds the release notes (using [our community's own release notes template](https://gitlab.com/tgdp/templates/-/releases/v1.0.0), of course) by using the `Create Release` button on the release screen\n* Creates the release; GitLab generates all the files from our repository, including zips, tarballs, and JSON artifacts\n* Publishes a link to our release and the artifacts on our website\n\nWe try to ensure we've recognized and tagged every project member who contributed directly to the templates release. That includes people who wrote templates, improved existing templates, or created examples for our templates. Then, the Tech Team publishes the artifacts and release notes to our website and publishes an announcement to all our internal and external communication channels.\n\nWe believe it's important to take breaks. For that reason, our project always takes a three-week break after release day. For those three weeks, we encourage all our project members to get some well-deserved rest and relaxation. We don't hold any meetings during this time, and we encourage people to only communicate lightly with other project members.\n\nThen we regroup in July or January — and start the release process all over again!\n\nIt's not too late to join our next release and experience this process firsthand. Just visit [The Good Docs Project community page](https://thegooddocsproject.dev/community/) to learn how to get started.\n\nThe [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) are building the future of open source on GitLab. Connect with them on [Gitlab.com](https://gitlab.com/gitlab-com/marketing/community-relations/open-source-program/gitlab-open-source-partners).\n{: .note}\n",[675,268,1139],{"slug":1256,"featured":6,"template":679},"coordinating-documentation-projects-gitlab","content:en-us:blog:coordinating-documentation-projects-gitlab.yml","Coordinating Documentation Projects Gitlab","en-us/blog/coordinating-documentation-projects-gitlab.yml","en-us/blog/coordinating-documentation-projects-gitlab",{"_path":1262,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1263,"content":1269,"config":1274,"_id":1276,"_type":16,"title":1277,"_source":17,"_file":1278,"_stem":1279,"_extension":20},"/en-us/blog/next-gen-telecom-with-gitlab",{"title":1264,"description":1265,"ogTitle":1264,"ogDescription":1265,"noIndex":6,"ogImage":1266,"ogUrl":1267,"ogSiteName":713,"ogType":714,"canonicalUrls":1267,"schema":1268},"Developing next-generation telecommunications with GitLab","Learn more about Project Sylva, a cross-industry collaboration to build a cloud-native, open source telecommunications platform using GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682864/Blog/Hero%20Images/telecomabstract.jpg","https://about.gitlab.com/blog/next-gen-telecom-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Developing next-generation telecommunications with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Bryan Behrenshausen\"}],\n        \"datePublished\": \"2023-08-07\",\n      }",{"title":1264,"description":1265,"authors":1270,"heroImage":1266,"date":1271,"body":1272,"category":14,"tags":1273},[1135],"2023-08-07","\nIn November 2022, the Linux Foundation Europe [announced the launch of Project Sylva](https://www.linuxfoundation.org/press/linux-foundation-europe-announces-project-sylva-to-create-open-source-telco-cloud-software-framework-to-complement-open-networking-momentum), a cloud-native, [open source](https://go.gitlab.com/spHNym) telecommunications software stack. The initiative represents a cross-industry collaboration between major telecommunications providers and vendors (Telefonica, Telecom Italia, Orange, Vodafone, Deutsche Telekom, Ericsson, and Nokia), who formally agreed to collaborate on building the foundation of a next-generation telecommunications system in the open.\n\nToday that work continues [on GitLab](https://gitlab.com/sylva-projects), where the project is gaining momentum as its contributor community grows. Eager to hear what that community has achieved since last year, I sat down with [André Vieira](https://gitlab.com/andre.macedo.av), the project's communications lead. \n\nWatch our interview to learn more about Sylva's guiding mission and vision, its successes, its challenges, and its future.\n\n## Watch the interview\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/mblgJpmvkZI\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n",[675,268,1139],{"slug":1275,"featured":6,"template":679},"next-gen-telecom-with-gitlab","content:en-us:blog:next-gen-telecom-with-gitlab.yml","Next Gen Telecom With Gitlab","en-us/blog/next-gen-telecom-with-gitlab.yml","en-us/blog/next-gen-telecom-with-gitlab",{"_path":1281,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1282,"content":1288,"config":1295,"_id":1297,"_type":16,"title":1298,"_source":17,"_file":1299,"_stem":1300,"_extension":20},"/en-us/blog/building-new-fedora-project-website-with-gitlab",{"title":1283,"description":1284,"ogTitle":1283,"ogDescription":1284,"noIndex":6,"ogImage":1285,"ogUrl":1286,"ogSiteName":713,"ogType":714,"canonicalUrls":1286,"schema":1287},"How GitLab helped Fedora build websites and community","Learn how the Fedora Project recently modernized its web development practices and streamlined team workflows with GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682851/Blog/Hero%20Images/communityhands.jpg","https://about.gitlab.com/blog/building-new-fedora-project-website-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How building modern websites with GitLab led to a healthier Fedora Project community\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Akashdeep Dhar\"}],\n        \"datePublished\": \"2023-07-11\",\n      }",{"title":1289,"description":1284,"authors":1290,"heroImage":1285,"date":1292,"body":1293,"category":14,"tags":1294},"How building modern websites with GitLab led to a healthier Fedora Project community",[1291],"Akashdeep Dhar","2023-07-11","\nWhen [Fedora Linux 38](https://fedoraproject.org/) debuted in April 2023, the Fedora Project community and I had an extra reason to celebrate. The first item in the community's [official release annoucement](https://fedoramagazine.org/announcing-fedora-38/) was one we were extremely proud of: our brand-new Fedora Project websites.\n\nThe launch of the new websites was the culmination of many months of good, old-fashioned community contribution from the \n[Fedora Websites and Apps team](https://gitlab.com/fedora/websites-apps) and other teams such as [Fedora Infrastructure](https://pagure.io/fedora-infrastructure), [Fedora Marketing](https://docs.fedoraproject.org/en-US/marketing/), \n[Fedora Design](https://fedoraproject.org/wiki/Design), and many more teams. This effort didn't just involve the development of the refreshed websites; it also involved rearchitecturing the team's technical stack and aligning our workflows with modern industry's best practices. \n\nIn this article, I will explain how migrating our workflow to GitLab helped us to not only build refreshed websites for the Fedora Project but also reimagine and streamline our community's process for building, maintaining, testing, and deploying them. The result: new workflows that redefine our team's processes to incentivize contribution and avoid the looming threat of potential contributor burnout – not to mention the elegant websites themselves.\n\n## Why we embarked on this effort\nAbout two years ago, four Fedora Project community members ([Ramya Parimi](https://gitlab.com/ramyaparimi), [Nasir Hussain](https://gitlab.com/nasirhm), [Justin W. Flory](https://gitlab.com/jwflory), and [myself](https://gitlab.com/t0xic0der)) were working on a project together when we discovered that only a tiny group of volunteer contributors maintained our websites. We immediately faced a dilemma that's common in many free and open source projects: Should that tiny group disband or disappear, we were at risk of not being able to maintain our websites and applications. Also, we didn't want the volunteer contributors to get burnt out under the constant stress of maintaining these projects. We needed more hands on deck, and we needed them quickly.\n\nSo our former Fedora Community Architect (the position was then called Fedora Community Action and Impact Coordinator, or FCAIC), [Marie Nordin](https://gitlab.com/riecatnor), helped us kickstart a community initiative that inspired us to not only refresh Fedora Project websites and applications but also establish more reliable processes and workflows around them, too.\n\nThat second part is incredibly important. We focused on enhancing the visual appeal and user experience of our websites — diligently adhering to the best accessibility practices, implementing a native dark mode that aligns with the user's system theme, and effectively advocating for our offerings to the best of our abilities (among other things). But we needed to solve the problem of maintainability, too. That would involve addressing some underlying issues that, although they looked deceptively simple on the surface, profoundly influenced the long-term sustainability of the team's work. Our goal was to ensure that even when *we* were not around, contributors who would do this work *after* us would be able to set things up and maintain them in the long run without issue.\n\nTo recruit more contributors, we needed to align the way our team worked with current industry practices. Adopting GitLab helped us do that.\n\n## How GitLab helped simplify, unify, and standardize\nHistorically, the website development team employed a range of tools as part of our workflows. Some we developed internally; others we acquired externally and integrated into our infrastructure. But these tools weren't always compatible with one another, meaning extra effort on our part (establishing a standardized business language for effective communication of work plans, progress obstacles, task updates, etc.). That not only impacted our operational efficiency but also drained our resources (for example, we were dedicating meetings solely to the purpose of ensuring everyone was aligned and understood the processes).\n\nAdopting GitLab helped alleviate that burden, because it's [a single, comprehensive platform](https://about.gitlab.com/stages-devops-lifecycle/). Our team got acclimated to capabilities like creating and tagging issues and epics to organize work, building Kanban boards and Gantt charts to map work-in-progress and construct functional timelines, and incorporating merge requests as progress indicators in a comprehensive project overview. We then understood how the cohesive nature of GitLab's approach to most aspects (if not all) of the software development lifecycle significantly enhanced our distributed team's overall efficiency.\n\nBut we use GitLab for more than just planning and implementation. We completely rewrote the technology stack using industry-standard static site-generating libraries like [NuxtJS](https://v2.nuxt.com/). GitLab's ability to create and deploy static sites helps us automate our deployment workflow. Then we coupled the revamped frontend with the [NetlifyCMS](https://v1.netlifycms.org/) content management system that relies on GitLab as its core. We also simplified the translation pipeline for localizing and internationalizing our website content. By employing continuous integration tools, we were able to generate dynamic test deployments to evaluate our websites before deploying them to the production environment. That success also prompted us to utilize GitLab for storing meeting logs and documentation, streamlining our project management processes even further.\n\nHere's an example.\n\nIn the past, when our websites were based on [Frozen Flask](https://pypi.org/project/Frozen-Flask/), we used various shell scripts to maintain it. These scripts would create an [OCI](https://opencontainers.org/) container using [Podman](https://podman.io/), build static files, perform translations, and serve the website. You can still find the [deprecated](https://pagure.io/fedora-websites) [repositories](https://pagure.io/fedora-web/websites/) where this was the standard development, testing, and deployment method. Although this process was automated using Ansible in our community infrastructure, it seemed complex for less experienced contributors.\n\nAfter transitioning to GitLab, we could deploy to our fast-changing staging environments directly from [GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/) while the slow-changing production environment remained on the community infrastructure. We also utilized GitLab's CI/CD features to test merge requests with ephemeral deployment environments. Since the automation is integrated into the project itself, any push to the primary branch or merge request triggers a deployment workflow. This consolidation of automation into a single unit has further streamlined our processes.\n\n## Better workflow, healthier community\nChanges like these were critical to the Fedora Project's overall [mission to foster an inviting environment](https://docs.fedoraproject.org/en-US/project/#_our_community) for contributors. Our new GitLab-centric workflow improved the experience for team members who wanted to contribute to documenting and translating content without having to navigate the technical intricacies of using Git. By lowering the entry barrier, we aimed to attract prospective newcomers and promote a more inclusive team dynamic.\n\nAs a result, we saw content contributions from other teams. And then, gradually, more folks joined us in our revamp efforts, helping to [make this community initiative a success](https://communityblog.fedoraproject.org/tag/websites-and-apps-initiative-wrapup/).\n\n*The [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) are building the future of open source on GitLab. Connect with them on [Gitlab.com](https://gitlab.com/gitlab-com/marketing/community-relations/open-source-program/gitlab-open-source-partners).*\n\nPhoto by [Hannah Busing](https://unsplash.com/@hannahbusing?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on Unsplash.\n{: .note}\n\n\n",[675,268,1139],{"slug":1296,"featured":6,"template":679},"building-new-fedora-project-website-with-gitlab","content:en-us:blog:building-new-fedora-project-website-with-gitlab.yml","Building New Fedora Project Website With Gitlab","en-us/blog/building-new-fedora-project-website-with-gitlab.yml","en-us/blog/building-new-fedora-project-website-with-gitlab",{"_path":1302,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1303,"content":1309,"config":1314,"_id":1316,"_type":16,"title":1317,"_source":17,"_file":1318,"_stem":1319,"_extension":20},"/en-us/blog/meet-partner-the-good-docs-project",{"title":1304,"description":1305,"ogTitle":1304,"ogDescription":1305,"noIndex":6,"ogImage":1306,"ogUrl":1307,"ogSiteName":713,"ogType":714,"canonicalUrls":1307,"schema":1308},"How The Good Docs Project uses GitLab for documentation as code and more","In this video interview, meet our new Open Source Partner, The Good Docs Project, and learn about the benefits they are extracting from the DevSecOps platform.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682841/Blog/Hero%20Images/documentation1.jpg","https://about.gitlab.com/blog/meet-partner-the-good-docs-project","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How The Good Docs Project uses GitLab for documentation as code and more\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Bryan Behrenshausen\"}],\n        \"datePublished\": \"2023-07-06\",\n      }",{"title":1304,"description":1305,"authors":1310,"heroImage":1306,"date":1311,"body":1312,"category":14,"tags":1313},[1135],"2023-07-06","\n\n[The Good Docs Project](https://thegooddocsproject.dev/welcome/) wants to help improve software documentation across the entire [open source](https://go.gitlab.com/spHNym) ecosystem. The community provides templates and other resources to help open source developers write, maintain, and improve project documentation. Last year, they voted to migrate to GitLab. Since then, they've discovered how using an all-in-one DevSecOps platform can streamline and accelerate work in open source communities like theirs.\n\nThey've now joined the [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) community, and they're sharing their knowledge and resources with other open source projects also using GitLab to build a world where anyone can contribute.\n\nI sat down with some community members from The Good Docs Project to learn what brought them together, what motivates their work, and where they're headed next.\n\nIn this interview, you'll learn:\n* How switching to GitLab enabled an open source project to unify planning, development, and testing work onto a single platform\n* How a community of technical writers and editors uses GitLab to develop documentation as code\n* How an open source project built community-focused git toolchain training on GitLab\n\n### Watch the interview\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Bek7vLmNmME\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Learn more\n\nThe [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) are building the future of open source on GitLab. Connect with them on [Gitlab.com](https://gitlab.com/gitlab-com/marketing/community-relations/open-source-program/gitlab-open-source-partners).\n\nCover image by \u003Ca href=\"https://unsplash.com/@beatriz_perez?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Beatriz Pérez Moya\u003C/a> on \u003Ca href=\"https://unsplash.com/photos/XN4T2PVUUgk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Unsplash\u003C/a>  \n{: .note}\n",[675,268,1139],{"slug":1315,"featured":6,"template":679},"meet-partner-the-good-docs-project","content:en-us:blog:meet-partner-the-good-docs-project.yml","Meet Partner The Good Docs Project","en-us/blog/meet-partner-the-good-docs-project.yml","en-us/blog/meet-partner-the-good-docs-project",{"_path":1321,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1322,"content":1328,"config":1333,"_id":1335,"_type":16,"title":1336,"_source":17,"_file":1337,"_stem":1338,"_extension":20},"/en-us/blog/interview-the-open-group",{"title":1323,"description":1324,"ogTitle":1323,"ogDescription":1324,"noIndex":6,"ogImage":1325,"ogUrl":1326,"ogSiteName":713,"ogType":714,"canonicalUrls":1326,"schema":1327},"Get to know our newest open source partner, The Open Group","The Open Group leaders explain how the organization uses GitLab to build and maintain open standards for transformative digital technologies.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679170/Blog/Hero%20Images/migration-data.jpg","https://about.gitlab.com/blog/interview-the-open-group","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Get to know our newest open source partner, The Open Group\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Bryan Behrenshausen\"}],\n        \"datePublished\": \"2023-06-20\",\n      }",{"title":1323,"description":1324,"authors":1329,"heroImage":1325,"date":1330,"body":1331,"category":14,"tags":1332},[1135],"2023-06-20","\n\nFor more than 30 years, [The Open Group](https://www.opengroup.org/) has served as a steward and champion of [open source](https://go.gitlab.com/spHNym) technologies, helping companies achieve business objectives through [open technological standards](http://www.opengroup.org/standardsprocess/main.html). Today, many of the group's approximately 900 member organizations participate in the work of ensuring critical digital technologies remain open and accessible.\n\nThe Open Group recently joined the [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) community, where it can connect with other large-scale, open source consortia and projects using GitLab to advance the state of the open source art. So I brewed a cup of tea and sat down with two of the group's team members — Vice President and CTO [Andras Szakal](https://pages.opengroup.org/aszakal) and GitLab administrator [David Diederich](https://pages.opengroup.org/divido) — to hear how using GitLab helps them achieve their group's mission. \n\nIn this interview, you'll learn how:\n\n* [GitLab CI/CD](https://about.gitlab.com/features/continuous-integration) helps the group build scalable open source projects\n* adopting GitLab's integrated analysis tools helped the organization deploy complex solutions without the [DevOps tax](https://about.gitlab.com/blog/too-many-toolchains-a-devops-platform-migration-is-the-answer/#eliminating-the-devops-tax)\n* GitLab serves as the foundation of the organization's approach to digital transformation\n\n## Watch the interview\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0--qGhH-MBQ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Learn more\nThe [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) are building the future of open source on GitLab. Connect with them on [Gitlab.com](https://gitlab.com/gitlab-com/marketing/community-relations/open-source-program/gitlab-open-source-partners).\n",[675,268,1139],{"slug":1334,"featured":6,"template":679},"interview-the-open-group","content:en-us:blog:interview-the-open-group.yml","Interview The Open Group","en-us/blog/interview-the-open-group.yml","en-us/blog/interview-the-open-group",{"_path":1340,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1341,"content":1347,"config":1353,"_id":1355,"_type":16,"title":1356,"_source":17,"_file":1357,"_stem":1358,"_extension":20},"/en-us/blog/major-league-gitlab-hacking",{"title":1342,"description":1343,"ogTitle":1342,"ogDescription":1343,"noIndex":6,"ogImage":1344,"ogUrl":1345,"ogSiteName":713,"ogType":714,"canonicalUrls":1345,"schema":1346},"Major League Hacking: Students contribute to feature updates","Our latest program participants explain their projects, their results, and the lessons they learned.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663736/Blog/Hero%20Images/a-deep-dive-into-the-security-analyst-persona.jpg","https://about.gitlab.com/blog/major-league-gitlab-hacking","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Major League Hacking: Student fellows contribute to platform feature updates\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Bryan Behrenshausen\"}],\n        \"datePublished\": \"2023-05-30\",\n      }",{"title":1348,"description":1343,"authors":1349,"heroImage":1344,"date":1350,"body":1351,"category":14,"tags":1352},"Major League Hacking: Student fellows contribute to platform feature updates",[1135],"2023-05-30","\n\nContributing to [open source](https://go.gitlab.com/spHNym) projects [like GitLab](https://gitlab.com/gitlab-org) can be a powerful way to learn software development. Just ask [Mughees Pervaiz](https://gitlab.com/Mughees_), who is studying computer science at the University of South Asia, and [Young Jun Joo](https://gitlab.com/youngjun827), who is studying mathematics and economics at the University of Waterloo in Canada. They recently contributed to GitLab as part of a fellowship with [Major League Hacking](https://mlh.io/about), a Certified B corporation working to empower tomorrow's technology leaders. The fellows' [12-week program recently concluded](https://fellowship.mlh.io/), but before it was over, we gave them one final assignment: Explain your favorite contribution to GitLab during your fellowship.\n\nHere's what they had to say.\n\n## Mughees Pervaiz\nDuring my internship, I was a part of the GitLab Foundation team under the mentorship of our maintainer, [James Rushford](https://gitlab.com/jrushford). My primary responsibility was to improve both the developer and user experience on GitLab. \n\nMy favorite contribution was helping to update expand/collapse buttons in roadmaps [from link buttons to tertiary buttons](https://gitlab.com/gitlab-org/gitlab/-/issues/396775). Before the changes, the feature was using old components, and I updated it to new GitLab UI components. We had to [migrate the expand/collapse buttons](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117242) that appear in the roadmap tree drawer. So we were working with the tree view (or, you could say, the 'child components' of the roadmap) and, because of this, it was very difficult for me to find the right file from GitLab's very large codebase.\n\nMaking this contribution taught me a lot about working with the GitLab codebase — specifically about making changes to the front-end user interface. I had to work with different GitLab components, such as the epic item details (vue component), epic item details (js component), and the front-end JavaScript libraries such as [Jest](https://jestjs.io/), in order to test or implement this feature.\n\nThis contribution also helped me develop my collaboration and communication skills. I had to work closely with other members of the GitLab community, including designers, product managers, and other contributors, in order to refine the feature and ensure that it aligned with GitLab's design principles and user experience goals.\n\nI also learned not to jump into coding without understanding an issue completely. Here, James helped me quite a bit: When I asked for his guidance, he responded with the following questions:\n\n- What is your understanding of the problem?\n- What did you try so far?\n- What did you find so far?\n- What are your next ideas?\n- Where did you look for information?\n\nAt first, I was confused. *Why is he asking me these questions instead of helping me?* But following James' technique really helped me with the issue, and I solved the problem by myself. At that moment, one of the most important lessons was clear to me: Don't underestimate myself. James wanted me to go beyond my limits, get out of the box, and try to solve the issue by myself so I could have a better understanding of what was happening in the codebase. So to anyone wishing to contribute to GitLab, I would say: Believe in yourself and give your best, and make sure you read the issue closely to develop a good understanding of the problem you're trying to solve.\n\n## Young Jun Joo\nDuring my Major League Hacking fellowship with GitLab, I worked on [improving the GitLab search function](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111741). Some GitLab users were experiencing a slow search experience — and as a user myself, I understood the importance of having a quick and efficient search function. I wanted to help make that a reality for other users.\n\nSo I [implemented a memoization algorithm](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/112606) that caches search results. Now, if a user searches for the same word multiple times, the search results will be retrieved from the cache instead of being recalculated each time. This results in a faster and more efficient search experience for GitLab users.\n\nMy contribution to GitLab was significant because it improved the search function's performance and efficiency, making it more reliable and user-friendly. Working on this project taught me a lot about optimization and efficiency in software development. I also gained a deeper understanding of how memoization algorithms work and how they can be used to improve performance.\n\nMy work on this project not only was extremely rewarding but also had a positive impact on GitLab and its users, who can now quickly and easily search for the information they need without experiencing lag or delays. I'm proud to have made a meaningful contribution to such a valuable tool for software development, and grateful for the opportunity to have worked with such a talented team of developers.\n\n## Your turn\nWant to improve your open source development skill by contributing to GitLab? You can start right now by reviewing the project's [list of outstanding issues](https://gitlab.com/groups/gitlab-org/-/issues/?sort=created_date&state=opened&label_name%5B%5D=quick%20win&first_page_size=100) (hint: start with issues labeled `quick win`). And be sure to connect with our [community on Discord](https://discord.gg/gitlab). We'd love to meet you.\n",[675,268,1139],{"slug":1354,"featured":6,"template":679},"major-league-gitlab-hacking","content:en-us:blog:major-league-gitlab-hacking.yml","Major League Gitlab Hacking","en-us/blog/major-league-gitlab-hacking.yml","en-us/blog/major-league-gitlab-hacking",{"_path":1360,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1361,"content":1367,"config":1371,"_id":1373,"_type":16,"title":1374,"_source":17,"_file":1375,"_stem":1376,"_extension":20},"/en-us/blog/building-inclusive-gaming-community-gitlab",{"title":1362,"description":1363,"ogTitle":1362,"ogDescription":1363,"noIndex":6,"ogImage":1364,"ogUrl":1365,"ogSiteName":713,"ogType":714,"canonicalUrls":1365,"schema":1366},"Building a more inclusive gaming community with GitLab","Meet the Friendly Linux Players, an open source community focused on making video gaming less intimidating and more welcoming for everyone.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749672079/Blog/Hero%20Images/videogamer.jpg","https://about.gitlab.com/blog/building-inclusive-gaming-community-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Building a more inclusive gaming community with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Bryan Behrenshausen\"}],\n        \"datePublished\": \"2023-05-15\",\n      }",{"title":1362,"description":1363,"authors":1368,"heroImage":1364,"date":1369,"body":1370,"category":14},[1135],"2023-05-15","\nThe Friendly Linux Players ([FLiP](https://friendlylinuxplayers.org/)) get it: Video gaming on Linux-based platforms has never been a straightforward, uncomplicated affair. In fact, it's been notoriously intimidating.\n\nA community of open gaming enthusiasts, FLiP wants to build a better future for gaming on Linux — one that begins with a more inclusive culture and participatory spirit.\n\nThe group recently joined the [GitLab for Open Source Program](https://go.gitlab.com/SEUvzJ), and I caught up with some of their members — [Andrew Conrad](https://gitlab.com/her0) (he/him), [Lara Flynn](https://gitlab.com/CrimsonFork) (it/she), [Andrew K.](https://gitlab.com/signal9) (he/him), [Nell Hardcastle](https://gitlab.com/nell) (she/her), and [Stephan Lanfermann](https://gitlab.com/DerRidda) (he/him) — to learn more about how they're using GitLab to build a friendlier, more welcoming gaming community with open principles, protocols, and tools.\n\n**Tell me about the Friendly Linux Players. What brought your community together?**\n\nAndrew C.: Friendly Linux Players started with a couple ideas I had in 2017 for a new Linux gaming community. The most important of these ideas was creating a specifically inclusive space, which I don't think existed elsewhere in Linux gaming at the time.\n\nAndrew K.: One of our primary goals is to make gaming on Linux less intimidating for everyone, which we believe will further promote the growth of our community. With FLiP, you'll find a welcoming and supportive community of like-minded individuals who are passionate about gaming on Linux.\n\nLara: I joined sometime between 2017 and 2018. I didn't really think much of it, just was interested in playing games and Linux and that's where [Matrix's](https://matrix.org/) room search led me. At the time, I was blissfully unaware of the kinds of things one would deal with in an average \"gaming\" community, or why that would be of special impact to me. I remember being asked to read the [code of conduct](https://friendlylinuxplayers.org/conduct) and wondering why half the things even need to be specified. FLiP is the first community I decided to settle into and feel comfortable, which, evidently, I still do.\n\nAndrew C.: Another of my ideas was to create a place where anyone could host a gaming event. We were able to implement this idea earlier this year, using a new bot I made: [flip-matrix-bot](https://gitlab.com/FriendlyLinuxPlayers/flip-matrix-bot), which is available on GitLab.com. Since creating this, regularly hosted gaming events have brought a surge of membership and participation in the community.\n\n**What does a typical FLiP-hosted gaming event look like?**\n\nNell: Events usually [involve] getting together for a multiplayer cooperative or competitive game. We are mainly talking via voice chat while playing the game chosen for the event. For me, I've been learning a lot of the games we've been playing, so I've asked questions about how the game works or what's the best approach and strategies. There's also some general chatting about off-topic things before we start or once everyone has the basics of the game figured out.\n\nAndrew K.: When we have a gaming event on FLiP, we usually start by hopping on the Mumble (voice chat) server and making sure everyone's in before we get going. The host gives us the lowdown on how to join the game (like which server we're playing on) and then we're off! There's no pressure to stick around for a certain amount of time; you can come and go as you please. These events usually last from two to five hours.\n\nAndrew C.: Our first event was on January 29th. At the moment, we have 31 events scheduled on [the calendar](https://friendlylinuxplayers.org/events), through July 16th. We've held around one or two events per week. At most, we've had about seven participants joining each one.\n\n**What does flip-matrix-bot do to empower community members and promote a more inclusive environment?**\n\nAndrew C.: flip-matrix-bot is our community bot, which can be interacted with through a CLI-like interface in the [Matrix chat protocol](https://matrix.org/docs/guides/introduction). It is written in [Rust](/blog/rust-programming-language/). We use it primarily for scheduling events, sending reminders about events, and making event data available outside of our main Matrix room (such as in an iCalendar feed or [the events page of our website](https://friendlylinuxplayers.org/events)). One particularly fun implementation detail: Instead of using local files or a relational database, event data is stored as custom \"messages\" in a separate Matrix room. This makes it more portable, and lowers the requirements to build and run the bot. This helps realize another motivation behind my original dream of allowing anyone to volunteer to host a gaming event: It decouples event hosting from community admins and moderators, which allows for the events to be more community-driven. This lower barrier to entry makes it easier for people to host events at different times of day, to accommodate different regions (I live in the U.S., but the community is international), or for someone to host an event for a game that none of the community leadership owns. I am excited to participate in [the first event scheduled by a regular community member](https://friendlylinuxplayers.org/events/90efd648ab9fb34b), and I am dedicated to keeping this open to all.\n\n**So community members can also contribute to flip-matrix-bot if they'd like?**\n\nAndrew C.: Yes. I've worked to make it easier for people with different skill levels to contribute to flip-matrix-bot, including a [good for new contributors label on issues](https://gitlab.com/FriendlyLinuxPlayers/flip-matrix-bot/-/issues/?label_name%5B%5D=good%20for%20new%20contributors). Several community members have already contributed to the bot. One contribution even came from someone entirely new to Matrix bots and the Rust programming language, illustrating one benefit of our open approach.\n\n**Why do you think gamers are attracted to the community you're building?**\n\nAndrew C.: I think there are a few main categories of people who have interest in joining FLiP. Most community members probably already have an interest in playing games on Linux, and already have a PC or Steam Deck running Linux, though this is not a requirement to participate in the community. Many join because we have created a specifically inclusive space, which is not very common in any community, let alone ones allowing anonymity on the internet. Some like the option of joining regularly hosted gaming events, including several of my fellow GitLab team members. There are certainly members who are drawn to the fact that the community is centered around [Matrix](https://matrix.org/) and [Mumble](https://www.mumble.info), with open source clients/servers/specifications, as opposed to something like Discord.\n\nAndrew K.: For a long time, gaming on Linux was considered a niche hobby, but thanks to recent advancements in compatibility layers and the introduction of the Steam Deck, it has become a viable option for many gamers. However, there are still unique challenges and obstacles that Linux gamers face that gamers on other platforms don't. This is where FLiP comes in. I think our friendly community is a perfect match for gamers who are seeking others who share their struggles with gaming on Linux. We're always ready to offer assistance and guidance to help you overcome any issues you may encounter.\n\nLara: In my opinion, what makes this community so great is that it *doesn't* appeal to all gamers, but only those who don't spread the toxicity you'll find elsewhere.\n\nNell: Speaking as a more recent member, I've been gaming with Linux for a long time but was drawn to FLiP due to the inclusivity commitment. Many gaming groups are not concerned with this and they can be especially hostile for women. It takes planning and moderation work to make sure any online social group is being careful to not exclude people and I appreciate what this group does to make sure members are comfortable participating.\n\n**What measures do you take to ensure the community remains inclusive?**\n\nAndrew C.: I feel that a community cannot be *inclusive* unless it is known to always *exclude* those who would create an unsafe environment for others. So the most important aspect of how we ensure inclusivity is having a strong code of conduct, which we strictly enforce.\n\nNell: Beyond the code of conduct, I think our members make the extra effort to include people and provide a welcoming environment. Everyone involved cares about this and puts in effort.\n\nLara: The community does a great job promoting inclusivity, so it doesn't need many specific measures in place to stay friendly. So I suppose the biggest measure in place is to provide a safe space where folks are and feel heard, and where people can point to issues when they arise.\n\n**You mentioned compatibility and general availability as two barriers to popularizing gaming on Linux. What are some of the other barriers your community hopes to lower?**\n\nAndrew C.: Game compatibility and availability are technical challenges to playing games on Linux. The biggest challenges that FLiP tries to address are social ones. By creating a friendly and inclusive Linux gaming community, where people can feel safe participating, I like to think that we help make Linux gaming more accessible for many. Of course, we also have a [Tech Support](https://matrix.to/#/#tech-support:flip.earth) Matrix chat room, which allows for individual members to ask for technical help from the rest of the community.\n\n**How does using GitLab help you build and serve your community?**\n\nStephan: GitLab helps us embrace the 'free software by default' culture that many in the Linux community expect and FLiP swears by. What good is it to build our community exclusively on free software platforms and then keep the things we build ourselves a secret? [With GitLab](https://gitlab.com/FriendlyLinuxPlayers), everyone can see how FLiP is made, contribute to FLiP resources, and potentially re-use the software for their own benefit.\n\nNell: The accessibility of GitLab as a platform is excellent, and using a platform that is [well-aligned with our group's values](https://go.gitlab.com/spHNym) is nice. Being able to host the organizational tooling with public code management and allowing for member contributions and feedback is really valuable to building a community like this, where we really want to take that seriously.\n\n**Now perhaps the *most important* question: What are you playing right now? What games would you recommend?**\n\nNell: For FLiP's multiplayer events, I've really enjoyed [Deep Rock Galactic](https://store.steampowered.com/app/548430/Deep_Rock_Galactic/) and recently [Nebulous: Fleet Command](https://store.steampowered.com/app/887570/NEBULOUS_Fleet_Command/). I'm also playing [Dredge](https://store.steampowered.com/app/1562430/DREDGE/) at the moment; cozy fishing horror is perfect for the Steam Deck. I recently finished [Hi-Fi Rush](https://store.steampowered.com/app/1817230/HiFi_RUSH/) and I loved how polished and fun that was. I recommend it.\n\nLara: I've been recently getting back into [Teardown](https://teardowngame.com) and especially [Geometry Dash](https://store.steampowered.com/app/322170/Geometry_Dash/), which, funny thing, work way better on my setup than they would with the same hardware on Windows (I measured), despite not having native Linux releases. This is because of how much better Mesa's implementation of OpenGL is, compared to AMD's Windows drivers. Also [A YEAR OF SPRINGS](https://steamcommunity.com/app/1688580), a cute visual novel I can recommend to anyone and [Entropy: Zero 2](https://store.steampowered.com/app/1583720/Entropy__Zero_2/) (surely it would be \"Entropy: One“ at that point), [arguably](https://moddb.com/mods/entropy-zero-2/news/mod-of-the-year8) the best Hλlf-Life² mod there is, that also more recently got a native Linux release and is continuously updated, such as with the same controller/ Steam Deck friendly UI that Valve updated the original Portal and Hλlf-Life² with.\n\nStephan: I have been greatly enjoying the [Resident Evil 4 Remake](https://store.steampowered.com/app/2050650/Resident_Evil_4/), which is performing absolutely flawlessly for me on Linux on top of being an amazing game. Beyond that, I regularly go back to [Squad](https://store.steampowered.com/app/393380/Squad/) as my main multiplayer game.\n\nAndrew C.: I've been hosting most of the community's events so far, so I've played a variety of multiplayer games recently. Among those, I have also been enjoying Nebulous, where I can't stop thinking about different fleets I can create! In addition, I've been playing [Arma Reforger](https://store.steampowered.com/app/1874880/Arma_Reforger/), though I'm not sure if I would recommend it right now, as it is in a pretty early state. Along a very different vein, I recently picked up [Liftoff](https://store.steampowered.com/app/410340/Liftoff_FPV_Drone_Racing/), a first person quadcopter simulator.\n\n*Andrew Conrad and Stephan Lanfermann are founding members of FLiP. Andrew K., Lara Flynn, and Nell Hardcastle participate in FLiP as community moderators, software developers, and event participants.*\n\nCover image by [Julien Tromeur](https://unsplash.com/@julientromeur) on [Unsplash](https://www.unsplash.com).\n{: .note}\n",{"slug":1372,"featured":6,"template":679},"building-inclusive-gaming-community-gitlab","content:en-us:blog:building-inclusive-gaming-community-gitlab.yml","Building Inclusive Gaming Community Gitlab","en-us/blog/building-inclusive-gaming-community-gitlab.yml","en-us/blog/building-inclusive-gaming-community-gitlab",{"_path":1378,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1379,"content":1385,"config":1392,"_id":1394,"_type":16,"title":1395,"_source":17,"_file":1396,"_stem":1397,"_extension":20},"/en-us/blog/gitlab-operator-red-hat-certification",{"title":1380,"description":1381,"ogTitle":1380,"ogDescription":1381,"noIndex":6,"ogImage":1382,"ogUrl":1383,"ogSiteName":713,"ogType":714,"canonicalUrls":1383,"schema":1384},"GitLab Operator certified by Red Hat OpenShift","The GitLab Operator is now certified by Red Hat’s OpenShift standards, allowing users to install GitLab directly on an OpenShift cloud cluster.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682717/Blog/Hero%20Images/bi_worldwise_casestudy_image.png","https://about.gitlab.com/blog/gitlab-operator-red-hat-certification","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Operator certified by Red Hat OpenShift\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dilan Orrino\"}],\n        \"datePublished\": \"2023-05-11\",\n      }",{"title":1380,"description":1381,"authors":1386,"heroImage":1382,"date":1388,"body":1389,"category":14,"tags":1390},[1387],"Dilan Orrino","2023-05-11","\nGitLab and Red Hat have been technology partners for more than two years, collaborating on a number of projects. GitLab first started its integration with Red Hat’s OpenShift cloud-based container platform by introducing the [GitLab Runner Operator](https://catalog.redhat.com/software/container-stacks/detail/5e9877e96c5dcb34dfbb1ac9) in GitLab Version 13.3. The Runner Operator offered the capability to run pipeline tasks from an external GitLab instance to OpenShift clusters.\n\nOur next step was to more closely integrate with the OpenShift platform and alleviate the need to require the GitLab instance to run external to OpenShift-based infrastructure. [The GitLab Operator](https://docs.gitlab.com/operator/) is now certified by Red Hat, which enables the capability to install an instance of GitLab inside of an OpenShift cloud cluster.\n\n## Benefits of GitLab with Red Hat OpenShift\n\nThe [Operator framework](https://operatorframework.io/about/) offers many benefits, but the main reason we identified is that it would allow us to run a self-managed instance of GitLab inside an OpenShift cluster. The GitLab DevSecOps platform can be operated on the same trusted infrastructure as other applications and services within a customer's organization. \n\nThe Operator framework also delivers a streamlined installation and seamless version upgrades. As the GitLab Operator continues to be developed, we hope to add other elements of the Operator framework such as backup and recovery, comprehensive metrics, and auto-tuning and auto-scaling. GitLab plans to align our future cloud-native deployment model behind our Operator.\n\n![Capability model](https://about.gitlab.com/images/blogimages/gitlaboperatorcapabilitymodel.png){: .shadow}\n\n\n## Details of the Red Hat certification\n\nThe Red Hat Certification included aligning our application components with Red Hat’s Universal Base Image (UBI) when deploying through the Red Hat Marketplace. The Red Hat Certification also included meeting all of [Red Hat’s policy requirements](https://access.redhat.com/documentation/en-us/red_hat_software_certification/8.61#con-operator-requirements_openshift-sw-cert-policy-products-managed). The certification signifies GitLab being supported on OpenShift in collaboration with Red Hat. The Operator as a deployment method will be available as a recommended choice in Q3, but is available for testing now.\n\n## A technical milestone\n\nThe GitLab application is complex, so building an Operator to deploy it was a technical achievement for the GitLab and Red Hat engineering teams. Completing this operator certification is a significant milestone and gives customers the confidence and assurance that GitLab runs effectively, jointly supported by Red Hat, on OpenShift.\n\n![GitLab Operator install screen](https://about.gitlab.com/images/blogimages/gitlaboperatorinstall.png){: .shadow}\n\n\n## Try the GitLab Operator\n\n[The GitLab Operator](https://docs.gitlab.com/operator/) is available now for testing in the OpenShift console via the embedded OperatorHub, and will be production ready for GitLab instances in Q3 2023. Check out the [catalog listing](https://catalog.redhat.com/software/container-stacks/detail/5ec3fcb08b6f188e53644c0f) for links to documentation and installation instructions. For a self-managed free trial to host GitLab on your OpenShift cluster, [submit this form](/free-trial/?hosted=self-managed).\n",[283,675,1391],"cloud native",{"slug":1393,"featured":6,"template":679},"gitlab-operator-red-hat-certification","content:en-us:blog:gitlab-operator-red-hat-certification.yml","Gitlab Operator Red Hat Certification","en-us/blog/gitlab-operator-red-hat-certification.yml","en-us/blog/gitlab-operator-red-hat-certification",{"_path":1399,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1400,"content":1406,"config":1414,"_id":1416,"_type":16,"title":1417,"_source":17,"_file":1418,"_stem":1419,"_extension":20},"/en-us/blog/lets-all-search",{"title":1401,"description":1402,"ogTitle":1401,"ogDescription":1402,"noIndex":6,"ogImage":1403,"ogUrl":1404,"ogSiteName":713,"ogType":714,"canonicalUrls":1404,"schema":1405},"Let's all search!","We spoke with you about our search tools. Now we've got some issues we'd like your help on.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679339/Blog/Hero%20Images/AdvancedSearch.png","https://about.gitlab.com/blog/lets-all-search","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Let's all search!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Will Leidheiser\"}],\n        \"datePublished\": \"2022-12-01\",\n      }",{"title":1401,"description":1402,"authors":1407,"heroImage":1403,"date":1409,"body":1410,"category":14,"tags":1411},[1408],"Will Leidheiser","2022-12-01","\n\nEarlier this year, our research team set out to learn how users search for GitLab content and to better understand their experience with our [global search](https://docs.gitlab.com/ee/user/search/) and [advanced search](https://docs.gitlab.com/ee/user/search/advanced_search.html) tools. We spoke with 12 GitLab users individually over the course of a four-week span to get their [feedback on our search capabilities](https://gitlab.com/groups/gitlab-org/-/epics/8193). \n\n![Getting feedback from GitLab users](https://about.gitlab.com/images/blogimages/2022-11-21-lets-all-search/Talking_to_GitLab_users.png){: .shadow.medium.center}\nA researcher talking with GitLab users to gather their feedback.\n{: .note.text-center}\n\n## Research insights\n\nOur research identified that the discoverability of our search could be better. Some users had never tried out our search capabilities because they did not know we had a search bar inside of GitLab. The search bar [did not visually stand out](https://gitlab.com/groups/gitlab-org/-/epics/8275) to some GitLab users, so this led them to try other means (e.g., using their web browser URL history or using another external application) to find content. In addition, we learned that even long-time users of the GitLab search bar were [unaware of the kinds of content it could find](https://gitlab.com/groups/gitlab-org/-/epics/8274). As we encouraged users to try out the search tools for our study, they would uncover new information either through exposure or by reading our documentation.\n\nOur research helped the Global Search Product team at GitLab with future roadmap planning. Now, we need the support of our community to make iterative improvements to GitLab search tools. We have identified **two** actionable insight issues that you can contribute to directly to improve the search experience for all GitLab users. \n\n## Community contribution issues\n\n- In order to make the search bar stand out, we're proposing a change to [improve the contrast of the search bar](https://gitlab.com/gitlab-org/gitlab/-/issues/330925) in the GitLab navigation header. This change would greatly support the accessibility of our site and would assist users when looking for a way to search for content.\n\n![Update to improve the contrast of our search bar](https://about.gitlab.com/images/blogimages/2022-11-21-lets-all-search/Focus.png){: .shadow.medium.center}\nA visual mock-up of improved contrast for the GitLab search bar.\n{: .note.text-center} \n\n- Improve the search experience by [providing hints](https://gitlab.com/gitlab-org/gitlab/-/issues/364402) about the kinds of content that the GitLab search bar can find. This change would prompt users with different ideas of what they can do with the search bar, so they can learn about our functionality without having to read through documentation.\n\n![Hints in the search bar](https://about.gitlab.com/images/blogimages/2022-11-21-lets-all-search/Placeholder_Options.png){: .shadow.medium.center}\nSome examples of hints that would be shown in the GitLab search bar.\n{: .note.text-center}\n\n## Let's contribute\n\nWondering where to start? Check out [this blog post](/blog/first-time-open-source-contributor-5-things-to-get-you-started) and [our development guide](/community/contribute/development/) and become an all-star contributor!\n\nNeed guidance or help? Feel free to leave a comment directly on one of the issues linked above, or find support in the \"get help\" section [in our contributing guide](/community/contribute/#getting-help).\n\n**Let's all contribute to GitLab's search!**\n",[865,268,675,1412,1413],"research","UX",{"slug":1415,"featured":6,"template":679},"lets-all-search","content:en-us:blog:lets-all-search.yml","Lets All Search","en-us/blog/lets-all-search.yml","en-us/blog/lets-all-search",{"_path":1421,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1422,"content":1428,"config":1435,"_id":1437,"_type":16,"title":1438,"_source":17,"_file":1439,"_stem":1440,"_extension":20},"/en-us/blog/how-to-start-a-great-oss-project",{"title":1423,"description":1424,"ogTitle":1423,"ogDescription":1424,"noIndex":6,"ogImage":1425,"ogUrl":1426,"ogSiteName":713,"ogType":714,"canonicalUrls":1426,"schema":1427},"How to start a great OSS project","In a modern DevOps world it's never been more critical to embrace open source. Here's everything you need to know to get started.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679362/Blog/Hero%20Images/contribute-open-source-jobs.jpg","https://about.gitlab.com/blog/how-to-start-a-great-oss-project","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to start a great OSS project\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mike Vanbuskirk\"}],\n        \"datePublished\": \"2022-10-18\",\n      }",{"title":1423,"description":1424,"authors":1429,"heroImage":1425,"date":1431,"body":1432,"category":14,"tags":1433},[1430],"Mike Vanbuskirk","2022-10-18","\nIf you spend any time coding, you've probably considered starting an OSS project at some point. Of course, the natural temptation is to immediately sit down and start writing code. That's a great approach that many projects have started from, but what about when it's time to let others contribute?\n\nAn OSS project is as much about community as it is code, and the key to building a good project is providing an inviting, productive place for that community to work and create. How can new contributors be onboarded smoothly? What kind of maintenance and automation will allow the project to scale beyond the scope of its original creator's time and resources? This article hopes to answer a few of these questions and provide first-time project maintainers with a solid foundation for launching a great OSS project.\n\n## Create a great README.md\n\nA README file is the \"entry point\" to an OSS project. Most distributed version control software hosting platforms like GitLab make the README file the first thing a visitor sees when viewing the repo. A good README manages to convey important information about a project while focusing on ease of navigation and reading and grabs the attention of potential contributors and users.\n\nTo start, maintainers should familiarize themselves with [Markdown](https://www.markdownguide.org), the markup language used for most OSS project documentation files like README. Markdown is a simple, elegant tool for crafting content and it's helpful to be aware of its features and capabilities.\n\nFor the README file itself, there are some things maintainers can include that will help drive productive participation and engagement.\n\n### Overview of the project\n\nA great way to draw attention to your project is to lead with a UI or CLI screenshot of the software. Even better: record some basic usage and convert it to a GIF using an OSS (of course!) tool like [Terminalizer](https://github.com/faressoft/terminalizer). The overview should also include the \"why\" of the project; it should be clear what problem or problems the project solves, and what drove the maintainer to create the project.\n\n### How to install and use it\n\nOSS project users can often become OSS project contributors; a well-run and well-documented project goes a long way towards bringing more contributors into the fold. Users should be presented with clear, concise, and most importantly correct instructions for installing and using the software contained in the project. Potential users and contributors are likely to be put off by confusing, complex, or non-functional installation instructions.\n\n### Links to documentation\n\nNot all project documentation does or even should fit inside the README file. Your project likely depends on one or more programming languages, as well as the many development tools, libraries, and modules in the language ecosystem. The README should serve as a project portal; linking to third-party documentation as needed, rather than as a comprehensive collection of all relevant documentation in one place.\n\n### Links to Code of Conduct\n\nThe global OSS project community is made up of a great many individuals, representing a rich, diverse spectrum of backgrounds and identities. With that in mind, an OSS project needs to provide a welcoming, inclusive Code of Conduct with firm and clear rules around expected behavior and decorum. One option is [Contributor Covenant](https://www.contributor-covenant.org/). A shared understanding of what defines good conduct is a pillar of a good community.\n\n### Links and instructions for reporting bugs or requesting features\n\nIf OSS project users become contributors, a great way to foster this transition is to make it easy to report bugs or request features. Ideally, this is where your README file links to your CONTRIBUTING.md file as well.\n\nA great example of an OSS project with an awesome README is [Leapp](https://github.com/Noovolari/leapp#readme); here’s another [example on GitLab](https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/README.md). This [Hacker News discussion](https://news.ycombinator.com/item?id=30106264) further demonstrates the power of the OSS project community in helping drive better engagement.\n\n## Creating a great CONTRIBUTING.md is important too\n\nThe CONTRIBUTING.md file represents another very important piece of documentation in an OSS project. Ideally, a CONTRIBUTING file should contain clear instructions for how individuals can get started contributing to your project. It's also important to be cognizant of first-time contributors to your project versus first-time contributors to OSS. For first-time OSS participants, it can be helpful to include links [like this](https://opensource.guide/how-to-contribute/).\n\nThe focus should be on technical detail; clear, concise instructions for how to clone, build, test, and commit are just some of what should be included. An adequate amount of detail and context is important, especially around what pre-requisite knowledge is expected and where it can be gained. The goal is to provide a deterministic path for contributors, with the end-state being a well-formed Merge Request. The [GitLab document](https://about.gitlab.com/community/contribute/) provides an excellent example.\n\nThe documentation for contributing should include:\n\n### An introductory message\n\nThis should be a warm and welcoming message that encourages individuals to participate, but also gives them the right foundation and context for creating successful and helpful commits.\n\n### How to set up a development environment\n\nDevelopment environments can be tricky to get right. Contributors may be working from a variety of different operating systems, IDEs, and hardware. Focus on making your project as environment agnostic as possible. Containerization tools like [Docker](https://www.docker.com) can help by isolating dependencies within the boundaries of a container environment. Ideally, as the project grows, you can take advantage of CI/CD automation to standardize things like linting and testing in a controlled environment or provide a one-click deployment option via something like [GitPod](https://www.gitpod.io).\n\n### How to run tests\n\nEarly in the project lifecycle, testing will probably be a minimal, non-comprehensive affair. Contributors will need to have clear guidance on setting up local development and testing to ensure their commits don't break existing functionality. Tests are another aspect of contributions that benefit heavily from automation.\n\n### Links to resources, including a style guide, the primary discussion medium, etc...\n\nContributors will almost always need to refer to additional resources to help them complete their work. The Contributing doc is a great place to link helpful and relevant documentation, including style guides, as well as third-party information. You should also highlight where the primary discussion medium for the project is hosted, which can be something like Slack, Discord, or within the repository itself.\n\n### Specific instructions on reporting bugs, and submitting changes/features\n\nBe specific and explicit with instructions for bugs, changes, and features. Providing this up-front reduces the amount of time that might be spent requesting basic formatting changes or additional information that's typically always needed on these topics.\n\n### Less experienced contributors? Suggest first-time issues\n\nContributing to OSS can be very intimidating for first-time contributors. It can be extremely helpful not just for your project, but for the entire OSS ecosystem to label issues that are ideal for first-time contributions. GitLab uses the [quick win](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=created_date&state=opened&label_name%5B%5D=quick%20win&first_page_size=20) label to highlight such issues.\n\nSome criteria that make for good first issues:\n- User-facing documentation updates\n- Adding unit tests\n- Well-scoped bug fixes, with an obvious end-state or success metric\n- Writing good code comments. Python docstrings are great for defining class and method behavior and are read by a variety of tools.\n\n## Choose a good license\n\nAn often overlooked, but no less important, part of starting an OSS project is choosing a good license. The sometimes verbose legal language of OSS licenses, as well as the scare stories of them being applied inappropriately, can be intimidating to first-time contributors.\n\nFortunately, tools like [Choose a license](https://choosealicense.com/) are available, allowing maintainers to make an informed choice about which license model is the best fit for the project.\n\nThe MIT and Apache licenses are common choices for OSS projects, but each project and maintainer are unique. Something else to consider is that a lot of OSS contributors often work professionally as software engineers, and may be subject to rules that prohibit or limit OSS contributions based on intellectual property concerns.\n\n## Use templates to make OSS maintenance easier\n\nEarly in the life of your OSS project, there are likely to only be a few contributors. The inflow of pull requests, issues and feature work will generally be pretty manageable at this stage. The need for automation and well-defined processes won't be immediately obvious, but once the project scales it's very easy to feel overwhelmed without some structure in place.\n\nTemplates are a great way to help establish some formal processes for dealing with common workflows in OSS projects. For most version control platforms, templates are Markdown documents that allow maintainers to pre-define the format and structure of things like issues, pull requests, and merge requests. There are some good examples of [issue templates here](https://gitlab.com/gitlab-org/gitlab/-/tree/master/.gitlab/issue_templates), as well as [templates for merge requests](https://gitlab.com/gitlab-org/gitlab/-/tree/master/.gitlab/merge_request_templates).\n\nGiving contributors a clear picture of the required information up front saves a lot of time and headache, and avoids the dance of maintainers having to frequently ask follow-up questions on issues to get a clear picture of the actual technical problem at hand. Once your project hits a critical mass of participation, it's very important to have a good structure of templates in place to allow you, and eventually other maintainers to leverage their time.\n\nAnother easy win for ease of maintenance is committing a well-formed gitignore file that's relevant to the type of project and language choice. The [SCM Git docs](https://git-scm.com/docs/gitignore) provide great documentation.\n\n## Automate your OSS project\n\nLeveraging maintainer resources and time is the key to successfully growing an OSS project. Beyond templates, some platforms allow maintainers to automate significant portions of the building and deployment of their projects.\n\nOne piece of automation that should be familiar to anyone with experience in a DevOps environment is Continuous Integration/Continuous Delivery(CI/CD) pipelines. CI/CD tools enable engineers to define a repeatable workflow that can lint, analyze, test, and deploy code while providing fast feedback on the outcome of each step. For example: a project using Python could integrate [pyflakes](https://gitlab.com/dnsmichi/api-playground/-/blob/main/.gitlab-ci.yml) into its CI workflow, ensuring all contributions are tested with a common standard for linting and syntax. Even [Markdown code can be tested](https://gitlab.com/gitlab-de/playground/markdown-lint-challenge/-/blob/main/.gitlab-ci.yml) this way! If maintainers want to take this pattern even further, a tool like [MKDocs can be integrated into a CI/CD workflow](https://gitlab.com/dnsmichi/opsindev.news/-/blob/main/.gitlab-ci.yml) as well to automatically generate documentation for the project. For busy maintainers, automating the typically tedious process of writing and updating documentation is a huge win.\n\nWith automation deployed, status badges can be a great way to provide contributors with a holistic view of the state of things like test coverage, build status, CI/CD health, and the current release version. The status badges on [this project](https://gitlab.com/gitlab-de/use-cases/iac-tf-vuln-module) provide both users and contributors with an at-a-glance understanding of pipeline health, and the most current release version of the module.\n\nFor anyone thinking about starting a project or already maintaining an open source project, the [GitLab for Open Source](https://about.gitlab.com/solutions/open-source/) program provides maintainers access to Ultimate features for free, which includes many valuable Security features as well as additional CI minutes.\n\n## Great OSS projects aren't just code\n\nCode is of central importance to open source software. However, an OSS project is more than just code. It's a community of diverse individuals participating in a shared goal. To help achieve that goal, it's crucial to provide a well-maintained space for that community to participate.\n\nSaying thanks for every contribution, welcoming everyone, and encouraging them to stay with feedback can also help make the project an inviting space. Along the way, you'll find new maintainers, and friends as well.\n\n_GitLab developer evangelist Michael Friedrich made significant contributions to this post._\n",[1434,675,865],"DevOps",{"slug":1436,"featured":6,"template":679},"how-to-start-a-great-oss-project","content:en-us:blog:how-to-start-a-great-oss-project.yml","How To Start A Great Oss Project","en-us/blog/how-to-start-a-great-oss-project.yml","en-us/blog/how-to-start-a-great-oss-project",{"_path":1442,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1443,"content":1449,"config":1456,"_id":1458,"_type":16,"title":1459,"_source":17,"_file":1460,"_stem":1461,"_extension":20},"/en-us/blog/accelerate-cloud-adoption-with-gitlabs-open-source-partnership-with-google-cloud",{"title":1444,"description":1445,"ogTitle":1444,"ogDescription":1445,"noIndex":6,"ogImage":1446,"ogUrl":1447,"ogSiteName":713,"ogType":714,"canonicalUrls":1447,"schema":1448},"GitLab & Google Cloud partnership accelerates cloud adoption","Learn how Cloud Seed came about and how it will help speed app modernization.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665811/Blog/Hero%20Images/daytime-clouds.jpg","https://about.gitlab.com/blog/accelerate-cloud-adoption-with-gitlabs-open-source-partnership-with-google-cloud","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Accelerate cloud adoption with GitLab's open source partnership with Google Cloud\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sri Rangan\"}],\n        \"datePublished\": \"2022-10-11\",\n      }",{"title":1450,"description":1445,"authors":1451,"heroImage":1446,"date":1453,"body":1454,"category":14,"tags":1455},"Accelerate cloud adoption with GitLab's open source partnership with Google Cloud",[1452],"Sri Rangan","2022-10-11","\nSince December 2021, GitLab Incubation has partnered with Google Cloud to develop\nsolutions that will help customers address one of their biggest business requirements: accelerating cloud adoption.\n\nWe are thrilled to announce the release of Cloud Seed at Google Cloud Next 2022,\nand we are even more excited to follow up with our community. Cloud Seed is an open\nsource partnership between GitLab and Google Cloud to accelerate cloud adoption and\napp modernization.\n\nThe origins of Cloud Seed date back to late 2020 when I worked closely with GitLab co-founder and CEO [Sid Sijbrandij]( /company/team/#sytses) on an experiment called “5 Minute Production\". Our focus was to improve developer experience while consuming cloud services and enabling DevSecOps best practices by default.\n\nFor this, GitLab needed to collaborate with the hyper clouds, and Google Cloud emerged as our natural choice. In this post I’d like to shed light on our collaboration, the results our partnership has achieved, and the positive business outcomes our customers will realize.\n\n## Refining the use case\n\nFirst, we reached out and polled our customers to try and understand their cloud adoption use cases. \n\nWe found the enterprise market segment focused on migrating existing systems to the cloud to achieve their digital transformation targets, while the SMB and startup segment focused on embracing the cloud for greenfield initiatives.\n\n## Cloud Run and Cloud SQL\n\nWhile motivations for enterprise and SMB segments varied, the underlying use case —– deploying web applications to the cloud —– remained the same. Thus, we selected two of the more popular Google Cloud managed services that web applications make use of: [Cloud Run](https://cloud.google.com/run) and [Cloud SQL](https://cloud.google.com/sql).\n\nCloud Run makes it possible to build and deploy scalable containerized apps written in any language (including Go, Python, Java, Node.js, .NET, and Ruby) on a fully managed platform. Meanwhile, Cloud SQL is a fully managed relational database service for MySQL, PostgreSQL, and SQL Server with rich extension collections, configuration flags, and developer ecosystems.\n\n## Open source collaboration\n\nGitLab comes with a rich tradition of [open source](/solutions/open-source/). Our partners at Google Cloud understood and complemented that remarkably, which made for a close collaboration between our two teams. We agreed quite early in the process that all capabilities built within Cloud Seed will be open source and, therefore, available for all GitLab users regardless of their market segment, license tier, or any other consideration.\n\n## Preview environments on Cloud Run\n\nThe Cloud Seed private beta was made available to trusted testers in May 2022, and based on the successful beta program, Preview Environments with GitLab and Cloud Run emerged among the most popular use cases.\n\n**Take a look at Preview Environments on GitLab with Cloud Seed:**\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/zDMGCyAgCPY\" title=\"Preview Environments on GitLab with Cloud Seed\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\nMost Git-based development workflows make use of temporary feature branches. In larger teams and organizations, it is required that feature branches are made available for review and testing.\n\nWith Cloud Seed, a Cloud Run deployment pipeline can be generated in less than two minutes that deploys all feature branches to Cloud Run. Given Cloud Run’s free tier, this can be a cost-effective method to deploy and manage preview environments.\n\n## Relational databases with Cloud SQL\n\nAnother common use case, typically in the app migration scenario, is to set up and migrate relational databases in the cloud. Our beta-test users voted for Cloud SQL as their most popular data storage option among a myriad of Google Cloud services.\n\nWith Cloud Seed, traditional relational databases such as Postgres, MySQL, and SQL Server can be spun up from the GitLab web UI. Similar to the Cloud Run workflow described above, these database instances can be made branch, tag, and environment specific. Alternatively, a GitLab project can be spun up for database operations, where Cloud Seed creates a suitable Cloud SQL instance while the Git repository serves as the host for configuration and migration operations.\n\n## Looking ahead\n\nOur purpose is clear: We learn from our users and customers about their use cases and needs, and we build capabilities to support them through their cloud adoption journeys. We are thrilled to announce the release of Cloud Seed at [Google Cloud Next '22](https://cloud.withgoogle.com/next), and we are even more excited to follow up with our community. Connect with us @OpenCloudSeed on Twitter and try out Cloud Seed today at GitLab.com.\n",[283,675,1391],{"slug":1457,"featured":6,"template":679},"accelerate-cloud-adoption-with-gitlabs-open-source-partnership-with-google-cloud","content:en-us:blog:accelerate-cloud-adoption-with-gitlabs-open-source-partnership-with-google-cloud.yml","Accelerate Cloud Adoption With Gitlabs Open Source Partnership With Google Cloud","en-us/blog/accelerate-cloud-adoption-with-gitlabs-open-source-partnership-with-google-cloud.yml","en-us/blog/accelerate-cloud-adoption-with-gitlabs-open-source-partnership-with-google-cloud",{"_path":1463,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1464,"content":1470,"config":1476,"_id":1478,"_type":16,"title":1479,"_source":17,"_file":1480,"_stem":1481,"_extension":20},"/en-us/blog/arm-open-source-makes-a-seamless-migration-to-gitlab",{"title":1465,"description":1466,"ogTitle":1465,"ogDescription":1466,"noIndex":6,"ogImage":1467,"ogUrl":1468,"ogSiteName":713,"ogType":714,"canonicalUrls":1468,"schema":1469},"Arm Open Source makes a seamless migration to GitLab","DevOps platform switch reaps cost savings of up to 20%.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670681/Blog/Hero%20Images/a-creative-agencys-gitlab-wishlist.jpg","https://about.gitlab.com/blog/arm-open-source-makes-a-seamless-migration-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Arm Open Source makes a seamless migration to GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2022-10-03\",\n      }",{"title":1465,"description":1466,"authors":1471,"heroImage":1467,"date":1472,"body":1473,"category":14,"tags":1474},[818],"2022-10-03","[Arm](https://www.arm.com/) wanted to modernize its infrastructure to span across internal (private) and open-source collaborative repositories, and, in the process, consolidate some of its key projects on the same underlying infrastructure. Arm selected GitLab as its new platform. \n\nArm builds software that acts as enablement pieces that can be integrated with other software on its architecture. These are foundational pieces of software that often underpin commercial software offerings, from operating systems to middleware applications. Over 99% of mobile devices have Arm-based processors and the software from the Open Source Engineering team powers computers from sensors up to the cloud.\n\n“The magic really happens when you join enablement pieces with other bits of software from other communities and other projects,” explains Andrew Wafaa, distinguished engineer and senior director of software communities at Arm.\n\nThe goal is to give software developers the best of the Arm architecture, he adds. The enablement pieces “leverage a lot of the bells and whistles from the Arm architecture and that allows people to take those and integrate them with other stacks.”\n\n## GitLab open source lets Arm use its own tooling\n\nArm had a mix of stand-alone Git servers internally and public web-based Git service and wanted to consolidate to a single solution for the company’s larger projects. However,  most of the new core infrastructure that Arm is deploying is on native Arm-based hardware, and the Git service is a proprietary solution. \n\nArm would have to work with its previous platform provider to ensure correctness. According to Wafaa, “We'd have to do reviews, and the patch review process is challenging because it's all private and proprietary code, which was a big factor for us in choosing GitLab.” In addition, Arm had concerns about the code ownership of their OSS projects hosted on the external service. Therefore, Arm determined an open source solution like GitLab would be the best option to maximize choice, be cost effective, and minimize vendor lock-in. Moving to GitLab’s self-hosted platform supported effective collaboration and enabled Arm’s software to be hosted on Arm technology.  \n\nAnother large bonus is that because [GitLab is open source](/solutions/open-source/), Arm can use its own tools to support its open source ecosystem. “Using an open source product made sense at the end of the day,’’ Wafaa says. “Another big factor was that GitLab is an enterprise-grade product that provides very similar workflows to what Arm was already using. It was very easy to move from our previous platform to GitLab; the terminology is very similar, as well as the look and feel.”\n\nFurther, GitLab is a self-hosted enterprise product, and it was important to Arm to have good customer support in the event that something goes wrong.\n\nArm hosts about 200 external open source projects, so of course cost was also a consideration, Wafaa says. “When we're looking at future growth plans there needs to be a reasonable amount of savings and GitLab made it appealing cost-wise.” \n\n## Maintaining control every step along the way\n\nArm is in the process of moving internal workloads to the Arm architecture. Although GitLab didn't initially support Arm, the company “was quite happy to work with us and our engineering teams to ensure that it did support Arm” by creating integrations with its infrastructure, Wafaa says.\n\n“The fact that we could have that fine-grained access control was a huge benefit to us and being able to replicate it on AWS Graviton EC2 instances globally gave us that full redundancy and disaster recovery requirements to meet our IT's needs,\" Wafaa says.\n\nBecause Arm is an IP company, security is paramount. Wafaa says they opted for a gradual migration before scaling out. “For us to deploy, we have to go through a number of approvals with various security teams internally, and that went fairly smoothly. It just worked.”\n\nAfter a “mini deployment,” everything is working seamlessly, he says. Now, anyone can run GitLab on Arm from an enterprise perspective.\n\nThen Wafaa and others held their collective breath awaiting feedback. “Our engineering teams can be quite demanding of the infrastructure provided. They are very, very particular.”\n\nSince the teams have been migrated onto GitLab, “they have been full of praise,” which was a pleasant surprise for Dean Arnold, Arm’s DevOps lead for the open source engineering org, Wafaa says, “because he's not used to getting praise from them. It stood up and worked really well for them.”\n\nMigration to GitLab is ongoing with about 90 percent of it complete. “Certain projects are taking longer because they have complex tooling and the integration pieces are still being ironed out,” Wafaa says.\n\nWith the adoption of GitLab, Arm’s Open Source Engineering teams can now offer full end-to-end native development, and can confidently say “software development by Arm, for Arm, on Arm”. GitLab is not just a DevOps tool, it is a tool that helps companies like Arm offer a complete developer experience.\n\n## Solid metrics for Arm\n\nWith GitLab, Arm has found a number of benefits:\n- Ease of CI/CD set up and integration\n- Cost savings of between 15% and 20%\n- Time savings of an average two to four people a month on admin work\n- Tool simplification\n- The ability to share and collaborate on pipelines/code\n- Quick setup of new projects and onboarding of teams\n\nPreviously, there were multiple individual components that would have to be then stitched together, Wafaa says. “GitLab actually offers us more features and more functionality than we're necessarily used to, and that’s great.”\n\nThat’s especially useful because other contributors want to use pretty much every feature possible for their projects, both for corporate and personal use. For example, one engineer uses GitLab in a personal capacity and wants full CI capabilities.\n\nBoth Wafaa and Arnold are confident that once the migration is completed, there will be significant time savings and projects will be onboarded quickly.\n\n## Deployment in the clouds\n\nOn tap now is working through how to share parts of the pipelines so that teams can adopt things quicker, Arnold says. By the time the migration is completed, Arm will have most of what contributors need, he says.\n\nRight now, Arm is using AWS EC2 instances. Looking ahead, Arnold envisions that [deployment between cloud providers](/topics/multicloud/) will become more seamless without having to change underlying code.\n\nSays Wafaa, “Once we've got people fully onto GitLab, then we'll look at how we can expand it and perhaps provide a more robust level of redundancy across geographies via the containerized route. This is an area of ongoing collaboration between Arm and GitLab, and we hope to be able to deploy soon.”",[1475,675,1434],"customers",{"slug":1477,"featured":6,"template":679},"arm-open-source-makes-a-seamless-migration-to-gitlab","content:en-us:blog:arm-open-source-makes-a-seamless-migration-to-gitlab.yml","Arm Open Source Makes A Seamless Migration To Gitlab","en-us/blog/arm-open-source-makes-a-seamless-migration-to-gitlab.yml","en-us/blog/arm-open-source-makes-a-seamless-migration-to-gitlab",{"_path":1483,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1484,"content":1490,"config":1502,"_id":1504,"_type":16,"title":1505,"_source":17,"_file":1506,"_stem":1507,"_extension":20},"/en-us/blog/a-benchmarking-framework-for-sast",{"title":1485,"description":1486,"ogTitle":1485,"ogDescription":1486,"noIndex":6,"ogImage":1487,"ogUrl":1488,"ogSiteName":713,"ogType":714,"canonicalUrls":1488,"schema":1489},"A Google Summer of Code project: creating a benchmarking framework for SAST","Our 2022 Google Summer of Code project helped to create a benchmarking framework for SAST.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677267/Blog/Hero%20Images/benchmarking.png","https://about.gitlab.com/blog/a-benchmarking-framework-for-sast","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A Google Summer of Code project: creating a benchmarking framework for SAST\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Henriksen\"},{\"@type\":\"Person\",\"name\":\"Martynas Krupskis\"},{\"@type\":\"Person\",\"name\":\"Mark Art\"},{\"@type\":\"Person\",\"name\":\"Dinesh Bolkensteyn\"},{\"@type\":\"Person\",\"name\":\"Isaac Dawson\"},{\"@type\":\"Person\",\"name\":\"Julian Thome\"}],\n        \"datePublished\": \"2022-09-27\",\n      }",{"title":1485,"description":1486,"authors":1491,"heroImage":1487,"date":1498,"body":1499,"category":14,"tags":1500},[1492,1493,1494,1495,1496,1497],"Michael Henriksen","Martynas Krupskis","Mark Art","Dinesh Bolkensteyn","Isaac Dawson","Julian Thome","2022-09-27","In summer 2022, the [Vulnerability Research team at GitLab](/handbook/engineering/development/sec/secure/vulnerability-research/) \nlaunched the [Google Summer of Code (GSoC)](https://summerofcode.withgoogle.com/) project: \n[A benchmarking framework for SAST](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/gsoc-2022/-/issues/1).\n\nThe goal of the project was to create a benchmarking framework, which would assess the\nimpact and quality of a security analyzer or configuration change before it reaches the production environment.\n\n## Preliminaries \n\n### GitLab SAST\n\nAs a complete DevOps Platform, GitLab has a variety of integrated [static analysis (SAST) tools](/direction/secure/static-analysis/sast/) \nfor different languages and frameworks. These tools help developers find\nvulnerabilities as early as possible in the software development lifecycle.\nThese tools are constantly being updated, either by upgrading the underlying\nsecurity analyzers or by applying configuration changes.\n\nSince all the integrated SAST tools are very different in terms of\nimplementation, and depend on different tech stacks, they are all\nwrapped in Docker images. The wrappers translate tool-native vulnerability\nreports to a [generic, common report format](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format) which is\nmade available by means of the `gl-sast-report.json` artifact. This generic\nreport is GitLab's common interface between analyzers and the GitLab Rails\nbackend.\n\nBenchmarking is important to assess the efficacy of analyzers and helps to make\ndata-driven decisions. For example, benchmarking is useful for QA testing\n(spotting regressions), for data-driven decision making, and for research by\nassessing the progression of the GitLab security feature performance over time.\n\n### Google Summer Of Code (GSoC)\n\n[Google Summer of Code (GSoC)](https://summerofcode.withgoogle.com/) \nis a 10-week program that enlists contributors to work on open source projects\nin collaboration with open source organizations. For GSoC 2022, GitLab offered\nfour projects to GSoC contributors. The contributors completed each of the\nprojects with the guidance from GitLab team members who mentored them and\nprovided regular feedback and assistance when needed.\n\n### Terms & Notation\n\nIn this blog post, we use the terms/acronyms below to classify findings reported by security analyzers.\n\n| Acronym   | Meaning        | Description                                                        |\n|-------|----------------|--------------------------------------------------------------------|\n| _TP_  | True Positive  | Analyzer correctly identifies a vulnerability.                     |\n| _FP_  | False Positive | Analyzer misidentifies a vulnerability or reported a vulnerability where none exist. |\n| _TN_  | True Negative  | Analyzer correctly ignores a potential false positive.             |\n| _FN_  | False Negative | Analyzer does not report a known vulnerability.                    |\n\nFor the figures in the blog post we use the following notation: processes are\ndepicted as rounded boxes, whereas artifacts (e.g., files) are depicted as\nboxes; arrows denote an input/output (IO) relationship between the connected nodes.\n\n``` mermaid\nflowchart TB;\nsubgraph legend[ Legend ]\n   proc(Process);\n   art[Artifact];\n   proc -->|IO relation|art;\nend\n``` \n\n## Motivation\n\nThe authors of the paper [How to Build a Benchmark](https://dl.acm.org/doi/10.1145/2668930.2688819) distilled the desirable characteristics of a benchmark below:\n> 1. Relevance: How closely the benchmark behavior correlates to behaviors that are of interest to consumers of the results.\n> 2. Reproducibility: The ability to consistently produce similar results when the benchmark is run with the same test configuration.\n> 3. Fairness: Allowing different test configurations to compete on their merits without artificial limitations.\n> 4. Verifiability: Providing confidence that a benchmark result is accurate.\n> 5. Usability: Avoiding roadblocks for users to run the benchmark in their test environments.\n\nThere currently is no standard nor de facto language-agnostic SAST benchmark\nsatisfying all the criteria mentioned above. Many benchmark suites focus on\nspecific languages, are shipped with incomplete or missing ground-truths, or\nare based on outdated technologies and/or frameworks. A ground-truth or\nbaseline is the set of findings a SAST tool is expected to detect.\n\nThe main objective of the GSoC project was to close this gap and start to\ncreate a benchmarking framework that addresses all the desirable charateristics\nmentioned above in the following manner:\n\n1. Relevance: Include realistic applications (in terms of size, framework usage\n   and customer demand).\n2. Reproducibility: Automate the whole benchmarking process in CI.\n3. Fairness: Make it easy to integrate new SAST tools by just tweaking the CI\n   configuration and use the [GitLab security report schema](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format) as a common standard.\n4. Verifiability: Assemble baseline that includes all the relevant\n   vulnerabilities and make it publicly available. The baseline is the north star\n   that defines what vulnerabilities are actually included in a test application. \n5. Usability: Benchmark users can just integrate the benchmark as a downstream\n   pipeline to their CI configuration.\n\n## A benchmarking framework for SAST\n\nThe benchmarking framework compares the efficacy of an analyzer against a known\nbaseline. This is very useful for monitoring the efficacy of the analyzer that\nparticipates in the benchmarking. The baseline is the gold standard that serves\nas a compass to guide analyzer improvements.\n\n### Usage\n\nFor using the framework, the following requirements have to be met:\n1. The analyzer has to be dockerized.\n1. The analyzer has to produce a vulnerability report that adheres to the\n   [GitLab security report schema](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format)\n   format, which serves as our generic intermediate representation to compare\n   analyzer efficacy. \n1. The baseline expectations have to be provided as \n   [GitLab security report schema](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format)\n   so that we can compare the analyzer output against it. \n\nThe framework is designed in such a way that it can be easily integrated into\nthe CI configuration of existing GitLab projects by means of a [downstream pipeline](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html).\nThere are many possible ways in which a downstream pipeline can be triggered:\nsource code changes applied to an analyzer, configuration changes\napplied to an analyzer, or scheduled pipeline invocation. By using the pipeline,\nwe can run the benchmarking frameworks continuously and instantaneously on the GitLab\nprojects that host the source code of the integrated analyzers whenever code or\nconfiguration changes are applied. \n\n### Architecture \n\nThe figure below depicts the benchmarking framework when comparing an analyzer\nagainst a baseline.\n\nWe assume that we have a baseline configuration available; a baseline consists\nof an application that is an actual test application that includes\nvulnerabilities. These vulnerabilities are documented in an expectation file\nthat adheres to the [security report schema](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format).\n\nNote that we use the terms baseline and expectation interchangeably. As\nmentioned earlier, the benchmarking framework is essentially a GitLab pipeline\nthat can be triggered downstream. The configured analyzer then takes the\nbaseline app as input and generates a `gl-sast-report.json` file. The heart of the\nbenchmarking framework is the `compare` step, which compares the baseline\nagainst the report generated by the analyzer, both of which adhere to the\n[security report schema](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format).\n\nThe compare step also computes the _TP_, _FN_ and _FP_ that have been reported by the\nanalyzer and computes different metrics based on this information. The compare\nstep is implemented in the\n[evaluator tool](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/evaluator). \n\n``` mermaid\nflowchart LR;\nsbx[gl-sast-report.json];\nbreport[Report];\nconfig[Configuration];\n\nconfig --> bf;\n\nsubgraph Baseline\n  bcollection[app];\n  baseline[expectation];\nend\n\nsubgraph bf [ Benchmarking Framework ]\n   orig(Analyzer);\n   compare(Compare);\n   orig --> sbx;\n   sbx --> compare;\nend\n\nbaseline --> compare;\ncompare --> breport\nbcollection --> orig\n```\n\nUsing the security report format as a common standard makes the benchmarking\nframework very versatile: the baseline could be provided by an automated\nprocess, by another analyzer, or manually, which happened to be the case in this\nGSoC project.\n\n### Scoring\n\nThe main functionality of the [evaluator tool](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/evaluator)\nis to compute the overlap/intersection, and difference between a baseline and\ngenerated report in order to uncover true positives, false positives, and false\nnegatives. \n\nThe relationship between _TP_, _FP_, _FN_, _TN_, baseline, and generated report can be\nseen in the table below; it includes three columns `analyzer`, `baseline` and\n`classification`. The column `analyzer` represents the findings included in the\nreport generated by the analyzer; column `baseline` represents the findings\nincluded in the baseline; column `classification` denotes the\nverdict/classification that the [evaluator tool](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/evaluator)\nattaches to the analyzer finding when performing the comparison. The `X` and\n`-` denote reported and non-reported findings, respectively.\n\n| analyzer | baseline | classification |\n| -------- | -------  | -------------  |\n| -        | -        | _TN_           |\n| -        | X        | _FN_           |\n| X        | -        | _FP_           |\n| X        | X        | _TP_           |\n\nThe `classification` column in the table above shows that a _TP_ is a\nvulnerability existing in both baseline and generated report; similarly, an\n_FP_ is a vulnerability detected by an analyzer without a corresponding\nbaseline entry, while an _FN_ is a vulnerability present in the baseline but\nnot detected by an analyzer. Note, that _TN_ is practically not relevant for\nour use-case since the analyzers we are looking at only report unsafe,\nvulnerable cases instead of safe, non-vulnerable cases. \n\nAt the moment, the `evaluator` tool computes the metrics below:\n- Precision: _P_ = _TP_ /( _TP_ + _FP_ )\n- Recall: _R_ = _TP_ / ( _TP_ + _FN_ )\n- F-Score: _F_ = 2 * ( _P_ * _R_ ) / ( _P_ + _R_ ) \n- Jaccard-Index: _J_ = _TP_ / ( _TP_ + _FP_ + _FN_ )\n\nA higher precision indicates that an analyzer is less noisy due to the low(er)\nnumber of _FPs_. Hence, a high precision leads to a reduction of auditing effort\nof irrelevant findings. A high recall represents an analyzer's detection\ncapacity. F-Score is a combined measure so that precision and recall can be\ncondensed to a single number. The Jaccard-Index is a single value to capture\nthe similarity between analyzer and baseline.\n\nThe [evaluator tool](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/evaluator)\nsupports the addition of custom metrics via a simple call-back mechanism; this\nenables us to add support more metrics in the future that help us to gain\nadditional or new insights with regards to the efficacy of our analyzers.\n\n### Framework Properties\n\nIn principle, the implemented benchmarking framework is language-agnostic: new\nanalyzers and baselines can be plugged-in as long as they adhere to the\n[security report schema](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format). \n\nEstablishing baselines is laborious since it requires (cross-)validation, \ntrying out attacks on the running baseline application and\ncode auditing.\n\nFor the GSoC project, we established baselines for the applications below\ncovering Java ([Spring](https://spring.io/)) and Python\n([Flask](https://flask.palletsprojects.com/)) as they are [ranking high in the most used languages and frameworks](https://survey.stackoverflow.co/2022/#technology-most-popular-technologies). \nFor a benchmark application to have practical utility, it is important that the\napplication itself is based on technology, including programming languages and\nframeworks, that are used in the industry.\n\nFor both of these applications, the baseline/expectations have been collected,\nverified and are publicly availabe: \n- [WebGoat](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/baselines/WebGoat/-/tree/baselines). \n  WebGoat is a deliberately insecure Web application used to teach security vulnerabilities.\n  We chose this as baseline application because it is often used as a benchmark\n  app in the Java world and it is based on [Spring](https://spring.io/) which is\n  one of the most popular frameworks in the Java world. \n- [vuln-flask-web-app](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/baselines/vuln-flask-web-app/-/tree/report) Like WebGoat, this application is deliberately insecure. `vuln-flask-web-app` covers both Python and [Flask](https://flask.palletsprojects.com/en/2.2.x/), one of the most popular web frameworks in the Python world.\n\n## Conclusion\n\nThis GSoC project was a first step towards building a FOSS benchmarking\nframework that helps the community to test their own tools and to build up a\nrelevant suite of baselines covering various languages and frameworks. With the\nhelp of the community, we will continue adding more baselines to the\nbenchmarking framework in the future to cover more languages and frameworks.\n\nIf you found the project interesting, you might want to check out the following repositories:\n\n- [evaluator](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/evaluator)\n- [WebGoat baseline](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/baselines/WebGoat/-/tree/baselines)\n- [Vulnerable Flask Web App baseline](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/baselines/vuln-flask-web-app/-/tree/report)\n- [Example of downstream pipeline triggering evaluator](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/evaluator-downstream)\n\nCover image by [Maxim Hopman](https://unsplash.com/@nampoh) on [Unsplash](https://unsplash.com/photos/fiXLQXAhCfk)\n{: .note}\n",[864,1501,675],"google",{"slug":1503,"featured":6,"template":679},"a-benchmarking-framework-for-sast","content:en-us:blog:a-benchmarking-framework-for-sast.yml","A Benchmarking Framework For Sast","en-us/blog/a-benchmarking-framework-for-sast.yml","en-us/blog/a-benchmarking-framework-for-sast",{"_path":1509,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1510,"content":1516,"config":1522,"_id":1524,"_type":16,"title":1525,"_source":17,"_file":1526,"_stem":1527,"_extension":20},"/en-us/blog/git-resources-for-visual-learners",{"title":1511,"description":1512,"ogTitle":1511,"ogDescription":1512,"noIndex":6,"ogImage":1513,"ogUrl":1514,"ogSiteName":713,"ogType":714,"canonicalUrls":1514,"schema":1515},"5 Git resources for visual learners","Learning Git is not commonplace in code instruction, yet it is essential for modern software development. These sites get you started.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668161/Blog/Hero%20Images/armycyberschool.jpg","https://about.gitlab.com/blog/git-resources-for-visual-learners","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 Git resources for visual learners\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"PJ Metz\"}],\n        \"datePublished\": \"2022-09-14\",\n      }",{"title":1511,"description":1512,"authors":1517,"heroImage":1513,"date":1519,"body":1520,"category":14,"tags":1521},[1518],"PJ Metz","2022-09-14","\n[Git](https://Git-scm.com/doc) is free and open source version control and has become the industry standard for keeping track of changes in software. A recent [survey](https://www.jetbrains.com/lp/devecosystem-2021/) by JetBrains states that 93% of developers surveyed use Git for source control.  Even though it’s used by almost every software developer, it’s still not ubiquitously taught as part of coding courses. Many people end up learning Git either on the job or on their own.\n\nWe’ve gathered a list of sites to learn Git, whether you’re brand-new to it or you need to fine-tune your skills. These five resources are largely focused on visual learning and use either video-based tools or an interactive website or game. \n\n\n**1. [Oh My Git](https://ohmyGit.org/)**\n\nOh My Git is a gamified way of learning Git commands that includes a visualization of what effect your actions have on the repository. It’s card-based for early beginners. Think of it like Hearthstone or Magic the Gathering, but better for learning. It can also be played by using the command line as well. Start playing today! \n\n**2. [Git for Computer Scientists](https://eagain.net/articles/git-for-computer-scientists/)**\n\nI love the abstract for this site: “Quick introduction to Git internals for people who are not scared by words like Directed Acyclic Graph.” This website has lots of helpful graphs for people who aren’t necessarily working explicitly in software, and is intended for a specific audience of computer scientists; be aware before heading in. \n\n**3. [Learn Git Branching](https://Github.com/pcottle/learnGitBranching#learnGitbranching)**\n\nSometimes, the complicated part of Git is understanding what is actually happening when you’re creating or working with multiple branches. This visualization tool helpfully creates a real-time display of changes to commit trees. \n\n**4. [Explain Git with D3](https://onlywei.github.io/explain-git-with-d3/)**\n\nThis is such a great resource and one that everyone should have bookmarked. This website lets you type commands in a CLI and immediately see graphs representing what you did on the right. It has an open playground mode where you can just do whatever you like as well as structured lessons for common Git commands. If you use Git but it just feels like magic, then this is a great website for deepening your understanding of what Git does. \n\n**5. [Git for ages 4 and up](https://youtu.be/1ffBJ4sVUb4?t=125)**\n\nThis is a fantastic video of Michael G. Schwern at Linux conf.au in 2013. Using children's toys, Michael gives us a great example of what exactly goes on in Git. It’s an entertaining video with important basics and concepts for anyone struggling to understand Git. \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/1ffBJ4sVUb4\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Did you know? \n\nGitLab offers free Ultimate tier licenses to qualifying educational institutions when used for learning, teaching, or research? Learn more [here](/solutions/education/).\n",[699,675,268],{"slug":1523,"featured":6,"template":679},"git-resources-for-visual-learners","content:en-us:blog:git-resources-for-visual-learners.yml","Git Resources For Visual Learners","en-us/blog/git-resources-for-visual-learners.yml","en-us/blog/git-resources-for-visual-learners",{"_path":1529,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1530,"content":1536,"config":1542,"_id":1544,"_type":16,"title":1545,"_source":17,"_file":1546,"_stem":1547,"_extension":20},"/en-us/blog/pursuing-faster-time-to-merge-for-wider-community-contributions",{"title":1531,"description":1532,"ogTitle":1531,"ogDescription":1532,"noIndex":6,"ogImage":1533,"ogUrl":1534,"ogSiteName":713,"ogType":714,"canonicalUrls":1534,"schema":1535},"Pursuing faster time-to-merge for wider community contributions","How introducing more explicit contribution stages lowered the time it takes to merge a community contribution.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663397/Blog/Hero%20Images/logoforblogpost.jpg","https://about.gitlab.com/blog/pursuing-faster-time-to-merge-for-wider-community-contributions","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Pursuing faster time-to-merge for wider community contributions\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nick Veenhof\"}],\n        \"datePublished\": \"2022-09-13\",\n      }",{"title":1531,"description":1532,"authors":1537,"heroImage":1533,"date":1538,"body":1539,"category":14,"tags":1540},[1115],"2022-09-13","\n\nOne of GitLab's core strategies is to [build on our open core\nstrength](/company/strategy/#2-build-on-our-open-core-strength). We believe that building a\nstrong community of contributors is key to the long-term success of GitLab. We believe in a [dual-flywheel\nstrategy](/company/strategy/#dual-flywheels) that focuses on both product contributions from\nwithin our GitLab engineering team and community contributions. \n\nOur goal is to grow to 1000 contributors per month. The saying is that \"All roads lead to Rome,\" but of course not all of those roads are the most efficient ways to get there. To succeed, contributing to GitLab must be a rewarding and incentivizing experience that\nmotivates contributors to come back. One of the strategic choices we made in the [contributor\nsuccess](https://about.gitlab.com/handbook/marketing/developer-relations/contributor-success/) team is the route of being as\nresponsive and clear as we can about the next steps, using processes and automation. \n\n## Problem statement\n\nSo where do we start? On average GitLab has over [550 open merge\nrequests](https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&state=opened&label_name[]=Community%20contribution).\nWe wanted to focus on the _ready enough_ problem. When is an MR ready for review? And when is an MR still in development? In\nboth cases collaboration is required, but having a formal handoff — meaning this contribution is ready for a review — helps in\nunderstanding who is blocked from moving forward. Before a merge request can find its way into GitLab, it needs to get a\nreview from at least one maintainer.\n\nHow do we know when to ask specific maintainers of our product areas to put their focus on reviewing these merge requests? When is a merge request _ready enough_ for a thorough review? What does _ready enough_ even mean?\n\nSome OSS communities use crowdsourced reviews for contributions to make sure the project maintainers don’t need to take on everything by themselves. For example, in the Drupal community there is the concept of [Reviewed and Tested by the Community](https://www.drupal.org/community/contributor-guide/task/triage-the-drupal-core-rtbc-queue). At GitLab we have MR coaches and community help to make sure everything is as ready as can be before involving the maintainers.\n\nThe GitLab bot and our MR coaches try to assist the wider community contributors on their way. We also had a ping-pong label that tried to signify if a community contributor had reacted and it was ‘ping ponged 🏓’ back to the GitLab team members. This pingpong label didn’t take the context into account. It was a great iterative and [boring solution](https://handbook.gitlab.com/handbook/values/#boring-solutions) to know who was up next (the author or the reviewer). But it had a lot of false-positives and caused confusion to both the maintainers and the community contributors.\n\nSo where do we go from here? How do we get a better grasp on this _ready enough_ problem? Let’s start by asking for help from our recommended reading list, [High-Output Management](/handbook/leadership/high-output-management/). Author Andrew S. Grove states: “A very important way to increase productivity is to arrange the work flow inside our black box so that it will be characterized by high output per activity, which is to say high-leverage activities.”\n\n## Introducing workflow labels\n\nFor a while, GitLab team members were using workflow labels to signify the state of a merge request. It wasn’t always used across all teams, but they were available. More specifically we’re looking at the following labels:\n\n- `workflow::ready for review`\n- `workflow::in dev`\n- `workflow::blocked`\n\nEach wider community contributor is now [able to change these labels themselves](https://docs.gitlab.com/ee/development/contributing/#contribution-flow). By using `@gitlab-bot ready`, it sets the state to `workflow::ready for review` and assigns a reviewer. The reviewer is able to set it back to `workflow::in dev` if there are still items to be addressed. Other wider community members can also leave comments or suggestions for improvement, and then [set the label](https://about.gitlab.com/handbook/engineering/quality/triage-operations/#reactive-label-command) back to `workflow::in dev`, or set other labels to help triage these merge requests.\n\n## What have we learned so far?\n\nWe started using this system over two months ago. We now know that around 20% of MRs on average are in a \"ready for review\"\nstate. Those contributors are blocked and waiting for an answer to either continue to improve the merge request or get\nit merged if there are no more comments left. We also noticed that some merge requests were not getting a lot of\nattention. We did an async retrospective and feedback session with the GitLab team members and the wider community in order to find an answer on how we can\n[improve the time it takes before a review is made](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/13718) for\ncontributions that were ready for a review. We’re still processing that feedback, but are looking to try some of these\nsuggestions, learn from them, and iterate. Even though GitLab cannot promise timely reviews, we can certainly try to\nbuild in mechanisms, and understand where we see limits, to navigate towards better processes. When we started out, we\nhad a median time of 17 days that an MR was in the ready for review state. Today that median time has been reduced to five days!\n\nThe median Open Community MR Age (OCMA) has also dropped from 139 days in April to 78 days in August. Maybe it is a\ncoincidence that we reached an all-time high of 126 contributors in August? Either way, all of the steps allowed our amazing wider\ncommunity contributors to get 440 merge requests merged in a single month! I’m certain this change contributed, among other\nchanges and initiatives, to that record. We will keep learning as we progress. It certainly allowed us to take a peek\ninto our little black box.\n\n## What’s next?\n\nNext up is to continue our iterations and move further towards automation. Right now it is up to the reviewer to set the\nstatus back to `workflow::in dev` whenever there is something left to address. We notice that this is not always changed\nback when it’s actually needed. It is also causing false-positives with reviewers and our wider community members.\nThe Contributor Success team is looking into how this can be automated. If you’d like to help, the automation happens in\nthe [Triage Ops project](https://gitlab.com/gitlab-org/quality/triage-ops/) and the Contributor Success [issue\nqueue](https://gitlab.com/gitlab-com/quality/contributor-success/-/issues) is open for everyone!\n\nWe’re also looking into a new program called [Leading\nOrganizations](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/110700) which rewards recurring\ncontributors, and their organizations, with a review time objective of four business days. This would lead us to even\nshorter review cycle times and give those organizations that contribute to GitLab a competitive advantage to stay\nleaders in their domain. The faster we can innovate together, the faster our dual flywheel will spin. Together we go to\ninfinity and beyond. Together we can build software fast.\n\n\n\n\n",[1541,865,675],"code review",{"slug":1543,"featured":6,"template":679},"pursuing-faster-time-to-merge-for-wider-community-contributions","content:en-us:blog:pursuing-faster-time-to-merge-for-wider-community-contributions.yml","Pursuing Faster Time To Merge For Wider Community Contributions","en-us/blog/pursuing-faster-time-to-merge-for-wider-community-contributions.yml","en-us/blog/pursuing-faster-time-to-merge-for-wider-community-contributions",{"_path":1549,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1550,"content":1556,"config":1562,"_id":1564,"_type":16,"title":1565,"_source":17,"_file":1566,"_stem":1567,"_extension":20},"/en-us/blog/5-problems-you-can-help-us-solve-right-now",{"title":1551,"description":1552,"ogTitle":1551,"ogDescription":1552,"noIndex":6,"ogImage":1553,"ogUrl":1554,"ogSiteName":713,"ogType":714,"canonicalUrls":1554,"schema":1555},"5 UX problems you can help us fix right now","“We spent 40 hours talking to 20 of you. Now we’ve got some issues we’d like your help on.”","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682386/Blog/Hero%20Images/pexels-sevenstorm-juhaszimrus-704767.jpg","https://about.gitlab.com/blog/5-problems-you-can-help-us-solve-right-now","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 UX problems you can help us fix right now\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ben Leduc-Mills\"}],\n        \"datePublished\": \"2022-07-25\",\n      }",{"title":1551,"description":1552,"authors":1557,"heroImage":1553,"date":1559,"body":1560,"category":14,"tags":1561},[1558],"Ben Leduc-Mills","2022-07-25"," \n\nWe’ve all been there. You’re sailing along, being productive, and wham! Something inexplicably awful disrupts your workflow. You ask yourself, “How could _anyone_ think this was a good idea?” Maybe it’s a bug, slow performance, or bad design. One of the reasons we conduct [user experience research at GitLab](/handbook/product/ux/ux-research/) is to find these problems and report back to our teams so they can fix them. \n\n![Grumpy cat looking over computer](https://about.gitlab.com/images/blogimages/hhh13-tEMU4lzAL0w-unsplash__1_.jpg)\nWe've all been there\n{: .note.text-center}\n\nWith a product as rich and complex as GitLab, we find _a lot_ of problems. So many, in fact, we often can't fix them as fast as you find them. ([Although we do try!](/releases/2022/05/22/gitlab-15-0-released/#bug-fixes)) The great thing about GitLab is that [**everyone** can contribute](/company/mission/). This is the first in a new series of blog posts where the UX researchers at GitLab transform their findings into some great first contributions that community members can explore. \n\nWe recently spent 2 hours each with 20 people who use GitLab, going through specific tasks related to branch and merge request operations, and, predictably, we found plenty of things to work on (although this research focused on the code creation and review process) - you can check out the full report below:\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe style=\"border: 1px solid rgba(0, 0, 0, 0.1);\" width=\"800\" height=\"450\" src=\"https://www.figma.com/embed?embed_host=share&url=https%3A%2F%2Fwww.figma.com%2Fproto%2FmF555KKsf1m1UyyXbWxXu2%2FBenchmarking-Slides%3Fnode-id%3D943%253A12915%26scaling%3Dscale-down%26page-id%3D40%253A124%26starting-point-node-id%3D943%253A12915\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n\n\nWithout further ado, here are five issues we would **love** your contributions on:\n\n1. [Show more branches in the drop down menu while reverting a merge request.](https://gitlab.com/gitlab-org/gitlab/-/issues/358218) \n1. [Increase the discoverability of the insert suggestion feature.](https://gitlab.com/gitlab-org/gitlab/-/issues/368716) \n1. [Fix data loss when switching from inline to side-by-side view on MR creation page.](https://gitlab.com/gitlab-org/gitlab/-/issues/358217) \n1. [Show selected labels within the dropdown menu.](https://gitlab.com/gitlab-org/gitlab/-/issues/322945) \n1. [Improve clarity of text-only buttons -- Move 'mark as draft' onto new line](https://gitlab.com/gitlab-org/gitlab/-/issues/358437) \n\nWondering where to start? Check out [this blog post](/blog/first-time-open-source-contributor-5-things-to-get-you-started/) and [our development guide](/community/contribute/development/) and become an all-star contributor! \n\nNeed guidance or help? Feel free to leave a comment directly on one of the issues linked above, or find support in the \"get help\" section [in our contributing guide](/community/contribute/#getting-help).\n\nContributing to an open source project also brings a ton of proven benefits you might not expect:\n\n- Contributing is one of the most efficient ways to learn, as it is learning by doing and [being guided by merge request coaches](https://handbook.gitlab.com/job-families/expert/merge-request-coach/). Contributing has been proven time and time again to be the best form of learning!\n- Public exposure and explicit appreciation from the open source community, which helps build your public profile And show your expertise ... you never know when that resume might come in handy! 😊 \n- You're in for a treat: **first-time** contributors receive GitLab swag, **regular** contributors (5 MRs or more) are eligible for the [GitLab Heroes program](/community/heroes), and **top** contributors may be invited to join the [GitLab Core team](/community/core-team/).\n\nAnd not only is this beneficial for you, but also for your employer (if you are employed). Because you are growing and learning at a rapid speed from the best, you will get a faster turnaround time when integrating a feature into the platform since you know how the system works. You will get more value from the most precious resource in the universe, time 🕐. Take advantage of this experience today. We are convinced of the benefits and we hope you and/or your employer are too now. Let's aim for the moon together. 🚀 \n\n1,2,3...**let's go!**\n\nCover image by [SevenStorm JUHASZIMRUS](https://www.pexels.com/@sevenstormphotography/) on [Pexels](https://www.pexels.com/photo/123-let-s-go-imaginary-text-704767/)\n{: .note}\n",[865,268,675,1412,1413],{"slug":1563,"featured":6,"template":679},"5-problems-you-can-help-us-solve-right-now","content:en-us:blog:5-problems-you-can-help-us-solve-right-now.yml","5 Problems You Can Help Us Solve Right Now","en-us/blog/5-problems-you-can-help-us-solve-right-now.yml","en-us/blog/5-problems-you-can-help-us-solve-right-now",{"_path":1569,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1570,"content":1576,"config":1585,"_id":1587,"_type":16,"title":1588,"_source":17,"_file":1589,"_stem":1590,"_extension":20},"/en-us/blog/configuring-your-cluster-with-kubernetes-integration",{"title":1571,"description":1572,"ogTitle":1571,"ogDescription":1572,"noIndex":6,"ogImage":1573,"ogUrl":1574,"ogSiteName":713,"ogType":714,"canonicalUrls":1574,"schema":1575},"Heroes journey: Working with GitLab's Kubernetes agent","A tutorial on deploying and monitoring an application in Kubernetes without leaving GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682342/Blog/Hero%20Images/treasure.jpg","https://about.gitlab.com/blog/configuring-your-cluster-with-kubernetes-integration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Heroes Unmasked - How I became acquainted with the GitLab Agent for Kubernetes\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jean-Philippe Baconnais\"}],\n        \"datePublished\": \"2022-06-08\",\n      }",{"title":1577,"description":1572,"authors":1578,"heroImage":1573,"date":1580,"body":1581,"category":14,"tags":1582},"GitLab Heroes Unmasked - How I became acquainted with the GitLab Agent for Kubernetes",[1579],"Jean-Philippe Baconnais","2022-06-08","\n\n_A key to GitLab’s success is our vast community of advocates. Here at GitLab, we call these active contributors \"[GitLab Heroes](/community/heroes/).\" Each hero contributes to GitLab in numerous ways, including elevating releases, sharing best practices, speaking at events, and more. Jean-Phillippe Baconnais is an active GitLab Hero, who hails from France. We applaud his contributions, including leading community engagement events. Baconnais shares his interest in Kubernetes and explains how to deploy and monitor an application in Kubernetes without leaving GitLab._ \n\nSince 2007, I’ve been a developer. I’ve learned a lot of things about continuous integration, deployment, infrastructure, and monitoring. In both my professional and personal time, my favorite activity remains software development. After creating a new application with multiple components, I wanted to deploy it on Kubernetes, which has been really famous over the last few years. This allows me to experiment on this platform. This announces a lot of very funny things. I know some terms, I used them in production for five years. But as a user, Kubernetes Administration is not my “cup of tea” 😅.\n\n## My first deployment in Kubernetes\n\nWhen I decided to deploy an application on Kubernetes, I wasn’t sure where to start until I saw, navigating in my project in GitLab, a menu called “Kubernetes.\" I wanted to know what GitLab was hiding behind this. Does this feature link my project’s sources to a Kubernetes cluster? I used the credit offered by Google Cloud to discover and test this platform. \n\nDeploying my application on Kubernetes was easy. I wrote [a blog post](https://dev.to/jphi_baconnais/deploy-an-quarkus-application-on-gke-with-gitlabci-lgp) in 2019 describing how I do this, or rather, how GitLab helped me to create this link so easily. In this blog post I will explain further and talk about what’s changed since then.\n\nBehind the “Kubernetes” menu, GitLab helps you integrate Kubernetes into your project. You can create, from GitLab, a cluster on Google Cloud Platform (GCP), and Amazon Web Services (AWS). If you already have a cluster on this platform or anywhere else, you can connect to it. You just need to specify the cluster name, Kubernetes API UR, and certificate.\n\n![Connect cluster](https://about.gitlab.com/images/blogimages/baconcreatecluster.png){: .shadow}\n\nGitLab is a DevOps platform and in the list of DevOps actions, there is the monitoring part. \n\n![Chart of GitLab stages](https://about.gitlab.com/images/blogimages/baconstreamline.png){: .shadow}\n\nGitLab deploys an instance of Prometheus to get information about your cluster and facilitate the monitoring of your application.\n\nFor example, you can see how many pods are deployed and their states in your environment. You can also view some charts and information about your cluster, like memory and CPU available. All these metrics are available by default without changing the application of your cluster. We can also read the logs directly in GitLab. For a developer, it’s great to have all this information on the same tool and this allows us to save time. \n\n![Pod deployment](https://about.gitlab.com/images/blogimages/baconhealth.png){: .shadow}\n\n\n## A new way to integrate Kubernetes\n\nEverything I explained in the previous chapter doesn’t quite exist anymore. The release of GitLab 14.5 was the beginning of a revolution. The Kubernetes integration with certificates has limitations on security and many issues were created. GitLab teams worked on a new way to rely on your cluster. And in Version 14.5, the [GitLab Agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/) was released! \n\n## GitLab Agent for Kubernetes\n\nGitLab Agent for Kubernetes is a new way to connect to your cluster. This solution is easy to explain: An agent installed on your cluster communicates with your GitLab instance with [gRPC](https://grpc.io/) protocol. Your agent offers you useful GitOps features I will explain later. The next picture shows you the GitLab Agent for Kubernetes architecture (from GitLab). \n\n![GitLab Agent for Kubernetes flow chart](https://about.gitlab.com/images/blogimages/baconkubernetesflowchart.png){: .shadow}\n\n### GitOps defined\n\nLet’s quickly define the term “[GitOps](/topics/gitops/)”: It’s a way to manage your infrastructure as code, in a Git project. For me, there are two aspects in GitOps: “pull” and “push” mode. \n\n- Push mode is when your Git project activates the upgrade of your infrastructure following a change. \n- Pull mode is when your infrastructure verifies without interruption of your Git project and applies changes automatically.\n\nAnd GitLab chose the latter mode for their solution of GitLab Agent for Kubernetes. Indeed, your agent available on your cluster will check frequently if your project changes. The gRPC protocol is great to respect this intent. When you push a modification on your project, agents detect it automatically, and then your cluster upgrades.\n\n### How the GitLab Agent for Kubernetes works\n\nThere are some actions to do to install and have a GitLab Agent for Kubernetes available on your project. \n\nFirst, if you create a new project on GitLab, you can use the template “Management cluster,” which allows the initialization of files. These files allow you to have examples of: \n- a declaration of an agent\n- a list of starter kits to install DevOps tools\n\nGitLab is a DevOps platform that wants to help you to configure all steps of the lifecycle of your project. You can find the configuration of tools like Prometheus, Sentry, Ingress, etc. I will detail this later.\n\n### The evolution of GitLab Agent for Kubernetes\n\nBefore explaining more details about this agent, you have to know one thing. This product is in constant evolution and your feedback is welcome in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/342696#note_899701396) to improve it. The roadmap is available and each version gives some information about its evolution.\n\n## How to use GitLab Agent for Kubernetes\n\nCreating an agent is simple. You have to create a file in the directory .gitlab/agents/\u003Cnameofyouragent>/config.yaml. \n\n\n![Connect cluster](https://about.gitlab.com/images/blogimages/baconstructure.png)\n\n\nThe default configuration should contain:\n- your project id, represented by your \u003Cuser or group>/project\n- a namespace by default to deploy applications if it’s not present in your yaml files\n- path of your yaml file to apply. This can be a specific file, a directory, or a pattern of files\n- level of debug\n\n```\n\ngitops:\n manifest_projects:\n - id: xxxxx/demo-gitlab-kubernetes-cluster-management\n   default_namespace: gitlab-kubernetes-agent-demo\n   paths:\n   - glob: 'deploy.yaml'\nobservability:\n logging:\n   level: debug\n\n```\n\nYou can add security to this configuration file with the “ci_access” property. For example, it allows developers to avoid destroying the Kubernetes infrastructure 😅. I didn’t explore in detail this part yet. \n\nAll configuration options are available on [this reference page](https://docs.gitlab.com/ee/user/clusters/agent/gitops.html#gitops-configuration-reference). \n\nAfter creating and pushing your file in your project, you have to register your agent. And this action takes two seconds on the GitLab UI. \n\n![Add an agent](https://about.gitlab.com/images/blogimages/baconaddanagent.png){: .shadow}\n\nOn the next step, GitLab gives you the Docker command to install your agent on your cluster. For example:\n\n```\n\ndocker run --pull=always --rm \\\n    registry.gitlab.com/gitlab-org/cluster-integration/gitlab-agent/cli:stable generate \\\n    --agent-token=\u003Cyour token generated by GitLab> \\\n    --kas-address=wss://kas.gitlab.com \\\n    --agent-version stable \\\n    --namespace gitlab-kubernetes-agent | kubectl apply -f -\n\n```\nYou can copy-paste this command on your cluster and your agent will be available in a Kubernetes namespace. You can see on the GitLab UI that the link with the agent is successful.\n\n![Link with agent success](https://about.gitlab.com/images/blogimages/baconagentk.png){: .shadow}\n\n\nYou can also verify this connection in logs of agent container: \n\n```\n\n{\"level\":\"debug\",\"time\":\"2022-xx-xxT14:11:57.517Z\",\"msg\":\"Handled a connection successfully\",\"mod_name\":\"reverse_tunnel\"}  \n\n```\n\n### GitLab cluster management \n\nGitLab is a DevOps platform and uses tiers of applications to manage all the steps of a modern DevOps pipeline. The “Monitor” part in GitLab is based on some tools such as [Prometheus](https://prometheus.io/docs/visualization/grafana/),[Sentry](https://sentry.io/), [Vault](https://www.vaultproject.io/), etc. To help you, GitLab created the template [GitLab Cluster Management]( https://gitlab.com/gitlab-org/project-templates/cluster-management), which gives you a basic configuration of these tools.\n\nTo install these tools, a `.gitlab-ci.yml` file is created and defines a job to deploy them with helmfile configuration. All these tools, contained in the directory named “applications,” can be overridden or customized in `values.yaml` file. \n \nAnd for my experimentation, I used this template and applied a small change to have an external IP address for the Prometheus instance. After registering this external IP in GitLab (Menu Settings > Monitor > Alerts), the Monitor menu has data. We can check information about any pods deployed on my cluster. \n\n![Agent graph](https://about.gitlab.com/images/blogimages/baconagentgraph.png){: .shadow}\n\n## The GitOps aspect \n\nThe GitOps aspect can be verified quickly. If you choose to specify one manifest file defining an application deployment, a modification on this file implies an automatic deployment on your cluster. Without CI! This allows us to have a faster deployment than if we passed with a pipeline. The new features or fixes will be deployed faster on your infrastructures. And if you use the free version of GitLab, your deployment will not count in your CI quota. \n\nAfter a commit, the agent detects it and we can see the commit id in the agent logs.\n\n```\n{\"level\":\"info\",\"time\":\"2022-04-11T15:22:44.049Z\",\"msg\":\"Synchronizing objects\",\"mod_name\":\"gitops\",\"project_id\":\"jeanphi-baconnais/demo-gitlab-kubernetes-cluster-management\",\"agent_id\":12804,\"commit_id\":\"e2a82fe6cc82fa25e8d5a72584774f4751407558\"}\n\n```\n\n## CI/CD tunnel\n\nAnother feature that comes with the GitLab Agent for Kubernetes is the CI/CD tunnel. Your agent facilitates the interaction with your cluster. You just have to define a KUBE_CONTEXT variable referencing the path of your agent. \n\n```\nvariables:\nKUBE_CONTEXT: \"xxxxx/demo-gitlab-kubernetes-cluster-management:agentk\"\n\n```\n\nAnd actions on your cluster are available without secret configuration or anything else. If you want to execute `kubectl` commands, you can easily use this job:\n\n```\n\ntest-cicd-tunnel:\n stage: test\n extends: [.kube-context]\n image:\n   name: bitnami/kubectl:latest\n   entrypoint: [\"\"]\n script:\n  - kubectl get ns\n when: manual\n\n```\n\n## What's next\n\nCurrently, GitLab Agent for Kubernetes doesn’t allow you to get information about the state of pods on your cluster’s environment page.\n\n![Success](https://about.gitlab.com/images/blogimages/baconci.png){: .shadow}\n\nBut GitLab wants to offer the same level of service as the certificate integration. So, check the roadmap ([in this issue](https://gitlab.com/groups/gitlab-org/-/epics/3329)) and the contents of each release. The template Cluster Management is in progress, too. Some issues will give new features for configuration tools.\n\nThis experience was so rewarding for me. I would deploy a project on Google Cloud, and I discovered a new method. I saw this agent described in [GitLab 14.5](/releases/2021/11/22/gitlab-14-5-released/) but I didn’t imagine the impact it can have on a project. \n\nMy colleague [Eric Briand](https://twitter.com/eric_briand) and I had the opportunity to speak about this subject at [Malt Academy sessions](https://www.malt-academy.com/) and [Meetup GitLab France](https://www.meetup.com/GitLab-Meetup-France/events/283917115). I will continue to experiment with this agent and try different options for this wonderful product! \n\n**This blog post and linked pages contain information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this video/blog post and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.**\n\nCover image by [Ashin K Suresh](https://unsplash.com/photos/mkxTOAxqTTo) on Unsplash.\n{: .note}\n",[780,268,1583,1584,865],"user stories","growth",{"slug":1586,"featured":6,"template":679},"configuring-your-cluster-with-kubernetes-integration","content:en-us:blog:configuring-your-cluster-with-kubernetes-integration.yml","Configuring Your Cluster With Kubernetes Integration","en-us/blog/configuring-your-cluster-with-kubernetes-integration.yml","en-us/blog/configuring-your-cluster-with-kubernetes-integration",{"_path":1592,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1593,"content":1599,"config":1604,"_id":1606,"_type":16,"title":1607,"_source":17,"_file":1608,"_stem":1609,"_extension":20},"/en-us/blog/a-go-micro-language-framework-for-building-dsls",{"title":1594,"description":1595,"ogTitle":1594,"ogDescription":1595,"noIndex":6,"ogImage":1596,"ogUrl":1597,"ogSiteName":713,"ogType":714,"canonicalUrls":1597,"schema":1598},"Lingo: A Go micro language framework for building Domain Specific Languages","Design, build and integrate your own Domain Specific Language with Lingo.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682320/Blog/Hero%20Images/typeset.png","https://about.gitlab.com/blog/a-go-micro-language-framework-for-building-dsls","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Lingo: A Go micro language framework for building Domain Specific Languages\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Julian Thome\"}],\n        \"datePublished\": \"2022-05-26\",\n      }",{"title":1594,"description":1595,"authors":1600,"heroImage":1596,"date":1601,"body":1602,"category":14,"tags":1603},[1497],"2022-05-26","\n\nDomain Specific Languages (DSL) are small, focused languages with a narrow\ndomain of applicability. DSLs are tailored towards their target domain so that\ndomain experts can formalize ideas based on their knowledge and background.\n\nThis makes DSLs powerful tools that can be used for the purpose of increasing\nprogrammer efficiency by being more expressive in their target\ndomain, compared to general purpose languages, and by providing concepts to\nreduce the cognitive load on their users.\n\nConsider the problem of summing up the balances of different bank accounts in a\nCSV file. A sample CSV file is provided in the example below where the first\ncolumn contains the name of the account holder and the second column contains\nthe account balance.\n\n``` csv\nname, balance\nLisa, 100.30\nBert, 241.41\nMaria, 151.13\n```\n\nYou could solve the problem of summing up balances by using a general-purpose\nlanguage such as [Ruby](https://www.ruby-lang.org/en/) as in the code snippet\nbelow. Apart from the fact that the code below is not very robust, it contains\na lot of boilerplate that is irrelevant to the problem at hand, i.e., summing\nup the account balances.\n\n``` ruby\n#!/usr/bin/env ruby\n\nexit(1) if ARGV.empty? || !File.exist?(ARGV[0])\n\nsum = 0\nFile.foreach(ARGV[0]).each_with_index do |line, idx|\n  next if idx == 0\n  sum += Float(line.split(',')[1])\nend\n\nputs sum.round(2)\n```\n\nBelow is an example [AWK script](https://en.wikipedia.org/wiki/AWK) that solves\nthe same problem. AWK is a DSL that was specifically designed to address\nproblems related to text-processing.\n\n``` awk \n#!/usr/bin/awk -f\n\nBEGIN{FS=\",\"}{sum+=$2}END{print sum}\n```\n\nThe Ruby program has a size of 208 characters, whereas the AWK program has a size of 56. The AWK program is roughly 4x smaller than its Ruby\ncounterpart. In addition, the AWK implementation is more robust by being less\nprone to glitches that may appear in the CSV file (e.g., empty newlines,\nwrongly formatted data-fields). The significant difference in terms of size\nillustrates that DSLs, by being more focused on solving specific problems, can\nmake their users more productive by sparing them the burden to write\nboilerplate code and narrowing the focus of the language on the problem at\nhand.\n\nSome popular DSLs most software developers use on a regular basis include\n[Regular Expressions](https://en.wikipedia.org/wiki/Regular_expression) for\npattern matching, AWK for text\ntransformation or [Standard Query Language](https://en.wikipedia.org/wiki/SQL)\nfor interacting with databases.\n\n## Challenges when designing Domain Specific Languages\n\nPrototyping, designing and evolving DSLs is a\nchallenging process. In our experience this is an exploratory cycle where you\nconstantly prototype ideas, incorporate them into the language, try them out in\nreality, collect feedback and improve the DSL based on the feedback. \n\nWhen designing a DSL, there are many components that have to be implemented and\nevolved. At a very high level there are two main components: the language\nlexer/parser and the language processor. The lexer/parser\nis the component that accepts input as per the language definition which is\nusually specified specified by means of a language grammar. The parsing/lexing\nphase produces a syntax tree which is then passed onto the language processor.\nA language processor evaluates the syntax tree. In the example we saw earlier,\nwe ran both the Ruby and AWK interpreters providing our scripts and the CSV\nfile as input; both interpreters evaluated the scripts and this evaluation\nyielded the sum of all the account balances as a result.\n\nTools such as parser generators can significantly reduce the effort of\nlexer/parser development by means of code generation. Sophisticated DSL\nframeworks such as [JetBrains MPS](https://www.jetbrains.com/mps/) or\n[Xtext](https://www.eclipse.org/Xtext/) also provide features that help\nimplement custom language support in IDEs. However, if present at all, the\nsupport for building the language processors is usually limited to generating\nplaceholders functions or boilerplate code for the language components that\nhave to be filled-in by the DSL developer. Moreover, such large and powerful DSL\nframeworks usually have a fairly steep learning curve so that they are probably\na better fit for more sophisticated DSLs as opposed to small, easily\nembeddable, focused languages, which we refer to as _micro languages_.\n\nIn some situations, it may be worth considering working around these problems\nby just relying on standard data exchange formats such as `.toml`, `.yaml` or\n`.json` as a means of configuration. Similar to the parser generators, using\nsuch a format may relieve some of the burden when it comes to parser\ndevelopment effort. However, this approach does not help when it comes to the\nimplementation of the actual language processor. In addition, most standard data\nexchange formats are inherently limited to representing data in terms of simple\nconcepts (such as lists, dictionaries, strings and numbers). This limitation\ncan lead to bloated configuration files quickly as shown in the following\nexample.\n\nImagine the development of a calculator that operates on integers using\nmultiplication `*`, addition `+`. When using a data-description language like\nYAML in the example below, you can see that even a small simple term like `1 + 2 * 3 + 5` \ncan be hard to reason about, and by adding more terms the configuration\nfile would get bloated quickly.\n\n``` yaml\nterm:\n  add: \n    - 1\n    - times:\n      - 2\n      - 3\n    - 5\n```\n\nThis blog post is focused on the design of micro languages. The core idea is to\nprovide a simple, extensible language core that can be easily extended with\ncustom-types and custom functions; the language can evolve without having\nto touch the parser or the language processor. Instead, the DSL designer can\njust focus on the concepts that ought to be integrated into the DSL by\nimplementing interfaces and \"hooking\" them into the core language\nimplementation.\n\n## Lingo: A micro language framework for Go\n\nAt GitLab, Go is one of our main programming languages and some of the tools we\ndevelop required their own, small, embeddable DSLs so that users could properly\nconfigure and interact with them. \n\nInitially, we tried to integrate already existing, embeddable and expandable\nlanguage implementations. Our only condition was that they had to be\nembeddable natively into a Go application. We explored several great free and\nopen-source (FOSS) projects such as [go-lua](https://github.com/Shopify/go-lua)\nwhich is Lua VM implemented in Go, [go-yeagi](https://github.com/traefik/yaegi)\nwhich provides a Go interpreter with which Go can be used as a scripting\nlanguage or [go-zygomys](https://github.com/glycerine/zygomys) which is a LISP\ninterpreter written in Go. However, these packages are essentially modules to\nintegrate general-purpose languages on top of which a DSL could be built. These modules ended up being fairly complex. In contrast, we wanted to have basic support to design, implement, embed and evolve DSLs natively into a Go\napplication that is flexible, small, simple/easy to grasp, evolve and\nadapt.\n\nWe were looking for a micro language framework with the properties listed below:\n\n1. Stability: Changes applied to the DSL should neither require any changes to the core lexer/parser implementation nor to the language processor implementation.\n1. Flexibility/Composability: New DSL concepts (data-types, functions) can be integrated via a simple plug-in mechanism.\n1. Simplicity: the language framework should have just\nenough features to provide a foundation that is powerful enough to implement\nand evolve a custom DSL. In addition, the whole implementation of the micro\nlanguage framework should be in pure Go so that it is easily embeddable in Go\napplications.\n\nSince none of the available FOSS tools we looked at was able to\nfulfill all of those requirements, we developed our own micro language framework\nin Go called Lingo which stands for \"**L**ISP-based Domain Specific Languages\n(DSLs) **in Go**\". Lingo is completely FOSS and available in the [Lingo Git repository](https://gitlab.com/gitlab-org/vulnerability-research/foss/lingo)\nunder the free and open source space of the [Vulnerability Research Team](https://about.gitlab.com/handbook/engineering/development/sec/secure/vulnerability-research/).\n\n[Lingo](https://gitlab.com/gitlab-org/vulnerability-research/foss/lingo)\nprovides a foundation for building DSLs based on Symbolic Expressions (S-expressions), i.e.,\nexpressions provided in the form of nested lists `(f ...)` where `f` can be\nconsidered as the placeholder that represents the function symbol. Using this format,\nthe mathematical term we saw earlier could be written as S-expression `(+ 1 (* 2 3) 5)`. \n\nS-expressions are versatile and easy to process due to their uniformity. In\naddition, they can be used to represent both code and data in a consistent\nmanner.\n\nWith regards to the Stability, Flexibility and Composability properties, \n[Lingo](https://gitlab.com/gitlab-org/vulnerability-research/foss/lingo)\nprovides a simple plug-in mechanism to add new functions as well as types\nwithout having to touch the core parser or language processor. From the\nperspective of the S-expression parser, the actual function symbol is\nessentially irrelevant with regards to the S-expression parsing. The language processor is just evaluating S-expressions and dispatching the execution to the interface implementations. These implementations are provided by the plug-ins based on the function symbol.\n\nWith regards to Simplicity, the Lingo code base is roughly 3K lines of pure Go code including the lexer/parser, an\nengine for code transformation, and the interpreter/evaluator. The small size\nshould make it possible to understand the entirety of the implementation.  \n\nReaders that are interested in the technical details of\nLingo itself can have a look at the\n[README.md](https://gitlab.com/gitlab-org/vulnerability-research/foss/lingo/-/blob/main/README.md)\nwhere the implementation details and the used theoretical foundations are explained.\nThis blog post focuses on how\nLingo can be used to build a DSL from scratch.\n\n## Using Lingo to design a data generation engine\n\nIn this example we are designing a data-generation engine in Go using\nLingo as a foundation. Our data generation engine may be used to generate structured input\ndata for fuzzing or other application contexts. This example illustrates how\nyou can use Lingo to create a language and the corresponding language\nprocessor. Going back to the example from the beginning, let us assume we would\nlike to generate CSV files in the format we saw at the beginning covering\naccount balances.\n\n``` csv\nname, balance\nLisa, 100.30\nBert, 241.41\nMaria, 151.13\n```\n\nOur language includes the following functions:\n\n1. `(oneof s0, s1, ..., sN)`: randomly returns one of the parameter strings `sX` (0 \u003C= X \u003C= N).\n1. `(join e0, e1, ..., eN)`: joins all argument expressions and concatenates their string representation `eX` (0 \u003C= X \u003C= N).\n1. `(genfloat min max)`: generates a random float number X (0 \u003C= X \u003C= N) and returns it.\n1. `(times num exp)`: repeats the pattern generated by exp num times.\n\nFor this example we are using\nLingo to build the language and the language processor to automatically generate CSV\noutput which we are going to feed back into the Ruby and AWK programs we saw in\nthe introduction in order to perform a stress test on them. \n\nWe refer to our new language/tool as _Random Text Generator_ (RTG) `.rtg`.\nBelow is a sample script `script.rtg` we'd like our program to digest in order\nto randomly generate CSV files. As you can see in the example below, we are\njoining sub-strings starting with the CSV header `name, balance`\nafter which we randomly generate 10 lines of names and balance amounts. In\nbetween, we also randomly generate some empty lines.\n\n```\n(join \n  (join \"name\" \",\" \"balance\" \"\\n\")\n  (times 10 \n    '(join \n      (oneof \n        \"Jim\" \n        \"Max\" \n        \"Simone\" \n        \"Carl\" \n        \"Paul\" \n        \"Karl\" \n        \"Ines\" \n        \"Jane\" \n        \"Geralt\" \n        \"Dandelion\" \n        \"Triss\" \n        \"Yennefer\" \n        \"Ciri\") \n      \",\" \n      (genfloat 0 10000) \n      \"\\n\" \n      (oneof \"\" \"\\n\"))))\n```\n\nOur engine takes the script above written in RTG and generates random CSV\ncontent. Below is an example CSV file generated from this script.\n\n``` csv\nname,balance\nCarl,25.648205\nInes,11758.551\n\nCiri,13300.558\n...\n```\n\nFor the remainder of this section, we explore how we can implement a\ndata generation engine based on Lingo. The implementation of RTG requires\nthe two main ingredients: (1) a float data type and a result object to integrate a float\nrepresentation and (2) implementations for the `times`, `oneof`, `genfloat` and\n`join` functions.\n\n### Introducing a float data type and result objects\n\nLingo differentiates between data types and result objects. Data types indicate how data is\nmeant to be used and result objects are used to pass intermediate results\nbetween functions where every result has a unique type. In the code snippet\nbelow, we introduce a new `float` data type. The comments in the code snippet below\nprovide more details.\n\n``` go \n// introduce float type\nvar TypeFloatId, TypeFloat = types.NewTypeWithProperties(\"float\", types.Primitive)\n// introduce token float type for parser\nvar TokFloat = parser.HookToken(parser.TokLabel(TypeFloat.Name))\n\n// recognize (true) as boolean\ntype FloatMatcher struct{}\n\n// this function is used by the parser to \"recognize\" floats as such\nfunc (i FloatMatcher) Match(s string) parser.TokLabel {\n  if !strings.Contains(s, \".\") {\n    return parser.TokUnknown\n  }\n\n  if _, err := strconv.ParseFloat(s, 32); err == nil {\n\treturn TokFloat.Label\n  }\n\n  return parser.TokUnknown\n}\nfunc (i FloatMatcher) Id() string {\n  return string(TokFloat.Label)\n}\n\nfunc init() {\n  // hook matcher into the parser\n  parser.HookMatcher(FloatMatcher{})\n}\n```\n\nIn addition, we also require a result object which we can use to pass around\nfloat values. This is an interface implementation where most of the functions names\nare self-explanatory. The important bit is the `Type` function\nthat returns our custom `float` type we introduced in the last snippet.\n\n``` go\ntype FloatResult struct{ Val float32 }\n// deep copy\nfunc (r FloatResult) DeepCopy() eval.Result { return NewFloatResult(r.Val) }\n// returns the string representation of this result type\nfunc (r FloatResult) String() string {\n  return strconv.FormatFloat(float64(r.Val), 'f', -1, 32)\n}\n// returns the data type for this result type\nfunc (r FloatResult) Type() types.Type   { return custtypes.TypeFloat }\n// call-back that is cleaned up when the environment is cleaned up\nfunc (r FloatResult) Tidy()              {}\n\nfunc (r FloatResult) Value() interface{} { return r.Val }\nfunc (r *FloatResult) SetValue(value interface{}) error {\n  boolVal, ok := value.(float32)\n  if !ok {\n    return fmt.Errorf(\"invalid type for Bool\")\n  }\n  r.Val = boolVal\n  return nil\n}\nfunc NewFloatResult(value float32) *FloatResult {\n  return &FloatResult{\n    value,\n  }\n}\n```\n\n### Implementing the DSL functions\n\nSimilar to the data type and return object, implementation of a DSL function is\nas simple as implementing an interface. In the example below we implement the\n`genfloat` function as an example. The most important parts are the `Symbol()`,\n`Validate()` and `Evaluate()` functions. The `Symbol()` function returns the\nfunction symbol which is `genfloat` in this particular case. \n\nBoth, the `Validate()` and `Evaluate()` functions take the environment `env`\nand the parameter Stack `stack` as the parameter. The environment is used to store\nintermediate results which is useful when declaring/defining variables. The `stack` includes the input parameters of the function. For\n`(genfloat 0 10000)`, the stack would consist out of two `IntResult` parameters\n`0` and `10000` where `IntResult` is a standard result object already provided by the\ncore implementation of Lingo. `Validate()` makes sure that the parameter can be\ndigested by the function at hand, whereas `Evaluate()` actually invokes the\nfunction. In this particular case, we are generating a float value within the\nspecified range and return the corresponding `FloatResult`.\n\n``` go\ntype FunctionGenfloat struct{}\n\n// returns a description of this function\nfunc (f *FunctionGenfloat) Desc() (string, string) {\n  return fmt.Sprintf(\"%s%s %s%s\",\n    string(parser.TokLeftPar),\n    f.Symbol(),\n\t\"min max\",\n\tstring(parser.TokRightPar)),\n\t\"generate float in rang [min max]\"\n}\n\n// this is the symbol f of the function (f ...)\nfunc (f *FunctionGenfloat) Symbol() parser.TokLabel {\n  return parser.TokLabel(\"genfloat\")\n}\n\n// validates the parameters of this function which are passed in\nfunc (f *FunctionGenfloat) Validate(env *eval.Environment, stack *eval.StackFrame) error {\n  if stack.Size() != 2 {\n    return eval.WrongNumberOfArgs(f.Symbol(), stack.Size(), 2)\n  }\n\n  for idx, item := range stack.Items() {\n    if item.Type() != types.TypeInt {\n\t  return eval.WrongTypeOfArg(f.Symbol(), idx+1, item)\n\t}\n  }\n  return nil\n}\n\n// evaluates the function and returns the result\nfunc (f *FunctionGenfloat) Evaluate(env *eval.Environment, stack *eval.StackFrame) (eval.Result, error) {\n  var result float32\n  rand.Seed(time.Now().UnixNano())\n  for !stack.Empty() {\n    max := stack.Pop().(*eval.IntResult)\n    min := stack.Pop().(*eval.IntResult)\n\n\tminval := float32(min.Val)\n\tmaxval := float32(max.Val)\n\n\tresult = minval + (rand.Float32() * (maxval - minval))\n  }\n\n  return custresults.NewFloatResult(result), nil\n}\n\nfunc NewFunctionGenfloat() (eval.Function, error) {\n  fun := &FunctionGenfloat{}\n  parser.HookToken(fun.Symbol())\n  return fun, nil\n}\n```\n\n### Putting it all together\n\nAfter implementing all the functions, we only have to register/integrate them\n(`eval.HookFunction(...)`) so that Lingo properly resolves them when processing\nthe program. In the example below, we are registering all of the custom functions\nwe implemented, i.e., `times`, `oneof`, `join`, `genfloat`. The `main()`\nfunction in the example below includes the code required to evaluate our script\n`script.rtg`.\n\n``` go\n// register function\nfunc register(fn eval.Function, err error) {\n  if err != nil {\n    log.Fatalf(\"failed to create %s function %s:\", fn.Symbol(), err.Error())\n  }\n  err = eval.HookFunction(fn)\n  if err != nil {\n    log.Fatalf(\"failed to hook bool function %s:\", err.Error())\n  }\n}\n\nfunc main() {\n  // register custom functions\n  register(functions.NewFunctionTimes())\n  register(functions.NewFunctionOneof())\n  register(functions.NewFunctionJoin())\n  register(functions.NewFunctionGenfloat())\n  register(functions.NewFunctionFloat())\n  if len(os.Args) \u003C= 1 {\n    fmt.Println(\"No script provided\")\n    os.Exit(1)\n  }\n  // evaluate script\n  result, err := eval.RunScriptPath(os.Args[1])\n  if err != nil {\n    fmt.Println(err.Error())\n    os.Exit(1)\n  }\n\n  // print output\n  fmt.Printf(strings.ReplaceAll(result.String(), \"\\\\n\", \"\\n\"))\n\n  os.Exit(0)\n}\n```\n\nThe source code for RTG is available\n[here](https://gitlab.com/julianthome/lingo-example). You can find information\nabout how to build and run the tool in the\n[README.md](https://gitlab.com/julianthome/lingo-example/-/blob/main/README.md).\n\nWith approx. 300 lines of Go code, we have successfully designed a language and\nimplemented a language processor. We can now use RTG to test the robustness of\nthe Ruby (`computebalance.rb`) and AWK scripts (`computebalance.awk`) we used\nat the beginning to sum up account balances. \n\n``` bash\ntimeout 10 watch -e './rtg script.rtg > out.csv && ./computebalance.awk out.csv'\ntimeout 10 watch -e './rtg script.rtg > out.csv && ./computebalance.rb out.csv'\n```\n\nThe experiment above shows that the files generated by means of RTG can be\nproperly digested by the AWK script which is much more robust since it can cope\nwith the all generated CSV files. In contrast, executing of the Ruby script\nresults in errors because it cannot properly cope with newlines as they appear\nin the CSV file.\n\nCover image by [Charles Deluvio](https://unsplash.com/@kristianstrand) on [Unsplash](https://unsplash.com/photos/p8gzCnZf39k)\n{: .note}\n\n",[864,781,1139],{"slug":1605,"featured":6,"template":679},"a-go-micro-language-framework-for-building-dsls","content:en-us:blog:a-go-micro-language-framework-for-building-dsls.yml","A Go Micro Language Framework For Building Dsls","en-us/blog/a-go-micro-language-framework-for-building-dsls.yml","en-us/blog/a-go-micro-language-framework-for-building-dsls",{"_path":1611,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1612,"content":1618,"config":1624,"_id":1626,"_type":16,"title":1627,"_source":17,"_file":1628,"_stem":1629,"_extension":20},"/en-us/blog/join-us-for-hacktoberfest-2021",{"title":1613,"description":1614,"ogTitle":1613,"ogDescription":1614,"noIndex":6,"ogImage":1615,"ogUrl":1616,"ogSiteName":713,"ogType":714,"canonicalUrls":1616,"schema":1617},"Join us for Hacktoberfest 2021!","GitLab is participating in this year's Hacktoberfest, and your contributions to open source projects hosted on GitLab.com will count. No tricks, just treats here!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671856/Blog/Hero%20Images/gitlab-hacktoberfest_blog-dark.png","https://about.gitlab.com/blog/join-us-for-hacktoberfest-2021","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Join us for Hacktoberfest 2021!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christos Bacharakis\"}],\n        \"datePublished\": \"2021-10-01\",\n      }",{"title":1613,"description":1614,"authors":1619,"heroImage":1615,"date":1621,"body":1622,"category":14,"tags":1623},[1620],"Christos Bacharakis","2021-10-01","\nIt’s October 2021, and we have quite a few treats in store. In addition to celebrating the 10th anniversary of the GitLab open source project, GitLab Inc. will be participating in Hacktoberfest, an event dedicated to increasing contributions to open source projects that's now in its eighth year. This has been widely requested by the open source community for years, so we’re thrilled to see GitLab support rolled out!\n\nThanks to [DigitalOcean](https://www.digitalocean.com/blog/hacktoberfest-is-back-2021/), the organization behind Hacktoberfest, people can now contribute to open source projects that are hosted on GitLab.com.\n\nIt’s easy, sign up on [the Hacktoberfest website](https://hacktoberfest.digitalocean.com) using your GitLab account and explore the available projects to contribute. \n\nProject maintainers who want their projects to participate in Hacktoberfest should follow the steps described on the Hacktoberfest website.\n\n## Contributing to GitLab\n\nAt GitLab, we want to make it easy for everyone to contribute by offering diverse opportunities to participate. Back-end or front-end, localization or tech writing, getting started or experienced contributor, GitLab team members have hand picked a series of issues and epics available for everyone to contribute to during Hacktoberfest.\n\nFind these opportunities through the Hacktoberfest website, or by [searching for projects that have added the “Hacktoberfest” topic](https://gitlab.com/explore/projects?topic=hacktoberfest) on GitLab.\n\nMore information can be found on the [GitLab Hacktoberfest event page](https://about.gitlab.com/events/). If you need help, you can always reach out via [our gitter channel](https://gitter.im/gitlab/gitlab), where GitLab team members and GitLab contributors hang out.\n\n## Treats galore!\n\nTo celebrate the launch of Hacktoberfest on the GitLab ecosystem, we’re offering GitLab swag to the five contributors with the highest number of accepted merge requests to the [GitLab open source project](https://gitlab.com/gitlab-org/gitlab). Merge requests to GitLab created in October 2021 and merged by the 15th of November will count towards this initiative. \n\nWe’re also sending GitLab swag to all contributors whose first merge request [to the GitLab open source project](https://gitlab.com/gitlab-org/gitlab) is created and merged during that time, so newcomers are very welcome!\n\nWe are excited to join DigitalOcean during the launch of Hacktoberfest on GitLab, and look forward to your contributions. If you’d like to share your story with us, please reach out via contributors@gitlab.com or the [Contributors Gitter Channel](https://gitter.im/gitlabhq/contributors).\n\nHappy contributing!\n",[268,865,278],{"slug":1625,"featured":6,"template":679},"join-us-for-hacktoberfest-2021","content:en-us:blog:join-us-for-hacktoberfest-2021.yml","Join Us For Hacktoberfest 2021","en-us/blog/join-us-for-hacktoberfest-2021.yml","en-us/blog/join-us-for-hacktoberfest-2021",{"_path":1631,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1632,"content":1638,"config":1644,"_id":1646,"_type":16,"title":1647,"_source":17,"_file":1648,"_stem":1649,"_extension":20},"/en-us/blog/how-orange-uses-gitlab-ci-cd-for-modern-devops",{"title":1633,"description":1634,"ogTitle":1633,"ogDescription":1634,"noIndex":6,"ogImage":1635,"ogUrl":1636,"ogSiteName":713,"ogType":714,"canonicalUrls":1636,"schema":1637},"How Orange made a first step toward CI/CD standardization with GitLab","Find out how Orange made a first step toward CI/CD standardization with GitLab","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682084/Blog/Hero%20Images/oranges.jpg","https://about.gitlab.com/blog/how-orange-uses-gitlab-ci-cd-for-modern-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How Orange made a first step toward CI/CD standardization with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Pierre Smeyers\"}],\n        \"datePublished\": \"2021-07-29\",\n      }",{"title":1633,"description":1634,"authors":1639,"heroImage":1635,"date":1641,"body":1642,"category":14,"tags":1643},[1640],"Pierre Smeyers","2021-07-29","\n\nCI/CD is a foundational piece to modern software development. It's a major brick in the [DevOps](/topics/devops/) \"Automation\" pillar and every company involved in IT has to implement CI/CD or they're already quite far behind the curve.\n\nBut [implementing CI/CD](/topics/ci-cd/) can be challenging especially for growing or large companies. Some of those challenges include:\n\n* DevOps expertise and technical skills\n* [DevSecOps](/topics/devsecops/)\n* Standardization\n\n## Three key hurdles that come with implementing CI/CD\n\nThis blog post unpackes these challenges and explains how [Orange](https://orange.com/) overcame them using GitLab.\n\n### DevOps and technical skills\n\nNo matter which CI/CD tool you're using, it requires some amount of expertise to implement it right.\n\n**DevOps expertise** is important because your team needs some experience with Git workflows, deployment, environments, secrets management, etc. You can't ask a complete rookie to implement a state-of-the art DevOps pipeline without expertise or experience.\n\n**Technical skills** are also important for implementing CI/CD. Any professional can tell you that getting started tutorials are insufficient. We inevitably need advanced functions, and that requires knowing the tool pretty well. This is particularly true with GitLab CI/CD, which is a fantastic functionally rich tool. GitLab CI/CD is constantly evolving, which creates an ongoing burden for projects that want to integrate new tooling as they go.\n\n### DevSecOps\n\nDevOps is all about finding the right balance between shortening the cycle and maximizing your confidence.\n\n[DevSecOps tools](/solutions/security-compliance/) are a keystone in maximizing our confidence because they detect issues with things like security, code quality, and compliance, etc., almost instantly. But DevSecOps tools are evolving quickly and today's Docker container scanner tools can be replaced by newcomers in just a few months.\n\nAlso, having each development team in the company choose and integrate various DevSecOps tools doesn't make sense and will be a waste of time and resources. Going this route means most developers won't use any DevSecOps tool because the opportunity cost isn't worth the time and effort.\n\n### Standardization\n\nThe last challenge in implementing CI/CD at a large company is the lack of standardization.\n\nGitLab CI/CD - as with most other CI/CD tools - is mainly a sophisticated scheduler, allowing a team to define technical tasks and their sequence. GitLab CI/CD cares little about the nature of these tasks, and does not give any clues as to the \"right\" way to build a DevOps pipeline. The consequence of this is that every company, project team, and developer will implement a DevOps pipeline their own way, in a manner that is probably significantly different from their colleagues'.\n\nAs a lifelong Javaist, I like to compare the current situation in CI/CD with what was the Java build in the pre-Maven era. Back then, we used non-structuring tools such as [Make](https://en.wikipedia.org/wiki/Make_(software)) or [Apache Ant](https://en.wikipedia.org/wiki/Apache_Ant). Each project created its own build system, adopted its own conventions, code, and resource files structure. In short, it was a happy mess with everyone reinventing the wheel. When joining another project, a user had to ask: \"How does the build work here?\".\n\nIn 2004, Maven was released (and Gradle three years later). For a while, there were heated debates between the proponents of standardization and the defenders of expertise and customization. Today it would not occur to anyone to build a Java project with anything other than Maven or Gradle. Now, if I join a project developed in Java, I will immediately know how files are organized and how the project is built. Java build is now standardized.\n\nI believe that CI/CD ought to go a similar route: tools should offer a more opinionated framework so that CI/CD too becomes a non-topic.\n\n## How a single GitLab feature changed the game for Orange\n\nAt Orange - probably like many other companies involved in IT - we struggled with the three challenges summarized above.\n\nThen in January 2019, the [`include`](https://docs.gitlab.com/ee/ci/yaml/#include) feature was released in the [Community Edition (version 11.7) of GitLab](/releases/2019/01/22/gitlab-11-7-released/):\n\n```yaml\ninclude:\n  - project: a-path/to-some-project'\n    file: '/very-smart-template.yml'\n```\n\nThis feature finally gave us the ability to develop and share state-of-the-art GitLab CI/CD pipeline templates!\n\nSo that's what we did.\n\nFor two years, a handful of DevOps/security/languages/cloud experts developed ready-to-use GitLab CI/CD pipeline templates. This personal initiative quickly became recognized as an internal project, attracting more users and contributors, bringing the community to 1000+ members as of June 2021, and leveraging about 30 available templates. The visible effect of this increasing adoption is the beginning of a **CI/CD standardization at Orange**.\n\nWe were so happy with our results and convinced that it's a general need that we open sourced our templates under the name [\"to be continuous\"](https://to-be-continuous.gitlab.io/doc/).\n\n![To be continuous logo](https://about.gitlab.com/images/blogimages/orange_tbc.jpg){: .shadow}\nThe \"to be continuous\" logo.\n{: .note.text-center}\n\n### What is in *to be continuous*?\n\nFor now, *to be continuous* has 26 templates of six kinds:\n\n* **Build & Test**: Angular, Bash, Go, Gradle, Maven, MkDocs, Node.js, PHP, Python\n* **Code Analysis**: Gitleaks, SonarQube\n* **Packaging**: Docker\n* **Infrastructure** (IaC): Terraform\n* **Deploy & Run**: Ansible, Cloud Foundry, Google Cloud, Helm, Kubernetes, OpenShift, S3 (Simple Storage Service)\n* **Acceptance**: Cypress, Postman, Puppeteer, Robot Framework, SSL test, k6\n* **Others**: semantic-release\n\n*To be continuous* is thoroughly documented:\n\n* [Basic notions and philosophy](https://to-be-continuous.gitlab.io/doc/understand/)\n* [General usage principles](https://to-be-continuous.gitlab.io/doc/usage/)\n* How to use *to be continuous* in a [self-managed instance of GitLab](https://to-be-continuous.gitlab.io/doc/self-managed/basic/)\n* Every template also has [its own documentation](https://to-be-continuous.gitlab.io/doc/ref/angular/)\n\nTo get started quickly, *to be continuous* provides an [interactive configurer](https://to-be-continuous.gitlab.io/kicker/) (aka *\"kicker\"*) that allows generating the `.gitlab-ci.yml` file simply by selecting the technical characteristics of your project.\n\nFinally, *to be continuous* exposes several [example projects](https://gitlab.com/to-be-continuous/samples), illustrating how to use the templates in production-like projects, combining multiple templates.\n\n### A quick glance at *to be continuous*\n\nThere are tons of resources to get started with *to be continuous*. But here is a quick example to get the taste of it.\n\nHere is the `.gitlab-ci.yml` file for a project:\n\n* Developed in Java 11 (built with Maven)\n* Code analysis with SonarQube\n* Packaged as a Docker image\n* Deployed to Kubernetes cluster\n* GUI tests with Cypress\n* API tests with Postman (Newman)\n\n```yaml\ninclude:\n  # Maven template\n  - project: \"to-be-continuous/maven\"\n    ref: \"1.4.2\"\n    file: \"templates/gitlab-ci-maven.yml\"\n  # Docker template\n  - project: \"to-be-continuous/docker\"\n    ref: \"1.2.0\"\n    file: \"templates/gitlab-ci-docker.yml\"\n  # Kubernetes template\n  - project: \"to-be-continuous/kubernetes\"\n    ref: \"1.2.0\"\n    file: \"templates/gitlab-ci-k8s.yml\"\n  # Cypress template\n  - project: \"to-be-continuous/cypress\"\n    ref: \"1.2.0\"\n    file: \"templates/gitlab-ci-cypress.yml\"\n  # Postman template\n  - project: \"to-be-continuous/postman\"\n    ref: \"1.2.0\"\n    file: \"templates/gitlab-ci-postman.yml\"\n\n# Global variables\nvariables:\n  # Explicitly define the Maven + JDK version\n  MAVEN_IMAGE: \"maven:3.8-openjdk-11\"\n\n  # Enables SonarQube analysis (on sonarcloud.io)\n  SONAR_URL: \"https://sonarcloud.io\"\n  # organization & projectKey defined in pom.xml\n  # SONAR_AUTH_TOKEN defined as a secret CI/CD variable\n\n  # Kubernetes\n  K8S_KUBECTL_IMAGE: \"bitnami/kubectl:1.17\" # client version matching my cluster\n  K8S_URL: \"https://k8s-api.my.domain\" # Kubernetes Cluster API url\n  # K8S_CA_CERT & K8S_TOKEN defined as secret CI/CD variables\n  # enable review, staging & prod\n  K8S_REVIEW_SPACE: \"non-prod\"\n  K8S_STAGING_SPACE: \"non-prod\"\n  K8S_PROD_SPACE: \"prod\"\n\n  # Cypress & Postman: enable test on review aps\n  REVIEW_ENABLED: \"true\"\n\n# Pipeline steps\nstages:\n  - build\n  - test\n  - package-build\n  - package-test\n  - review\n  - staging\n  - deploy\n  - acceptance\n  - publish\n  - production\n  ```\n\nThis fully declarative file produces the following **development pipeline** (any feature branch):\n\n![Screenshot of development pipeline](https://about.gitlab.com/images/blogimages/orange_development_pipeline.jpg){: .shadow}\n\n... and the following **production pipeline** (`master` or `main` depending on your preferences):\n\n![Screenshot of production pipeline](https://about.gitlab.com/images/blogimages/orange_production_pipeline.jpg){: .shadow}\n\nAlthough they look pretty much the same, they aren't:\n\n* While the production pipeline privileges sureness and completeness, development pipelines privilege short cycles and developer experience. While code analysis jobs and acceptance tests are blocked in production, they only generate a non-blocking warning in development in case of failure.\n* The production pipeline deploys to the staging environment before deploying to production (provided acceptance tests are green). Development pipelines may deploy to a dynamically generated review environment (optional).\n* Developers may prefer to use a single integration environment (associated with the develop branch) instead of one review app per feature branch. The default behavior of the integration pipeline is much closer to the production one.\n\nWhat you can't see:\n\n* Java unit tests are automatically executed, their report is [integrated to GitLab](https://docs.gitlab.com/ee/ci/unit_test_reports.html), with [code coverage](https://docs.gitlab.com/ee/ci/yaml/#coverage) too.\n* SonarQube integration automatically uses [branch analysis](https://docs.sonarqube.org/latest/branches/overview/) or [MR analysis](https://docs.sonarqube.org/latest/analysis/pull-request/) (with MR decoration) depending on the context.\n* Kubernetes environments are obviously [integrated to GitLab](https://docs.gitlab.com/ee/ci/environments/) too.\n* [Review apps](https://docs.gitlab.com/ee/ci/review_apps/index.html) can be cleaned-up manually or automatically on branch deletion.\n* Cypress and Postman tests reports are also [integrated to GitLab](https://docs.gitlab.com/ee/ci/unit_test_reports.html).\n* Docker uses the Kaniko build by default but it might be configured to use Docker-in-Docker instead. It uses the GitLab registry by default but can be configured to use any other registry.\n* Each template integrates the most appropriate DevSecOps tools: [kube-score](https://kube-score.com/) for Kubernetes, [hadolint](https://github.com/hadolint/hadolint) for Docker, [OWASP Dependency-Check](https://jeremylong.github.io/DependencyCheck/) for Maven, among others.\n* All those templates combine themselves gracefully. For example, Kubernetes may simply deploy the Docker image built upstream; Cypress and Postman tests automatically test the application deployed in the upstream jobs; Kubernetes could be replaced with OpenShift, GCP or any other supported hosting technology, it would behave the same.\n\n## Contribute to *to be continuous*\n\n[to be continuous](https://to-be-continuous.gitlab.io/doc) is out and eagerly waiting for users and contributors.\n\nHave a look and share your feedback. Whether you like our choices or not, we want to hear from you. Your inputs are even more valuable to help us improve *to be continuous* and cover as many use cases as possible.\n\nBut anyway, never forget this: [`include`](https://docs.gitlab.com/ee/ci/yaml/#include) is undoubtedly the feature that makes CI/CD standardization possible in your company (and beyond).\n\nCover image by [Graphic Node](https://unsplash.com/@graphicnode) on [Unsplash](https://unsplash.com/photos/yi1YB_FubH8)\n{: .note}\n",[1434,675,1000],{"slug":1645,"featured":6,"template":679},"how-orange-uses-gitlab-ci-cd-for-modern-devops","content:en-us:blog:how-orange-uses-gitlab-ci-cd-for-modern-devops.yml","How Orange Uses Gitlab Ci Cd For Modern Devops","en-us/blog/how-orange-uses-gitlab-ci-cd-for-modern-devops.yml","en-us/blog/how-orange-uses-gitlab-ci-cd-for-modern-devops",{"_path":1651,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1652,"content":1658,"config":1667,"_id":1669,"_type":16,"title":1670,"_source":17,"_file":1671,"_stem":1672,"_extension":20},"/en-us/blog/outreachy-sponsorship-winter-2020",{"title":1653,"description":1654,"ogTitle":1653,"ogDescription":1654,"noIndex":6,"ogImage":1655,"ogUrl":1656,"ogSiteName":713,"ogType":714,"canonicalUrls":1656,"schema":1657},"Technology internships meet open source in Outreachy","Inside Outreachy technology internships, where participants work on Git.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664041/Blog/Hero%20Images/open-devops.png","https://about.gitlab.com/blog/outreachy-sponsorship-winter-2020","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Technology internships meet open source in Outreachy\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joey Salazar\"},{\"@type\":\"Person\",\"name\":\"Charvi Mendiratta\"},{\"@type\":\"Person\",\"name\":\"Nuritzi Sanchez\"},{\"@type\":\"Person\",\"name\":\"Christian Couder\"}],\n        \"datePublished\": \"2021-04-15\",\n      }",{"title":1653,"description":1654,"authors":1659,"heroImage":1655,"date":1663,"body":1664,"category":14,"tags":1665},[1660,1661,1662,798],"Joey Salazar","Charvi Mendiratta","Nuritzi Sanchez","2021-04-15","\n\nAs an enthusiastic participant in the [open source](/blog/innersourcing-using-the-open-source-workflow-to-improve-collaboration-within-an-organization/) community, we were excited to participate in the [Outreachy technology internships program](https://www.outreachy.org/) again this year, which focuses on women and underrepresented groups. It's a way GitLab can give back, and as a bonus, Outreachy's principles intersect with [our Diversity, Inclusion and Belonging value](https://handbook.gitlab.com/handbook/values/#diversity-inclusion).\n\n## About the Outreachy program\n\nInitially, Outreachy began as the Open Source Program for Women (OPW) at [GNOME](https://www.gnome.org/about-us/). The program was successful and grew quickly. Today, Outreachy has grown into the largest global technology internships program that provides opportunities for women and underrepresented groups to work on open source projects.\n\nCurrently, Outreachy is independently organized with the help of many volunteers, or sponsored help. For example, [Cindy Pallares](/company/team/#cindy) is a GitLab employee and helps with organizing Outreachy as a site reliability engineer.\n\nOutreachy is a paid technology internship program that runs twice a year for three months. During that time, interns can work in areas like programming, user experience, documentation, illustration and graphic design, or data science. In this technology internship program, participants work remotely with experienced mentors from prominent FOSS communities like Git, Mozilla, Linux kernel, GNOME, Wikimedia, and many others.\n\nOne of the benefits of the Outreachy technology internship is that the interns do not need to be students. It's a great opportunity for people who are coming back into the workforce after a hiatus, or who are navigating a career change into tech. This technology internship program is unique because it incorporates skill sets beyond engineering – which creates a broader range of skill sets represented in the open source world. The Outreachy internship is remote, making it more relevant than ever during the pandemic by helping interns gain experience working on an all-remote team.\n\nGitLab is one of the organizations that sponsors the Outreachy technology internship program, and we hope that by sharing our experience we can encourage more tech organizations to join us in participating in Outreachy as [corporate sponsors](https://www.outreachy.org/sponsor/).\n\n## Outreachy interns work on Git\n\nMore than 90% of the professional applications created today are built using open source components, according to a [2020 Tidelift survey](https://cdn2.hubspot.net/hubfs/4008838/Resources/The-Tidelift-guide-to-managed-open-source.pdf?utm_source=hs_automation&utm_medium=email&utm_content=66640714). One of the fundamental open source technologies we leverage at GitLab is the [Git project](https://git-scm.com/), so we chose to sponsor an Outreachy intern to work there.\n\n> GitLab sponsors an Outreachy intern to work on one of the most critical open source technologies that it relies on: The Git project.\n\n[Christian Couder](/company/team/#chriscool), senior backend software engineer at GitLab, who works on Git full-time, introduced the [GitLab Developer Relations team](/handbook/marketing/developer-relations/) to the Outreachy opportunity during the winter of 2017-2018 round. An experienced mentor for other programs like Google Summer of Code, Christian thought that it would be great to mentor an intern through the Outreachy program as well. Since the number of mentored interns and the need to sponsor them increased over the years, GitLab has sponsored an Outreachy intern for the Git project since winter 2019-2020.\n\nOutreachy at Git works similarly to the [Google Summer of Code (GSoC) program](https://summerofcode.withgoogle.com/). Git participates in GSoC in the summer and Outreachy in the winter. These programs consist of the Git project finding mentors and project ideas for individual participants to work on. Then there is a selection step, which includes working on a micro-project (a small code-related change), as part of the application process, and writing a proposal for a project to work on during the internship. After the interns are announced, they begin to work on their projects. Typically, Git tries to provide two mentors per intern to provide the best possible experience for the mentee.\n\n> The mentors used to be long-time Git developers, but more and more Outreachy and GSoC alumni have returned to the program as mentors, indicating the power of these programs.\n\nThe mentors volunteer some time each week to help their mentees by answering questions, providing suggestions, reviewing contributions, etc. Contributions still have to be sent by participants to the Git mailing list as patches. Then, other experienced Git contributors review the contributions before they are integrated into the Git code base by [Junio Hamano](https://www.linkedin.com/in/gitster), the Git maintainer.\n\n## Meet the Outreachy interns\n\nWe met with the Outreachy interns at Git to learn more about their experience participating in the winter 2020-2021 Outreachy technology internship program. In the next section, the Outreachy interns shared what the experience was like, in their own words.\n\n### Charvi Mendiratta: A self-taught programmer with an interest in robotics\n\n_This section was written by Charvi._\n\n> I am a recent graduate from the electronics field in India, a self-taught programmer with internship experiences working on mobile robotics projects, and I aim to pursue a career as a software developer. - [Charvi](https://charvi-077.github.io/about/)\n\nIt turned out to be difficult to find a job as a software developer because of my background in electronics and because I lacked professional programming skills. Also, there are very few job opportunities for recent graduates in software engineering roles, especially those related to robotics.\n\nDue to these challenges, I decided to try out open source in parallel with brushing up my skills. I supposed that open source contributions would be the best way to get hands-on experience with projects that required real-life problem solving skills, and I wanted to learn to convert my code into deployable software. That's why I decided to apply to the Outreachy program.\n\nBesides wanting to learn more about creating enterprise-grade code, I have always been interested in being part of the open source community. I first learned about open source work culture from my college programming community. I remember the old days when I attended an open source event called '[Software Freedom Day](http://www.softwarefreedomday.in/)' at my university. That's where I first learned about different open source programs like Outreachy.\n\n> Over the course of my three month internship, I worked on cleaning up and improving the Git interactive rebase, which is a useful git command to rewrite or modify the commit history. - Charvi\n\n#### About Charvi's Outreachy project\n\nMy work on Git's interactive rebase, which was mentored by Christian and [Phillip Wood](https://git.github.io/rev_news/2019/11/20/edition-57/), will help users who want to rework their commits and make it easier for users to improve the quality of their contributions. When teams practice code review, for example, it's very useful to rework commits to make them better or easier to understand before a reviewer steps in, and to fix them when reviews point to problems.\n\nFirst, I added the options '-c' and '-C' to the present `fixup` command in the interactive rebase. The `fixup` command adds the functionality to edit the commit message of the specific commit listed in the interactive rebase (see [merged patches](https://lore.kernel.org/git/20210129182050.26143-1-charvi077@gmail.com/)). This work is based on the [original patch series](https://github.com/phillipwood/git/commits/wip/rebase-amend), started by Phillip.\n\nThen, I worked on the [follow-up patches](https://lore.kernel.org/git/20210210113650.19715-1-charvi077@gmail.com/) and introduced some improvements after discussing the user interface of the added options with the Git community. Next, I worked on adding the new feature to `git commit --fixup` that allows to prepare the \"amend!\" and \"reword!\" commit, as an alternative to the present `fixup!` commit. It works with `git commit --autosquash` and will help to fix-up the content and commit message of the specific commit from the command line (see [merged patches](https://lore.kernel.org/git/20210315075435.18229-1-charvi077@gmail.com/)).\n\n### Joey Salazar: An engineer with international experience\n\n_This section was written by Joey._\n\n> As a female engineer from Costa Rica, who graduated in China through a full scholarship, it has been a challenge to find opportunities with mentoring for my transition from IT into programming. - [Joey](https://about.me/gomezsalazar-jogebeth)\n\nEven though I worked five years in IT (OS, networking, and storage), and was certified in Linux+ and CCNA through self-learning before beginning my software engineering studies, most companies and organizations seem eager to hire mid-senior level developers. Very few seem willing to invest in helping people get to that level, or in finding ways to build on any preexisting IT experience. As an open source advocate, it was through my research of open source technologies and the open source space that I came across community groups such as [WomenWhoCode](https://www.womenwhocode.com/), which was where I learned about Outreachy.\n\n#### About Joey's Outreachy project\n\n> My favorite thing to work on, probably because of my [background in privacy advocacy](https://www.techdirt.com/articles/20200622/08142044757/long-past-time-to-encrypt-entire-dns.shtml), was adding the foundations of HTTPS connection support for the Git protocol by following up on [a patch](https://gitlab.com/wireshark/wireshark/-/merge_requests/1946) started (and shared by) long-time Wireshark developer, [Richard Sharpe](https://sharkfestus.wireshark.org/bios/richard-sharpe). –  Joey\n\nMy work on Git protocol support in [Wireshark](https://www.wireshark.org/), which was mentored by Git developers employed by Google, [Emily Shaffer](https://nasamuffin.dev) and Jonathan Nieder, will help users debugging Git or any Git using software (like GitLab). This work helps production teams or developers understand what's going on between Git clients and servers, so they can better troubleshoot or optimize how Git works. This project will help demystify Git and its inner workings in the tech community.\n\nAs Wireshark is \"the world’s foremost and widely-used network protocol analyzer\", improving the way it dissects and presents the Git protocol to the user is helpful and important. Traffic interception and analysis is part of many user's workflows – from students, to researchers and advocates. For a few years, Git's dissector in Wireshark was bare-bones, and supported only raw traffic transmitted over regular TCP transport – my work is helping to change that.\n\nBy starting with [base functionality](https://gitlab.com/wireshark/wireshark/-/merge_requests/1922) and building on top of other member's work, Joey and her mentors added parsing of the multiplexing ([sideband](https://gitlab.com/wireshark/wireshark/-/merge_requests/1313)) version in use (if any) to Wireshark's dissector for the Git protocol. Next, they [added parsing for the specific version](https://gitlab.com/wireshark/wireshark/-/merge_requests/1714) of the Git protocol that is used, following up on [an MR to parse the Git protocol version](https://gitlab.com/wireshark/wireshark/-/merge_requests/805), did some refactoring on [an MR to refactor Git packet line dissector](https://gitlab.com/wireshark/wireshark/-/merge_requests/1942), and began the foundations for Git protocol's [testing suite](https://gitlab.com/wireshark/wireshark/-/merge_requests/2142).\n\nToday the Git dissector now includes more functionality and error handling, as well as HTTPS transport support – all of which was done through GitLab's platform.\n\n## Outreachy mentor shares experience\n\n_Christian, the Outreachy mentor and GitLab team member who worked with Joey and Charvi, shares what the experience was like in his own words._\n\nThere are many rewarding parts to being a mentor. I really enjoy seeing mentees gain confidence over the weeks in their abilities to contribute significantly by themselves.\n\n> Since Git is used by more than 80% of the developers in the world, I hope that the Outreachy interns get the feeling that they can improve things even in small ways for millions of people and that their work can have a global impact. - Christian\n\nI also really enjoy it when former mentees want to continue contributing to the Git community after their internship. Outreachy alumni contributions can take many forms. Sometimes they continue to contribute on the same topic as their project, sometimes they participate in related discussions, even 10 years later. One of our mentees was recently hired to work full-time on Git. And it is of course great when they want to become mentors, so they can give back to the program and increase the number of people who can get mentored.\n\nIt's great too that Outreachy, Google, and sometimes the Git project itself all provide funds for former mentees to come to in-person Git events or open source-related conferences. Meeting mentees in-person is very rewarding. At in-person events, the interns can also meet a number of Git-related companies and people, and of course, learn even more about Git and open source. For some of them, it was the first time they traveled outside of their country or could visit a different continent.\n\n#### Mentorship comes with challenges\n\nThe most challenging part of being a mentor is the fact that the Git codebase is getting bigger and more complex as Git evolves and gains features all the time.\n\nThis makes it hard for participants to stay on track when the internship starts. They sometimes have to trust that following the process we suggest will lead them to better and better understanding until they can find their own way and become autonomous.\n\n## Outreach interns share their key takeaways\n\nWe asked Joey and Charvi to share some of the ways that the Outreachy technology internship has impacted them.\n\n### Joey has a better understanding of herself\n\n_This section was written by Joey._\n\n> My Outreachy internship helped me better define the type of team and community that I'd like to join and which will benefit the most from the wide range of skills that I can offer. – Joey\n\nOutreachy was an amazing help, not only in technical areas, but also with soft skills. For example, I formed a solid understanding of Git. Now I can use `git cherry-pick` and `git rebase`, as well as squash, comfortably since I understand better what they do, and how. Those Git commands gave me lots of trouble when I was a junior developer for [BIND](https://en.wikipedia.org/wiki/BIND), and now they don't give me trouble anymore. I also reinforced fundamentals in C -- implementing pointers and references without panic and knowing about vtables -- and I learned how to write test cases in Python.\n\nA crowning achievement was finding balance between patience and impatience, and between autonomy and guidance.\n\n### Charvi has fallen in love with the open source world\n\n_This section was written by Charvi._\n\n> Outreachy helped me start my open source journey. - Charvi\n\nI have always been fascinated with the open source work culture as a way to learn, share, and grow. I finally got wonderful working experience too, since both Outreachy and the Git project are prestigious organizations.\n\nI learned a lot throughout the entire internship, starting from when the Outreachy contribution period began before I qualified for the internship. On the technical side, I enhanced my C programming and debugging skills, learned to write neat code, learned about shell scripts, and developed a deeper understanding of Git commands and about the Git project workflow.\n\nApart from this, my internship helped me improve my communication skills, make connections with amazing software developers, and  become more confident in myself. I am sincerely thankful for the Outreachy program, Git community, and my mentors, Christian and Phillip. It was an amazing learning journey.\n\n## So what's next?\n\nNow that the Outreachy internship has concluded, both Joey and Charvi are ready to leverage their skills and experience working on the Git project to future work in FOSS. Learn more about [Charvi's experience](https://charvi-077.github.io/about/) and [Joey's experience](https://about.me/gomezsalazar-jogebeth) by following the links.\n\n## GitLab's continued internship opportunities\n\nGitLab is proud to have sponsored and mentored an intern for the Git project during the most recent round of Outreachy technology internships. We hope to someday qualify for our own Outreachy interns to work on the [GitLab FOSS project](https://gitlab.com/gitlab-org/gitlab-foss) (which celebrates 10 years in October 2021).\n\nThis summer, GitLab will also be participating for the first time in [Google Summer of Code 2021](https://summerofcode.withgoogle.com/organizations/4961424868114432/). We look forward to mentoring engineering students through that technology internship program.\n\nIn addition to participating in these two great technology internship programs, GitLab held its first [engineering internship program](/handbook/engineering/internships/) in 2020 with great success. As a result, GitLab will continue to hire interns for various projects and teams in an ongoing fashion, with a specific [focus on recruiting interns from underrepresented groups in engineering](/handbook/engineering/internships/#recruitment).\n\nWe look forward to supporting these programs that help foster diversity in open source and the wider tech industry, and are excited for the year ahead!\n",[675,699,1666],"design",{"slug":1668,"featured":6,"template":679},"outreachy-sponsorship-winter-2020","content:en-us:blog:outreachy-sponsorship-winter-2020.yml","Outreachy Sponsorship Winter 2020","en-us/blog/outreachy-sponsorship-winter-2020.yml","en-us/blog/outreachy-sponsorship-winter-2020",{"_path":1674,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1675,"content":1681,"config":1687,"_id":1689,"_type":16,"title":1690,"_source":17,"_file":1691,"_stem":1692,"_extension":20},"/en-us/blog/how-the-open-source-community-can-build-more-accessible-products",{"title":1676,"description":1677,"ogTitle":1676,"ogDescription":1677,"noIndex":6,"ogImage":1678,"ogUrl":1679,"ogSiteName":713,"ogType":714,"canonicalUrls":1679,"schema":1680},"Making open source software more accessible for everyone","The open source software community is built on the idea that everyone can contribute, and that includes people living with disabilities. GitLab team members share their ideas for building more accessible, open source software.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667281/Blog/Hero%20Images/accessibility.jpg","https://about.gitlab.com/blog/how-the-open-source-community-can-build-more-accessible-products","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How the open source development community can build more accessible software\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2021-04-07\",\n      }",{"title":1682,"description":1677,"authors":1683,"heroImage":1678,"date":1685,"body":1686,"category":14},"How the open source development community can build more accessible software",[1684],"Sara Kassabian","2021-04-07","For [software to be considered open source](https://opensource.org/osd), it must not discriminate against any people, groups, or fields of endeavor. In other words, open source software must be available and accessible to all users, which includes people living with disabilities. In many ways, the open source community and technologists focused on accessibility are a natural pairing: The more accessible the product, the greater number of users benefit, and input from a diverse group of users is necessary to build a product that is truly accessible.\n\n\"A distinguishing feature of open source software versus proprietary software is that open source software tends to be used by a diverse community of users with different priorities, needs, use cases,\" says [Greg Myers](/company/team/#greg), support engineer at GitLab. \"I personally feel the more diverse and inclusive that community is, the better the end product is.\"\n\nEngineers that draw from the insights of the open source community when developing their software benefit from a broader set of inputs than those that work with a proprietary codebase. In many ways, the standards that define open source software overlap with the process of accessibility in software development.\n\n\"Accessibility aims to do the same thing, right? We want to make sure that as we're building software, we're building it with a diverse set of folks that are going to use it, and might want or need to use the technology in different ways,\" says [Brendan O’Leary](/company/team/#brendan), senior developer evangelist at GitLab.\n\n## Everyone can contribute to open source software\n\nThe greatest strength of the open source software community is the level of collaboration among a global set of users. [GitLab is an example of an open source software (OSS)](/solutions/open-source/) product that is continually fortified by the contributions of our community. Since [everyone can contribute](/company/mission/#mission) to improving our product, our team is exposed to many different ideas and perspectives.\n\n\"We're doing well because everybody can contribute to our mission,\" says Greg. \"If somebody has a feature request, a problem, or they find a bug – including if something's not accessible on our website, our documentation, or our software – they're invited to create an issue which will actually get passed along to our product team and get prioritized and acknowledged. Whereas that's not easily available in a lot of other companies and products.\"\n\n[Jeremy Elder](/company/team/#jeldergl) says that his work as a senior product desiger on the UX team at GitLab has benefitted from community contributions aimed at making GitLab features more accessible.\n\nAt GitLab, we have a few different [open source accessibility testing tools](/blog/introducing-accessibility-testing-in-gitlab/). We use [Pa11y](https://pa11y.org/), an open source accessibility tool, to [measure the accessibility of our website](https://docs.gitlab.com/ee/ci/testing/accessibility_testing.html). We also built a [simple CI job template that shares accessibility violations, warnings, and notices](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Verify/Accessibility.gitlab-ci.yml). One of the projects Brendan worked on before moving to the developer evangelist team was [building the accessibility merge request widget](https://docs.gitlab.com/ee/ci/testing/accessibility_testing.html), which creates an accessibility report.\n\n\"There's a lot that you can do with automated testing and there's a limit, but it's by examining those limits that I think we can continue to get better and improve,\" says Brendan. We will discuss accessibility testing more in an upcoming blog post.\n\n## How the OSS community can improve accessibility in software development\n\nDespite these good intentions, when it comes to building technology that is accessible to all, the open source community sometimes falls short.\n\n\"We've been painting a pretty nice picture of the open source community, and having folks involved and contributing to accessibility,\" says Brendan. \"But I also think that the inverse happens a lot in open source when a project is maybe not as mature or it's just starting out. And accessibility is one of many things that gets put on the backburner as an afterthought.\"\n\nAccessibility is not an unsolved problem in software engineering. [There are plenty of open source accessibility solutions out there](https://www.digitala11y.com/open-source-accessibility-tools/), it’s just a matter of making accessibility a priority.\n\nJeremy mentions two ways the open source community can make accessibility more of a priority: prioritizing user experience and shifting accessibility left.\n\n\"I don't feel like there's enough visibility from a design and UX standpoint in open source,\" says Jeremy. One thing that is unique about GitLab is that design and code work closely together, he says, although this is not typical in many open source communities that are more focused on code than UX.\n\nOftentimes, when open source communities are building developer tools, they will focus less on user experience and more on code. The number of users that are able to access the software will be limited if accessible design is not prioritized.\n\n\"You still want to be thinking through, 'how is this going to be usable by people that may come at the problem differently', or have a different set of needs when they're using the tool,\" says Brendan.\n\nAnother opportunity for developers is to bring accessibility into the DevOps process early. Greg notes that the Linux community does a good job of ensuring accessibility features are available for all users.\n\n\"It doesn't seem to matter what distribution you run, there is a screen reader built-in and there are accessibility features included in Linux,\" says Greg.\n\nIn a popular blog post on Opensource.com, Linux user Spencer Hunley shares [six reasons why people with disabilities should use Linux](https://opensource.com/life/15/4/6-reasons-people-disabilities-should-use-linux). One of those reasons is the ability to customize and modify Linux software to meet the needs of the user.\n\n\"Being able to take existing technology and adapt it to suit one's needs—rather than forcing a person to adapt to the device and/or software—is a strength of open source software and Linux, and is extremely important for those who rely on a device to accomplish what others take for granted every day,\" says Spencer.\n\nThe reality is, if accessibility testing were to be an assumed and automated component of the DevOps pipeline, it would be much easier to fix fundamental accessibility problems earlier in the development process.\n\n## Accessibility benefits everyone\n\nOne of the common misconceptions about accessibility is that it primarily benefits people with disabilities. In the United States, the 1990 Americans with Disability Act (ADA) lead to innovations like curb cuts, wheelchair ramps, and automatic doors, which were designed to help people with mobility issues navigate the physical world, but benefits everyone. Similarly, accessible software benefits users with different abilities as well as non-disabled users. While building software that complies with laws like the [ADA for Accessible Design](https://www.ada.gov/2010ADAstandards_index.htm) is legally mandated, accessibility is also about making software adaptable to meet the preferences of different users. For example, some users might prefer to use keyboard enhancements so they can work faster, or they [prefer to use different shortcuts or quick actions](/blog/improve-your-gitlab-productivity-with-these-10-tips/) to develop in [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/).\n\nIn the context of software, inclusive design is really all about intentionally considering and meeting the needs of people with different abilities and workflow preferences — which results in a more accessible product. For software to be truly open source, it ought to be built with accessibility in mind so everyone can contribute.\n\nWatch the video below to see our conversation about the overlap between the open source community and accessibility, and check back in with the blog to read more about accessibility.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/nuMTD_FZ_H8\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n\"I'd love to hear more from anyone who's using open source web accessibility tooling,\" says Brendan. He invites GitLab users to share their ideas for improving accessibility features for our product by [opening an issue](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/new) in the `www-gitlab-com` project, and adding the `accessibility` label. Tag any one of the GitLab team members mentioned in this article and they will help triage the issue. If you have ideas for how to make GitLab more inclusive, open an issue today, and check out the [resources Jeremy compiled to learn more about accessibility](https://jeldergl.gitlab.io/accessibility-cache/).\n",{"slug":1688,"featured":6,"template":679},"how-the-open-source-community-can-build-more-accessible-products","content:en-us:blog:how-the-open-source-community-can-build-more-accessible-products.yml","How The Open Source Community Can Build More Accessible Products","en-us/blog/how-the-open-source-community-can-build-more-accessible-products.yml","en-us/blog/how-the-open-source-community-can-build-more-accessible-products",{"_path":1694,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1695,"content":1700,"config":1706,"_id":1708,"_type":16,"title":1709,"_source":17,"_file":1710,"_stem":1711,"_extension":20},"/en-us/blog/how-you-contribute-to-gitlabs-open-devops-platform",{"title":1696,"description":1697,"ogTitle":1696,"ogDescription":1697,"noIndex":6,"ogImage":1655,"ogUrl":1698,"ogSiteName":713,"ogType":714,"canonicalUrls":1698,"schema":1699},"How you contribute to GitLab's DevOps Platform","Today we're celebrating you! These are just some of the many examples of how you make GitLab's DevOps Platform better by innovating together.","https://about.gitlab.com/blog/how-you-contribute-to-gitlabs-open-devops-platform","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How you contribute to GitLab's DevOps Platform\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2021-03-23\",\n      }",{"title":1696,"description":1697,"authors":1701,"heroImage":1655,"date":1702,"body":1703,"category":14,"tags":1704},[818],"2021-03-23","\n\nWe know that we can iterate faster when we innovate together. We want to highlight how you make GitLab better every day by contributing to our DevOps Platform, by suggesting improvements, submitting bug fixes, and contributing features. \n\nYou contribute around 300 merge requests to GitLab each month. Just look at [last month's release for a multitude of examples](/releases/2021/02/22/gitlab-13-9-released/#wider-community-contribution-highlights) – a reminder that [everyone can contribute](/company/mission/#mission). \n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">Achievement unlocked: having NASA contribute directly to your codebase. Open core ftw. \u003Ca href=\"https://t.co/qcnu8jhQuR\">https://t.co/qcnu8jhQuR\u003C/a>\u003C/p>— Brendan O’Leary (@olearycrew) \u003Ca href=\"https://twitter.com/olearycrew/status/1363992971188740103?ref_src=twsrc%5Etfw\">February 22, 2021\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\nRoger Meier, principal key expert and service owner of code.siemens.com from [Siemens IT](/customers/siemens/) explains, “If we want to have new features, we contribute them to GitLab.” \n\n## A DevOps platform gives you visibility into security and beyond\n\nWorking in the open presents unique security challenges (you can read about how we [prevent security fixes from leaking into our public repositories](/blog/how-we-prevented-security-fixes-leaking-into-our-public-repositories/)), but we’re proud of how taking an open approach to security serves our community, customers, and us.  \n\nCommunity member [Ethan Reesor](https://gitlab.com/firelizzard) is working on improving and simplifying how we do [authorization in our package managers](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38627) and added some great test coverage around that in [gitlab-org/gitlab!50729](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50729).\n\nSecurity issues are often reported to us directly in GitLab, but Dominic Couture, senior security engineer, [Application Security](/topics/devsecops/) at GitLab, explains that even security bugs reported through our [HackerOne bug bounty program](https://hackerone.com/gitlab) are often made public 30 days after they’re fixed: everyone can see the [old security issues](https://gitlab.com/gitlab-org/gitlab/-/issues?scope=all&utf8=%E2%9C%93&state=all&label_name[]=HackerOne). “This creates a positive feedback loop where external security researchers can look into old issues to help them find and disclose new ones to us.” You can read more reflections on [security and open source here](/blog/open-source-security/).\n\n### Debugging together\n\nOur customers regularly collaborate with us to debug problems. In this example, a customer helped our backend engineers to [resolve an S1 bug](https://gitlab.com/gitlab-org/gitlab/-/issues/261667), and even gave us access to part of their system to test the fix – showing that we’re most successful when everyone’s committed to iteration.\n\nSmall fixes and improvements to our documentation often arise out of customer interactions with our support engineers – you can see all the [merge requests from 2021 captured here](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues?label_name%5B%5D=Support+Team+Contributions).\n\nFor some customers, contributing to GitLab is even an official part of their job. Learn about how [one of our contributors at CERN here](/blog/cern-contributor-post/) helps make GitLab’s [open DevOps platform](/solutions/devops-platform/) better.\n\n### Getting to the root of performance problems\n\n[Working in public by default](https://handbook.gitlab.com/handbook/values/#public-by-default) is a little uncomfortable at first – especially when it comes to troubleshooting performance issues – but the advantage of this visibility is that we can crowdsource solutions. \n\nIn July 2019, our site reliability engineers noticed a significant increase in errors and site slowdown on GitLab.com. In the course of investigation, community member [Andrew Armstrong](https://gitlab.com/phplasma) [commented on the public issue ](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/928#note_187236004) with a suggestion: The Redis instance might be approaching its self-imposed memory limit, which can overwhelm the instance quickly even if plenty of physical memory is available. This inspired a review of the time to live (TTL) we apply to Redis keys.\n\n## Living our values through DevOps \n\nWe're proud to partner with groups who foster [our values](https://handbook.gitlab.com/handbook/values/) in their communities. [The Last Mile](/blog/thelastmile-gitlab/) is opening doors for aspiring software engineers at correctional facilities across the US. [GNOME moved to GitLab in 2018](/blog/welcome-gnome-to-gitlab/), and together with [Endless](https://endlessnetwork.com/) they [launched the Coding Education Challenge](/blog/gnome-follow-up/#whats-new-at-gnome-and-what-are-some-of-the-new-things-on-the-horizon) to inspire a new generation to \"take control of their digital worlds, not be controlled by them.\" Read more about intitiatives from our [friends in open source](/blog/categories/open-source/). \n\n_These are just a few examples of the improvements you make to GitLab and the wider community, and we want to keep celebrating how you iterate and innovate using our open DevOps platform. Got a story of your own to share? **We’re accepting proposals for our virtual user conference, [GitLab Commit](/events/commit/)** (Aug. 3-4, 2021) and would love to hear from you._\n",[675,268,1705],"DevOps platform",{"slug":1707,"featured":6,"template":679},"how-you-contribute-to-gitlabs-open-devops-platform","content:en-us:blog:how-you-contribute-to-gitlabs-open-devops-platform.yml","How You Contribute To Gitlabs Open Devops Platform","en-us/blog/how-you-contribute-to-gitlabs-open-devops-platform.yml","en-us/blog/how-you-contribute-to-gitlabs-open-devops-platform",{"_path":1713,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1714,"content":1720,"config":1726,"_id":1728,"_type":16,"title":1729,"_source":17,"_file":1730,"_stem":1731,"_extension":20},"/en-us/blog/kali-linux-movingtogitlab",{"title":1715,"description":1716,"ogTitle":1715,"ogDescription":1716,"noIndex":6,"ogImage":1717,"ogUrl":1718,"ogSiteName":713,"ogType":714,"canonicalUrls":1718,"schema":1719},"Kali Linux: Growing Community Contributions with GitLab","Since moving to GitLab in 2019, Kali Linux has gone from company-only contributions to a growing number of community contributions.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667243/Blog/Hero%20Images/open-source-community.png","https://about.gitlab.com/blog/kali-linux-movingtogitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab helped Kali Linux attract a growing number of community contributions\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nuritzi Sanchez\"}],\n        \"datePublished\": \"2021-02-18\",\n      }",{"title":1721,"description":1716,"authors":1722,"heroImage":1717,"date":1723,"body":1724,"category":14,"tags":1725},"How GitLab helped Kali Linux attract a growing number of community contributions",[1662],"2021-02-18","[Kali Linux](https://www.kali.org/) is a well-loved Debian-based Linux distribution aimed at advanced [Penetration Testing](https://en.wikipedia.org/wiki/Penetration_test) and Security Auditing. We sat down with Ben Wilson ([@g0tmi1k](https://twitter.com/g0tmi1k)), senior developer at Kali, to hear more about why Kali Linux moved to GitLab and see if they've noticed any changes to their project since adopting GitLab as their DevOps solution.\n\n## Why did you decide to move to GitLab?\n\nWe decided to move from Gitolite to GitLab around April 2019 to make it possible for our community to contribute to Kali. Our previous setup didn't allow anyone to sign up, so the community couldn't help out. Another complication was using a mixture of services such as Google Docs and Phabricator, and we wanted to condense our tool stack. We love that GitLab is a single platform for the whole software development lifecycle.\n\n>> One thing that was important for us is that we didn't want to reinvent the wheel. We tried to choose something open-source with advanced functionality, an active community, and a company behind it. GitLab ticked every box.\n\nAnother factor for our decision was that [GitLab's API is significantly more feature-rich than competitor APIs](https://docs.gitlab.com/ee/api/), which allowed us to automate and integrate into anything that we wanted. For example, we can fully automate the process of remotely forking a repository then apply our configurations.\n\nThat way, we don't have to download a git repository only to push it up again. This is a big time-saver for us and significantly simplifies the workflow. Some of the configuration that we can now automatically apply are:\n\n * Being able to drop the relationship between forks\n * Configure the default branch\n * Disable unused features for a repository (e.g., not everything requires their own wiki)\n * Populate a description for the repository\n * Set up CI paths\n * Set up email notification on any activity to our private mailing list\n\nWe take advantage of various open source tools that leverage GitLab's API, such as [Debian Salsa](https://www.phoronix.com/scan.php?page=news_item&px=Debian-Salsa-Beta). We can use these tools to automate things like updates to email distribution lists and our configuration of GitLab admin settings and repository structure. We contribute any changes we make to these tools back upstream so that other communities can leverage GitLab's API's power the way we do.\n\nAn additional perk to GitLab is its usability. The way you can organize projects makes it a more intuitive experience for people who want to contribute. For example, having sub-groups and projects allows us to keep a clean layout in a folder-like structure. For those interested, you can see how we've organized the [Kali project in GitLab](https://gitlab.com/kalilinux).\n\n## How are you using GitLab at Kali Linux?\n\nWe're using GitLab's [top-tier SaaS version](/pricing/), which is hosted on GitLab.com, thanks to the [GitLab for Open Source program](/solutions/open-source/). Using this version and hosting it on GitLab is easier for us because it's less infrastructure to maintain. We have many unique pieces of infrastructure so it's nice to reduce the load when we can. We're using a wide range of features to manage the entire Kali Linux project, consisting of 564 active repositories.\n\nSome of the most essential [GitLab features](/pricing/feature-comparison/) for us are:\n\n*   **Source Code Management**: We're using GitLab to host the source code to all our packages and build scripts and custom tools.\n*   **[Wiki](https://docs.gitlab.com/ee/user/project/wiki/#wiki)**: We use the wiki functionality for internal documentation. Markdown makes it easy for everyone to contribute.\n*   **[Project management](/solutions/agile-delivery/)**: We track tasks and short/long term goals with GitLab as well as the timelines for our project. We use issue tracking, threads, labels, milestones, weights, and everything else designed for project management.\n*   **[User Permissions](https://docs.gitlab.com/ee/user/permissions.html#permissions)**: We like the functionality of GitLab's user permissions, which allows us to have \"one-off\" users on specific projects as well as automatic expiration after a particular time.\n*   **[Security](https://docs.gitlab.com/ee/user/application_security/)**: As a cybersecurity-focused Linux distro, security is paramount to us. We like that [GitLab has 2FA and project access tokens](https://docs.gitlab.com/ee/security/).\n*   **[Analytics](https://docs.gitlab.com/ee/user/analytics/)**: We are still discovering the functionality here, but we like seeing user statistics around code review and contribution.\n*   **Performance**: We're able to use GitLab's [Content Delivery Network (CDN)](https://en.wikipedia.org/wiki/Content_delivery_network) for great performance across the globe.\n\nWe're hoping to leverage [GitLab's CI/CD features](/solutions/continuous-integration/) and the [container management capabilities](https://docs.gitlab.com/ee/user/packages/container_registry/) more regularly in the near future.\n\nWe're also looking to use [GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/) for hosting our website instead of our self-hosted WordPress instance. By using [Hugo](https://gohugo.io/hosting-and-deployment/hosting-on-gitlab/), we can write the content with a mixture of HTML and Markdown. Hugo makes it very simple, easy to update, and has straightforward change tracking. GitLab Pages then can serve up the [static output](https://docs.gitlab.com/ee/user/project/web_ide/index.html).\n\nThere were several problems we were facing with WordPress that made us consider moving away, such as plugins that weren't properly maintained, security issues that made us require VPN access to admin pages. The other benefits to the move are that static pages will load faster, and our community can help fix typos on our website through merge requests. Once we make the move to GitLab Pages, we'll start to make greater use of GitLab's CI/CD functions to statically generate the websites.\n\nAnother thing we're becoming more familiar with is all of GitLab's project management features. One of the reasons we chose GitLab instead of other DevOps tools is that it's a single platform for the whole software development lifecycle, and we're looking to use more of its features. Since we're on the top-tier SaaS plan, we have every functionality available to us and we're eager to make use of it.\n\n## What are some of the changes you've noticed in your open-source community since starting to use GitLab?\n\nThe most significant change is that we only allowed contributions from employees before moving to GitLab. Since the switch to GitLab, we've adopted a new mindset and now allow anyone to help out.\n\n>> GitLab's user-friendly design has made it easy for our community to get started, and we've started to receive merge requests from the public as well as bug reports and bug fixes.\n\nIt's been exhilarating to see these contributions land! We are working on increasing these contributions in 2021 with a \"Kali Summer of Code\" and are considering doing a giveaway for people who have made a significant contribution.\n\nWe've also experienced changes to our development practices. For example, we can now have more effective discussions about commit differences and can link to individual commits to pinpoint problems. It's easier to update items from the internal wiki, edit web pages, and merge requests. I also like that GitLab has a built-in automatic save feature to help when you're drafting something and either multitasking or on-the-go.\n\nFinally, GitLab's to-dos and long-term planning features allow us to plan ahead for the future of Kali development. For example, we've replaced ad-hoc solutions done by individuals via emails and to-do list text files on each person's computer since moving to GitLab.\n\n## What are some challenges you've had with implementing GitLab for your community? How did you overcome those challenges?\n\nDuring the switchover from the old system to GitLab, we discovered various things that were hardcoded.\n\nTo help with this, we automated a find and replace, and followed up with various manual searches to ensure that all links and references were located. This ended up taking about two hours. We also left the old web server up for a year, which pointed to the new URL structure to ensure that there weren't any missing links and references. We redid the layout of the site, so it took a while to recreate all the redirects.\n\nAnother challenge was the sheer size of Kali. We had to import roughly 1,000 repositories when we set up GitLab. We managed to migrate most of them in a day and completed the migration within a week once we managed to get the group structure in place. We set up separate groups for different access levels to repositories for build scripts, internal non-public files, Android, phone, build scripts, store, packages, recipes, tools, and websites.\n\nImporting other items (code packages, build scripts, and custom tools from our self-hosted git) took longer because they were in many different formats. When we did the import we cleaned up to determine which items were no longer in use and archived them. The next step was making sure our custom tools were hosted on GitLab and then configuring the tools and packages appropriately. Next, we imported several repositories. We also needed to create files that were not previously tracked in our repository. Finally, we converted our WordPress-based content to Markdown using an [open source project](https://github.com/lonekorean/wordpress-export-to-markdown), then manually verified and cleaned it up.\n\nWe chose not to carry over existing issues because we wanted to have a clean start. In general, we only imported what was important. Everything we ended up with is what we cared about and what we wanted to track.\n\n## What do you think GitLab is doing well in supporting open source communities, and what should GitLab do to improve in this area?\n\nWe really like that GitLab has an outreach program for open source projects with dedicated people for the job role. They actively contacted us to become a [GitLab Open Source Partner](/solutions/open-source/partners/) and we're glad to have joined as one!\n\nOne of the things that we appreciate about GitLab is that the company is open source. The transparency that comes with that allows us, and anyone else, to see the company's progress. GitLab is setting an example for how open source companies can work alongside their communities, and it's something we are learning from too.\n\n## What advice would you have for other open source communities that are looking to implement GitLab?\n\nThe sooner you make the switch, the easier and better! Once you move, you'll see that it's less work to maintain and there are more features to use.\n\nWhen beginning your migration, make sure to set up a test project first to help plan the structure ahead of doing the main project switch. Look up and explore features ahead of time so you know what GitLab can do rather than discover the functionality when using it. GitLab has a [GitLab Learn portal](/learn/), which we hear is going to continue to be improved to help with user education.\n\n## What are some of the new things on the horizon for Kali Linux?\n\n*   [KaBoxer](https://gitlab.com/kalilinux/tools/kaboxer): A framework to manage applications in containers on Kali\n*   New kali.org website using GitLab Pages\n*   Programs to increase community contributions to Kali\n\n## Is there anything else you'd like to share with us that we haven't asked you?\n\nWe have only scratched the surface of what GitLab has offered - and they keep putting in more features. We are planning on taking their upcoming training to make sure we are fully up-to-date on their offerings.\n\n## Last but certainly not least, we have heard a rumor that the founders of Kali are so dedicated to the project that they have Kali logo tattoos. Is this true?\n\nVery true! The original founders both have Kali tattoos, as do various current members.\n\nWe also have some pretty cute baby onesies that are a hit.\n\n![A baby in a Kali Linux onesie](https://about.gitlab.com/images/blogimages/kali_linux_baby.jpg){: .shadow.medium.center}\nKali Linux has some cute baby onesies. [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) Ben Wilson\n{: .note.text-center}\n\n## About Kali Linux\n\n[Kali Linux](https://www.kali.org/) (formerly known as BackTrack-Linux) is a Debian-based Linux distribution aimed at advanced Penetration Testing and Security Auditing. Kali Linux contains several hundred tools targeted toward various information security tasks, such as Penetration Testing, Forensics, and Reverse Engineering. Kali Linux is a multi platform solution, accessible and freely available to information security professionals and hobbyists.\n",[675,268,1583],{"slug":1727,"featured":6,"template":679},"kali-linux-movingtogitlab","content:en-us:blog:kali-linux-movingtogitlab.yml","Kali Linux Movingtogitlab","en-us/blog/kali-linux-movingtogitlab.yml","en-us/blog/kali-linux-movingtogitlab",{"_path":1733,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1734,"content":1740,"config":1745,"_id":1747,"_type":16,"title":1748,"_source":17,"_file":1749,"_stem":1750,"_extension":20},"/en-us/blog/q42020-hackathon-recap",{"title":1735,"description":1736,"ogTitle":1735,"ogDescription":1736,"noIndex":6,"ogImage":1737,"ogUrl":1738,"ogSiteName":713,"ogType":714,"canonicalUrls":1738,"schema":1739},"What happened at the Q4'2020 GitLab Hackathon","Here's a recap of GitLab community accomplishments during the Hackathon on Jan 6-7th of 2021.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663430/Blog/Hero%20Images/2018-09-13-gitlab-hackathon-cover.jpg","https://about.gitlab.com/blog/q42020-hackathon-recap","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What happened at the Q4'2020 GitLab Hackathon\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christos Bacharakis\"}],\n        \"datePublished\": \"2021-02-08\",\n      }",{"title":1735,"description":1736,"authors":1741,"heroImage":1737,"date":1742,"body":1743,"category":14,"tags":1744},[1620],"2021-02-08","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n\n\u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>  \nDisclaimer: Due to a [bug in our metrics platform](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/general/-/issues/59), that was identified a month after the release of this blogpost, we updated the post with accurate information about the number of MRs submitted, MRs merged, and the winners. In addition, we are not going to take into account the 15th of January as the date the MRs had to be merged to qualify, since we noticed a significant amount of delays in reviewing the MRs.\n  \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>\n{: .alert .alert-webcast}\n\nAnother GitLab hackathon is completed, and I would like to begin by celebrating our community contributions! Congratulations to everyone who participated and contributed to GitLab.\n\nThis time, participants managed to land 167 Merge Request, where 139 (83%) of them have already been merged across eight projects such as: GitLab, Omnibus, GitLab Development Kit, CNG, Runner and more.\n\n![Hackathon playlist](https://about.gitlab.com/images/blogimages/Hackathon_playlist.png){: .shadow.medium.center}\n\nDuring the Hackathon, a number of GitLab Team members ran a series of tutorial sessions around various GitLab Products, stages and groups like Runner, Release Stage, GitLab Pajamas, and Package Group. All of these sessions that are a resource for future contributions were recorded and can be found on our [YouTube Channel](https://www.youtube.com/playlist?list=PL05JrBw4t0KrqGydhkV_BUPrI-DBiDKfm).\n\nSomething unique about this Hackathon is that it happened two times. Originally it was scheduled to take place in December, around the time my onboarding was going to be completed; thus, we had to move it to the beginning of January. Our Tokyo community had already made arrangements for these dates, and with the lead of our Core Team member [Takuya Noguchi](https://gitlab.com/tnir), they successfully organized a [regional GitLab hackathon](https://gitlab-jp.connpass.com/event/189496/). \n\n\n## Hackathon prizes\n\nLike past events, everyone who had MRs merged will receive a token of our appreciation for their contribution. This time, [thirty seven people](https://gitlab.biterg.io/goto/2c0b5d1d60893bcec44dbfd11a16d947) had their MRs merged, where three of them had more than 10 MRs merged, which will receive the Second Prize.\n\nThe grand prize will go to both [Kev](https://gitlab.com/KevSlashNull) and [Jonston Chan](https://gitlab.com/JonstonChan) who had the highest number of merged MRs.\n\nBelow is a list of the top five contributors for this Hackathon, and all the MRs in the [Winder Community Hackathon MRs issue](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/-/issues/44#related-merge-requests).\n\n- Grand Prize: [Kev](https://gitlab.com/KevSlashNull), with 31 MRs merged\n- Grand Prize: [Jonston Chan](https://gitlab.com/JonstonChan), with 30 MRs merged\n- Second Prize: [Yogi](https://gitlab.com/yo), with 16 MRs merged\n- Second Prize: [Takuya Noguchi](https://gitlab.com/tnir), with 12 MRs merged\n- Second Prize: [Marvin Karegyeya](https://gitlab.com/nuwe1), with 10 MRs merged\n\n\n![Hackathon playlist](https://about.gitlab.com/images/blogimages/q4-hackathon-details.png){: .shadow.medium.center}\n\n## When is the next Hackathon?\n\nThe next Hackathon will occur on March 31st - April 1st, 2021 (yes, it's true!), and all the necessary information will be posted on the [Hackathon page by March 1st](/community/hackathon/).\n\n## How do I get started with contributing?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at cbacharakis@gitlab.com.\n\n[\"GitLab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel) on Unsplash\n{: .note}\n",[268,864,675],{"slug":1746,"featured":6,"template":679},"q42020-hackathon-recap","content:en-us:blog:q42020-hackathon-recap.yml","Q42020 Hackathon Recap","en-us/blog/q42020-hackathon-recap.yml","en-us/blog/q42020-hackathon-recap",{"_path":1752,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1753,"content":1759,"config":1766,"_id":1768,"_type":16,"title":1769,"_source":17,"_file":1770,"_stem":1771,"_extension":20},"/en-us/blog/thelastmile-gitlab",{"title":1754,"description":1755,"ogTitle":1754,"ogDescription":1755,"noIndex":6,"ogImage":1756,"ogUrl":1757,"ogSiteName":713,"ogType":714,"canonicalUrls":1757,"schema":1758},"Inside the collaboration between GitLab and The Last Mile","GitLab teamed up with The Last Mile to bring open source DevOps and tech mentorship to incarcerated populations across the United States.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681743/Blog/Hero%20Images/tlm-blogpost-banner.png","https://about.gitlab.com/blog/thelastmile-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Inside the collaboration between GitLab and The Last Mile\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christina Hupy, Ph.D.\"}],\n        \"datePublished\": \"2020-11-13\",\n      }",{"title":1754,"description":1755,"authors":1760,"heroImage":1756,"date":1762,"body":1763,"category":14,"tags":1764},[1761],"Christina Hupy, Ph.D.","2020-11-13","\n\n[The Last Mile (TLM)](https://thelastmile.org/), an organization focused on changing lives through technology, is tackling the daunting problem of mass incarceration in the United States by providing education and career training opportunities to incarcerated individuals to help break the generational cycle of incarceration. GitLab team members with similar passions and ideas connected with The Last Mile team and built a partnership to help bring the tech industry and mentorship directly to incarcerated individuals.\n\n## AMA to Coffee Chat to Partnership\n\nThe idea for TLM partnership originated during an AMA (or \"Ask Me Anything\" session) between GitLab CEO, [Sid Sijbrandij](/company/team/#sytses), and GitLab team members. [In one of these AMAs](https://www.youtube.com/watch?v=qi9zrymBO8o), [Tucker Logan](/company/team/#tuckcodes), a federal solutions architect at GitLab, asked Sid about the inspiration behind his [tweet](https://twitter.com/sytses/status/1227319454817804288) about mass incarceration. In a follow-up question, [Morgen Smith](/company/team/#msmith6), a sales development representative (SDR) for the Americas, asked Sid if GitLab would consider creating initiatives to help combat the school-to-prison pipeline.\n\nAs a former educator, Morgen has witnessed first-hand the national trend of disadvantaged youth being agressively disciplined in schools, which can then lead to juvenile offenses and later to formal charges. During the AMA, Morgen asked Sid: \"What do you think GitLab could do to encourage minority youth in this situation to be inspired by opportunities in tech?\" Sid shared his support and passion for the topic, and invited Morgen and Tyler to host an [open coffee chat](/company/culture/all-remote/informal-communication/#coffee-chats) on the topic to brainstorm ideas and next steps.\n\nDuring the coffee chat, Sid decided to take the smallest step, first. He visited San Quentin State Prison in San Rafael, Calif., and organized a call with Chris Redlitz, a co-founder of TLM. It turns out that TLM was using GitLab internally and also using the GitLab Community Edition to train nearly 300 students participating in their programs about how to use DevOps.\n\nTLM is a nonprofit program that started at San Quentin. TLM works with the incarcerated populations at men’s, women’s, and young adult correctional facilities to help them build relevant skills in technology with the goal of preparing individuals for successful reentry and building careers in business and technology. Today, TLM is in 23 classrooms across six states and has served 622 students since its inception.\n\n## TLM students learn DevOps with GitLab\n\nParticipants in TLM use the self-managed, free open core version of GitLab in their courses on Web Development. Each of the twenty individual classrooms have their own self-managed instance which around 20 students use to create and host their own private repositories. The sandbox environments are deployed centrally via Google Cloud. The core curriculum includes HTML/CSS and JavaScript, Node.js, Express.js, React.js, and Mongodb. GitLab is used primarily as a [source code management tool](/solutions/source-code-management/) for the students. Students write and commit code to personal repositories during course assignments. TLM Remote Instruction team also manages student-facing GitLab repositories to demonstrate industry best practices in merging, code collaboration, and version control platforms. Additionally, TLM leverages GitLab by providing students access to their repositories after they are released from prison, preserving commit history and all version control for the aspiring coders.\n\n\"By utilizing GitLab, The Last Mile students become comfortable using a best-in-class open source DevOps tool,\" says Tulio Cardozo, IT Manager, TLM. \"This experience empowers our students as aspiring software engineers, enabling them to enter the workforce with the collaboration and communication framework skills employers demand.\"\n\nThe GitLab team is partnering with the TLM Programs department to organize a series of webinars and workshops for the students. The first webinar kicked off in June of 2020 and was broadcast to 27 students (men, women, and youth programs), across four classrooms in several states. The topic was an introduction to GitLab and DevOps. Sid joined and shared the story of founding GitLab and his journey in tech. [Brendan O’Leary](/company/team/#brendan), a senior developer evangelist at GitLab, provided an overview of DevOps and explained how GitLab is the first single application for the entire DevOps lifecycle.\n\n\"The students appreciated the information on how to get started as new developers. Sid and Brendan helped the students believe they could accomplish anything with enough hard work,\" says a classroom facilitator from the Pendleton Youth Correctional Facility in Indiana.\n\nThe TLM team added that the webinar exposed students to a large company that works remotely and introduced them to an industry-recognized brand that the students use. In addition to the value of the content itself, there was a Q&A portion of the session where the studetns asked questions about the technology itself, such as how to start an open-source project and protecting intellectual property in open source, and about the facilitators' personal journey into tech.\n\nWatch the webinar with GitLab and TLM below.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/ejHmvMjXJVU\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nIn addition to the general workshop, the teams also collaborated on more technical content. The students at the Pendleton Juvenile Correctional Facility had a very special guest visit their [Web Development Fundamentals Course](https://thelastmile.org/our-work/), [Natalia Tepluhina](/company/team/#ntepluhina). Natalia, who currently lives in the Ukraine, is a frontend engineer at GitLab and also serves as a [core Vue.js team member](https://vuejs.org/v2/guide/team.html) and [core team member](/community/core-team/) of GitLab itself. Natalia answered a variety of questions about how to approach learning Javascript and provided a few demos related to specific questions from the students.\n\n## Mentorship for a career in DevOps\n\nGitLab and TLM also partnered on a series of Technical recruiting workshops with the classrooms. These have definitely been one of the highlights of the partnership thus far. In these workshops, a GitLab recruiter gave a presentation on the technical recruiting processes at GitLab, best practices during the application process and interview process, as well as an overview of what to expect during an interview. During each of the four sessions, the recruiters directly engaged with the participants, who asked a variety of questions, including:\n\n* How do I address incarceration on my resume?\n* What about background checks?\n* How do I gain professional experience while incarcerated?\n\nThe GitLab recruiting team was very sensitive to the participants' concerns and provided honest, clear answers, and great suggestions. The recruiters shared that during the process candidates should think of their recruiter as a resource, and they can always ask to speak to the People team at GitLab in confidence if it would help reassure them with any concerns they have regarding their criminal records. The recruiters encouraged the students to highlight their work in TLM courses on their resume and think about whether they can use course projects to start to build a portfolio. In addition, the facilitators encouraged participants to think about contributing to open source projects as a way to build technical skills, increase their network and mentorship opportunities.\n\n## How can open source help incarcerated populations gain experience in tech?\n\nThe discussion around contributing to open source projects as a way to build technical skills sparked a few different exciting ideas with the teams. One of these ideas was to hold a first time contributor workshop with alumni from TLM. The workshop was held in September 2020 had 16 alumni participants, four GitLab team members, including Sid, and five TLM team members. The workshop covered the basics on how to contribute to GitLab and demonstrated the step-by-step process. Participants were [provided an issue](https://gitlab.com/gitlab-org/gitlab/-/issues/247284) with a list of simple fixes with the label [\"good-for-new-contributors\"](https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=good+for+new+contributors) in the GitLab docs or handbook with typos or other minor changes. We had a few merge requests after just a few hours of the workshop! Participants were encouraged to tag GitLab team members for recognition and to win a pair of tanuki socks – by the end of the week we had given away six pairs of socks.\n\nParticipants and instructors appreciated the opportunity to learn in a hands-on way during the workshop:\n\n\"Thank you for the opportunity to participate in the GitLab workshop. I am so grateful to the GitLab staff for taking the time to introduce those of us who are new to GitLab to the history and functionality of the company. I learned so much, not just about how I can utilize GitLab to accomplish personal tasks more efficiently, but also how I can contribute and collaborate more with others and contribute to my local and global communities.\" - TLM staff and alumna.\n\nThe GitLab team found the experience equally rewarding. \"Working with The Last Mile was such a rewarding experience! When I think about how our product takes in contributions from all over the world and knowing it is also leveraged by those currently and or previously incarcerated really shows how truly 'inclusive' Git can be. Additionally, the empowerment it offers and the gift of knowledge and skill that can't be taken away is invaluable,\" says [Candace Brydsong Williams](/company/team/#cwilliams3), manage of the Diversity, Inclusion and Belonging program at GitLab.\n\n## How TLM uses GitLab technology\n\nGitLab also provides free licenses of our top-tier hosted application for the TLM team, who use our DevOps technology in nearly every aspect of their operations.\n\nTLM transitioned from GitHub to GitLab in 2019 after we provided the licenses. Initially, GitLab was used primarily in TLM's engineering department to track all internal processes with issues and Wikis. Infrastructure as code data and internal information is stored in repositories. Soon, TLM adopted GitLab technology in their education and programs departments, where it is now being used for project management. TLM now uses sprint planning, milestones, issues, priority levels, burndown charts, and issues boards to streamline project management across their departments.\n\nThe Last Mile has introduced numerous new and distinct use cases for GitLab. These include:\n\n* Issues are used to manage classroom facilities including to keep track of the impacts of COVID-19 on each classroom. For example, status updates are recorded on the issue and in the comments.\n* [The Last Mile’s reentry program](https://thelastmile.org/our-work/#reentry) uses GitLab to track returned citizen onboarding and service delivery process as well as tracking internal workloads, task efforts, and collaboration across teams. To-do lists are used to manage actions and labels are used to view the status of various efforts.\n\n\"The GitLab platform provides The Last Mile with a remarkable range of solutions -- from our application of GitOps workflows for managing our hybrid infrastructure, to our org-wide application of issues across teams,\" says Mike Bowie, Director of Engineering, The Last Mile. \"By solving such a broad range of our needs, GitLab enables us to focus on delivering value into our programs, instead of administering and maintaining a plethora of disparate tools.\"\n",[675,1583,864,1765,1000],"inside GitLab",{"slug":1767,"featured":6,"template":679},"thelastmile-gitlab","content:en-us:blog:thelastmile-gitlab.yml","Thelastmile Gitlab","en-us/blog/thelastmile-gitlab.yml","en-us/blog/thelastmile-gitlab",{"_path":1773,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1774,"content":1780,"config":1786,"_id":1788,"_type":16,"title":1789,"_source":17,"_file":1790,"_stem":1791,"_extension":20},"/en-us/blog/integrating-with-gitlab-secure",{"title":1775,"description":1776,"ogTitle":1775,"ogDescription":1776,"noIndex":6,"ogImage":1777,"ogUrl":1778,"ogSiteName":713,"ogType":714,"canonicalUrls":1778,"schema":1779},"How open source contributions accelerate GitLab Secure","Community contributions and an open integration framework allows anyone to extend GitLab Secure","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668622/Blog/Hero%20Images/group-rowing-collaboration.jpg","https://about.gitlab.com/blog/integrating-with-gitlab-secure","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How open source contributions accelerate GitLab Secure\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Taylor McCaslin\"}],\n        \"datePublished\": \"2020-10-22\",\n      }",{"title":1775,"description":1776,"authors":1781,"heroImage":1777,"date":1783,"body":1784,"category":14,"tags":1785},[1782],"Taylor McCaslin","2020-10-22","\nWhen you think about security you probably imagine locks, gates, and closed systems. This is the more traditional approach to security but modern security is much more open and collaborative. If you want to build the most secure systems, there is nothing better than building those systems in the open. Open security practices allow you to get fast feedback from a broad audience with diverse perspectives, helping you build better more holistic solutions. That's our approach to building [GitLab Secure](/stages-devops-lifecycle/secure/) at GitLab. We're leveraging amazing open source security projects, the collective contribution of the wider community, and providing an open integration system for anyone to build on top of GitLab security scanners.\n\n## Shifting left\n\nTraditional security approaches are opaque and late in the development life cycle. Security scans are performed by isolated security experts long after developers write code, often after it's deployed to production. GitLab aims to make security an integrated and continuous process. That's why we've built [GitLab Secure directly integrated into the DevOps life cycle](/solutions/security-compliance/). We are taking security tools and \"shifting left\" to make these tools more accessible to developers earlier in the development life cycle and integrated directly into developers' workflows.\n\n![Traditional Security vs DevSecOps with GitLab](https://about.gitlab.com/images/blogimages/traditional-security-vs-integrated.png)\n\nWe created a detailed survey to learn more about the [2020 DevSecOps Landscape](/developer-survey/#security). The results of the survey indicated that security is still a significant hurdle for most organizations that use DevOps, and show:\n\n- Only 13% of companies give developers access to the results of [application security](/topics/devsecops/) tests\n- Over 42% said testing happens too late in the lifecycle\n- 36% reported it was hard to understand, process, and fix any discovered vulnerabilities\n- 31% found prioritizing vulnerability remediation an uphill battle\n\nThese statistics illustrate why we are building security scanning directly into GitLab with our Secure features. We want to provide integrated security tools to broaden access and make it easier for everyone using GitLab to write more secure code.\n\n## Integrating security tools into everyday workflows\n\nGitLab Secure enables accurate, automated, and continuous assessment of your applications and services, allowing users to proactively identify vulnerabilities and weaknesses to minimize security risk. Secure is not an additional step in your development process nor an additional tool to introduce to your software stack. It is woven into your DevOps cycle, which allows you to adapt security testing and processes to your developers (and not the other way around).\n\nToday [GitLab Secure](/stages-devops-lifecycle/secure/) offers support for a variety of security scanning tools including:\n- [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)\n- [Dynamic Application Security Testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/)\n- [Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/)\n- [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)\n- [License Scanning](https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html)\n- [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/)\n- [API Fuzzing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/)\n- [Coverage Fuzzing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/)\n\nAll of these tools provide unique approaches to finding security problems. No one tool is best at everything, so we wanted to provide a way to leverage many tools in an integrated way, so you're always getting the most relevant security results. Take a look at how GitLab Secure integrates all these tools into common developer workflows on GitLab:\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/XnYstHObqlA\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## Democratizing security\n\nWith GitLab Secure, we've laid the foundation for bringing security tools directly into developers' workflows. At GitLab, we believe in a world where [everyone can contribute](/company/culture/#everyone-can-contribute). [Collaboration](https://handbook.gitlab.com/handbook/values/#collaboration) and [transparency](https://handbook.gitlab.com/handbook/values/#transparency) are part of our core values. This approach changes the way we build security features. That's why as part of our [community stewardship promise](/company/stewardship/#promises) we've made all our open source based [SAST scanners available for all users](/releases/2020/08/22/gitlab-13-3-released/#sast-security-analyzers-available-for-all), we offer [open source projects and nonprofits free access to our best features](/solutions/open-source/join/), and we've created a [security scanner integration framework](https://docs.gitlab.com/ee/development/integrations/secure.html) to allow anyone to contribute security scan tools. Our entire [product strategy and vision](/direction/secure/) is also open source, so everyone can understand our vision for an integrated, accessible, and democratic approach to security. Together we can build a more open and modern security approach that helps developers everywhere write more secure code.\n\n## Integrate with GitLab Secure\n\nOut of the box, GitLab provides a variety of pre-integrated and actively managed open source security tools, such as [SAST's 16 analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) that all support automatic language detection to always run the most relevant security tool. While GitLab will continue to update and build first-party integrations we wanted to ensure that GitLab contributors and integration partners could easily extend GitLab Secure for third-party tools. Our [open integration framework](https://docs.gitlab.com/ee/development/integrations/secure.html) makes it easy for anyone to leverage all of the [features of GitLab Secure](/pricing/feature-comparison/) with any scanning tool they may want to integrate. You can see all the tools GitLab users have requested support for and even add your own request in our [tracking epic](https://gitlab.com/groups/gitlab-org/-/epics/297).\n\n## Community contributions\n\nWith our open integration framework we've seen members of the [GitLab community](/community/) contribute additional security scanners, help maintain the existing open source scanners we offer and expand the list of supported languages and frameworks we support. Our community contributors are helping every GitLab user have access to more accurate, sophisticated, and relevant security results. Here are some recent community contribution highlights:\n\n- [Mobile SAST support via MobSF](https://gitlab.com/gitlab-org/gitlab/-/issues/233777) (contribution by [@williams.brian-heb](https://gitlab.com/williams.brian-heb)) - [GitLab 13.5 Release MVP](/releases/2020/10/22/gitlab-13-5-released/#mvp)\n- [Adding Helm Chart support](https://gitlab.com/gitlab-org/gitlab/-/issues/36755) (contribution by [@agixid](https://gitlab.com/agixid))\n- [Performance improvements to Fuzz testing](https://gitlab.com/gitlab-org/security-products/analyzers/fuzzers/pythonfuzz/-/merge_requests/1) (contribution by [@jvoisin](https://gitlab.com/jvoisin))\n- [Updates to secret detection](https://gitlab.com/gitlab-org/gitlab/-/issues/205172) (contribution by [@tnir](https://gitlab.com/tnir))\n- [Dependency scanning buxfixes](https://gitlab.com/gitlab-org/gitlab/-/issues/205172) (contribution by [@fcbrooks](https://gitlab.com/fcbrooks))\n- [Updates to Security Scanner underlying operating systems](https://gitlab.com/gitlab-org/gitlab/-/issues/216781) (contribution by [@J0WI](https://gitlab.com/J0WI))\n- [Contributions for .NET Framework Support](https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan/-/merge_requests/14) (contribution by [@agixid](https://gitlab.com/agixid))\n- [See the full list of Secure community contributions](https://gitlab.com/gitlab-org/gitlab/-/issues?scope=all&utf8=%E2%9C%93&state=all&label_name[]=Community%20contribution&label_name[]=devops%3A%3Asecure)\n\nThe open source nature of GitLab allows the community to help improve, maintain, and contribute features within GitLab. This is the ultimate value of open source. Even if we don't offer something, you can always extend or modify the behavior of GitLab to accomplish your goal. When compared to closed-source Security vendors, this is a huge benefit. The impact these contributions have is massive as GitLab Secure is used by tens of thousands of customers and performs hundreds of thousands of security scans every month. If you are interested in contributing, check out our [contributor program](/community/contribute/) and [contributor documentation](https://docs.gitlab.com/ee/development/contributing/).\n\n## Integration partners\n\nCommunity contributions aren't the only way GitLab Secure is being extended. We have a variety of integration partners who provide security integrations that further expand the suite of security tools available to GitLab users. Check out the [GitLab Security integrations](/partners/#security) our partners offer. If you are a security vendor interested in integrating with GitLab, [join our partner program](/handbook/alliances/integration-instructions/) today.\n\n## Looking ahead\n\nWe've come a long way in the past few years with GitLab Secure and we're not done yet. Our [vision is bold (and open source)](/direction/secure/) and [our investment in security is large](https://internal.gitlab.com/handbook/product/investment/). [Security is a team effort](/direction/secure/#security-is-a-team-effort) and we hope you'll join us on our mission to help developers write more secure code.\n\n## Read more about GitLab SAST:\n\n* GitLab [Secure Direction](/direction/secure/)\n* Learn more about [integrating with GitLab Secure](https://docs.gitlab.com/ee/development/integrations/secure.html)\n* View the latest [October 2020 GitLab security trends](/blog/gitlab-latest-security-trends/)\n\nCover image by [Mitchell Luo](https://unsplash.com/@mitchel3uo) on [Unsplash](https://unsplash.com/s/photos/rowing-team)\n{: .note}\n",[110,1434,843,268,865,675],{"slug":1787,"featured":6,"template":679},"integrating-with-gitlab-secure","content:en-us:blog:integrating-with-gitlab-secure.yml","Integrating With Gitlab Secure","en-us/blog/integrating-with-gitlab-secure.yml","en-us/blog/integrating-with-gitlab-secure",{"_path":1793,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1794,"content":1800,"config":1805,"_id":1807,"_type":16,"title":1808,"_source":17,"_file":1809,"_stem":1810,"_extension":20},"/en-us/blog/gnome-follow-up",{"title":1795,"description":1796,"ogTitle":1795,"ogDescription":1796,"noIndex":6,"ogImage":1797,"ogUrl":1798,"ogSiteName":713,"ogType":714,"canonicalUrls":1798,"schema":1799},"GNOME: two years after the move to GitLab","Extensive CI/CD adoption and easier contributions are just a couple of the benefits of #movingtogitlab for GNOME.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671276/Blog/Hero%20Images/gitlab-gnome.png","https://about.gitlab.com/blog/gnome-follow-up","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GNOME: two years after the move to GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nuritzi Sanchez\"}],\n        \"datePublished\": \"2020-09-08\",\n      }",{"title":1795,"description":1796,"authors":1801,"heroImage":1797,"date":1802,"body":1803,"category":14,"tags":1804},[1662],"2020-09-08","\n\n_It's been a little over two years since the [GNOME project moved to GitLab](/blog/welcome-gnome-to-gitlab/). We wanted to check in to see what’s happening at GNOME these days and see if they had noticed an impact from their migration on their community and their software development lifecycle. To find out the latest, we spoke with [Carlos Soriano](https://www.linkedin.com/in/carlos-soriano-sanchez-4b361240/) and [Sri Ramkrishna](https://www.linkedin.com/in/sriram-ramkrishna/) from GNOME and combined their responses._ \n\n### How are you using GitLab at GNOME? \n\nGNOME is using GitLab’s [Community Edition](/install/ce-or-ee/), which is entirely open source.\n\nAll teams at GNOME have been using GitLab for over a year, including non-coding teams like engagement and design, and the board of directors. The GNOME Foundation’s staff is also using GitLab for things like grant writing and running the foundation. \n\nGNOME is using most features that GitLab has to offer, such as [CI/CD](/topics/ci-cd/) for testing, issue tracking, kanban boards, and labels. Labels and CI/CD are two of the most important features being used across the entire organization. \n\nIn addition to this, GNOME is using GitLab Pages for some of the landing pages for projects, and also to host documentation.\n\nThe only team that hasn’t fully been able to use GitLab is the GNOME translation team since they need a different set of permissions and roles than GitLab provides. For them, Bugzilla was more flexible, and so some of their workflow is still there and in other tools. However, they are using GitLab for issue tracking and coordination. \n\nHere's how [GNOME has set up its GitLab instance](https://gitlab.gnome.org/explore/groups).\n\n### What are some of the changes that you’ve noticed in your community? \n\nThe perception at GNOME is that the move to GitLab has made it easier for people to contribute to GNOME. \n\nOne noticeable difference is that a lot of people are now using the GNOME GitLab instance to host their own projects that are somehow related to GNOME but aren’t part of the core software produced by GNOME. This has increased GNOME’s developer community. \n \nAnother noticeable difference in the community is that, since moving to GitLab, there is more awareness around what CI/CD is and how important it is to the development process. CI/CD is being used extensively throughout the project. \n\nThere is now also more transparency at GNOME, which is both a blessing and a curse. More people from the wider community are able to see what’s happening in the development cycle, and are chiming in on issues and merge requests.  This has caused friction at times when things like designs were picked up by the wider community that weren’t ready for comments. \n\nUnfortunately, GNOME does not currently have metrics to share about the changes they’ve seen within their community; however, the overall sentiment has been positive towards the move to GitLab. GNOME is on the path to being a more data-driven organization than it has been in the past, and hopes to share more concrete data in the future. \n\n### What are some of the changes in GNOME’s software development lifecycle?\n\nThe biggest change in GNOME's software development lifecycle is that they can now build images for testing pipelines, something that couldn't be done before moving to GitLab. In the future, they hope to allow people to preview upcoming releases. \n\nDespite the positive changes in testing practices due to the move to GitLab, QA and wider community testing are still challenges for GNOME. (To be fair, GitLab's Global 2020 DevSecOps Survey found [QA/test remain challenging for everyone.](/developer-survey/)) Coordinating teams and members within a large free software project like GNOME is similar to doing so at a large commercial organization -- mostly around coordinating milestones and features spanning multiple teams. This means that GNOME has to hack around the limits of the GitLab Community Edition with homegrown tools.\n\nAnother big change to GNOME’s software development lifecycle is that there is now a closer relationship between designers and maintainers because there is more transparency on what the design team is doing.  \n\nThe move to GitLab has also shortened the cycle for developing [Flatpak](https://flatpak.org/), a software deployment and package management technology created by members of the GNOME community. The community can now automatically build Flatpak bundles and test changes against those instead of committing things to code. This shortens the feedback for QA, design, and releasing the software. \n\n### What do you think GitLab is doing well in supporting open source communities and what else would you like to see?\n\nOne of the things that GNOME appreciates most about GitLab is its transparency. It helps to know the roadmap and see what is being worked on in order to form proper expectations and plan ahead. \n\nGNOME is also happy that GitLab is continuing to grow its Developer Relations team and has invested in hiring an open source program manager. They are encouraged that GitLab now has a dedicated resource to understand the specific needs of open source communities on GitLab and craft a strategy to enable growth in this segment.\n\nUsing the Community Edition adds some challenges for open source communities since they often have to ask for features to be ported down. There are common features that are important to a lot of open source projects and communities and it is important to identify those and port them down. Having someone who can start conversations around these features is important. \n\nAnother area of opportunity for GitLab is to foster a closer relationship between the GitLab team and the community. GNOME would find it especially helpful to get to know GitLab engineers and product managers, in order to feel more comfortable collaborating with them. \n\nWhile there is more work to be done on this, GitLab is actively taking this feedback into account and is rolling out changes to the [GitLab forum](https://forum.gitlab.com/). Instead of being just a place to ask technical questions and find answers, there will soon be more of a social component as well.\n\n### What kind of organizations would you recommend GitLab for?\n\nLarge open source organizations that require coordination among various contributors will benefit from using GitLab. The project or organization doesn’t have to be super big, but when you have 20-40 people, or if your project is something that the industry depends on, GitLab is a great choice due to its features that enable project management, issue tracking, and CI for testing. \n\nAlso, if you’re into open source software, then GitLab is your best option from a feature to feature comparison. \n\n### What’s new at GNOME and what are some of the new things on the horizon?\n\nGNOME is continuing to invest in expanding its contributor base. Not only are they working on initiatives to improve and scale newcomer onboarding, but they are also hosting a [Community Engagement Challenge](https://www.gnome.org/news/2019/08/gnome-foundation-launches-coding-education-challenge/), along with Endless, to get a younger generation into open source. The Challenge has multiple stages and includes over $65,000 USD in cash and prizes. Phase One winners were recently announced at this year’s [GUADEC](https://events.gnome.org/event/1/), GNOME’s annual core conference. \n\nThis year’s GUADEC was done remotely due to the pandemic and was a huge success! If you missed it, be sure to check out the [GUADEC YouTube channel](https://www.youtube.com/user/GUADEC/) for videos of the talks. Coming soon will be the annual [GNOME.Asia Summit](https://www.gnome.asia/), and the [Linux App Summit](https://linuxappsummit.org/), which will be co-hosted again with [KDE](https://kde.org/). GNOME also hopes to hold a first-ever Pan African GNOME Summit (PAGS) in the upcoming year. \n\nFrom a technical standpoint, GNOME is trying to remove their over-reliance on mailing lists by using GitLab projects instead. The release team now makes “freeze break” requests in a GitLab project, and the security team uses a web form that opens a confidential issue in a GitLab project through the GitLab Service Desk feature.\n\nAfter enthusiastically adopting CI pipelines, GNOME projects are now trying to optimize their workflows to minimise time spent, bandwidth, and energy consumption.\n\nLast but not least, some GNOME members are working on implementing community health metrics in order to evolve into a more data-driven organization. The [App Ecosystem working group at CHAOSS](https://chaoss.community/participate/) was founded earlier this year as a result, and includes members from GNOME and KDE, among others. New members are encouraged to join!\n\n",[268,675,865],{"slug":1806,"featured":6,"template":679},"gnome-follow-up","content:en-us:blog:gnome-follow-up.yml","Gnome Follow Up","en-us/blog/gnome-follow-up.yml","en-us/blog/gnome-follow-up",{"_path":1812,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1813,"content":1819,"config":1824,"_id":1826,"_type":16,"title":1827,"_source":17,"_file":1828,"_stem":1829,"_extension":20},"/en-us/blog/welcome-kde",{"title":1814,"description":1815,"ogTitle":1814,"ogDescription":1815,"noIndex":6,"ogImage":1816,"ogUrl":1817,"ogSiteName":713,"ogType":714,"canonicalUrls":1817,"schema":1818},"Why the KDE community is #movingtogitlab","Open source software community giant KDE finished phase one of their migration to GitLab and has joined our GitLab open source program. Check out what's next for KDE and GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681382/Blog/Hero%20Images/migratingbirds.jpg","https://about.gitlab.com/blog/welcome-kde","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why the KDE community is #movingtogitlab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nuritzi Sanchez\"}],\n        \"datePublished\": \"2020-06-29\",\n      }",{"title":1814,"description":1815,"authors":1820,"heroImage":1816,"date":1821,"body":1822,"category":14,"tags":1823},[1662],"2020-06-29","\n\nThe [KDE community](https://kde.org/) is [#movingtogitlab](https://twitter.com/hashtag/movingtogitlab)! After announcing the original decision to migrate to GitLab in November 2019, KDE has officially completed phase one of their migration, and contributors have begun to use GitLab on a daily basis at invent.kde.org. Read on to learn more about KDE's migration story.\n\n## About KDE\n\nKDE is an international community that creates open source software for desktops and mobile devices. KDE software is compatible with multiple platforms, including GNU/Linux, FreeBSD, Windows, macOS, and Android. Their products are used by millions of home and office workers and are being deployed in schools around the world.\n\nWith more than 2,700 artists, designers, programmers, translators, writers, and other contributors from across the globe, the KDE community is thriving.\n\nTogether, this community creates and maintains more than 200 applications and countless add-ons, plugins, and Plasmoids, 1000+ repositories, 80+ frameworks for Qt developers, and more than 2,600 projects. KDE software is translated into more than 100 languages to enable vast global reach.\n\n## Why KDE moved to GitLab\n\nOne of the main reasons that KDE decided to move to GitLab is to improve the newcomers story and make it easier to start contributing to KDE software. As [Aleix Pol](https://ev.kde.org/corporate/board/), President of KDE e.V says, \"Adopting GitLab has been a natural next step for us. Simplifying the onboarding experience for new contributors is one of our main goals in the KDE community. Being able to allow project contributors to easily participate in how the products they maintain are tested and delivered will certainly be a turning point for our ecosystem.\"\n\n\"By using a platform offering an interface and workflow that most open source developers are nowadays familiar with, we are confident that we are lowering the bar for new contributors to join us, and are providing the foundation for our community to scale in the following years,\" added [Neofytos Kolokotronis](https://ev.kde.org/corporate/board/), member of KDE e.V.'s Board of Directors and a core member of KDE's Onboarding team.\n\nAnother important consideration for the KDE community was to move to a product that was well-supported and where feedback from the community would be taken into account. With a release every month, GitLab has fast-paced development and is actively maintained by the company and community alike. Community members help to shape the way the product is built, and there's an [open roadmap](/direction/) since [transparency is one of GitLab's core values](https://handbook.gitlab.com/handbook/values/#transparency).\n\nMoving to new tools is a lot of work for established communities like KDE. Migration decisions require careful communication and the complex task of gathering community consensus.\n\nThe KDE team made the decision to migrate away from its [former tech stack](https://gitlab.com/gitlab-org/gitlab/-/issues/24900#gitlab-replacements) after following a series of carefully designed steps. First, they talked to the sysadmin team and then formed a migration team to evaluate the move. Next, the sysadmin team completed a thorough study of GitLab's features and did an intake and comparison of the community's needs against those product features. Then, they created a process that allows KDE to run short test cycles with some projects, document the process, and provide feedback to the community.\n\nThe migration started by moving some smaller and more agile KDE teams that were very interested in testing and providing feedback. After this cycle was completed successfully, KDE started migrating teams with a larger codebase and more contributors. Once all of the major issues were resolved, they made the final switch for all remaining projects they planned to move. The sysadmin team documented the results after each step and shared them directly with the KDE community to receive feedback and gather consensus on how to proceed.\n\nAs the switch to GitLab fell directly under the scope of KDE's [\"Streamlined Onboarding of New Contributors\" goal](https://community.kde.org/Goals/Streamlined_onboarding_of_new_contributors), the KDE Onboarding team was also involved from the start, working very closely with the sysadmin team, who were leading the effort. The community was involved in the decision-making from the beginning, and stayed up-to-date on each phase of the migration, and all questions and concerns were answered and addressed along the way.\n\n\"This was a major change for us, but we are very satisfied with how our community collaborated over long discussion threads. We believe that by working together we made the best decisions as we moved forward,\" says Neofytos.\n\n## Migration challenges and solutions\n\nThe biggest challenge for KDE was the sheer volume of data they were dealing with and how it was integrated into the numerous tools in use (including [Phabricator](https://www.phacility.com/phabricator/)). With more than 1,000 repositories, this migration was a big undertaking.\n\nTo address this challenge, KDE decided to approach the migration in phases rather than do it all at once. By phasing the migration, they were able to deal with different data types, such as repositories and tasks, separately.\n\nKDE developed custom tools to make bulk updates easier throughout the migration process. These tools help set the name, description, and avatar of the projects alongside a number of settings, for example, protected branches, and merge methods. By using these custom tools for bulk updates, KDE was also able to avoid granting maintainer access to individual contributors. KDE only allows maintainer access for sysadmins per their access and permissions policy.\n\nKDE ported custom Git hooks to ensure that certain checks and actions continued after the move to Gitlab. These include checks to ensure file encodings match KDE requirements and that bugs on their Bugzilla installation were closed as needed.\n\nIn order to support their translation community, which still uses Subversion in their workflow, KDE also built tooling to export SSH keys from GitLab to avoid the need to update these in two places.\n\nKDE also adjusted the tools used to build and develop KDE software to make them compatible with the new repository structure in GitLab.\n\nAt this point, KDE overcame most of their migration hurdles. Once the preparation work was finished to clean up a number of systems to work more natively with GitLab, the actual migration took about one day.\n\nBut there are a few more challenges left before KDE can transition continuous integration (CI) and task management over to GitLab. To follow along with the KDE migration, you can take a look at the [list of issues that KDE is tracking](https://gitlab.com/gitlab-org/gitlab/-/issues/26581).\n\n## Architectural decisions\n\nA common challenge for organizations moving to GitLab is deciding how to structure their groups to best enable their community's workflows and allow them to abide by their policies.\n\nKDE decided to tackle this challenge by setting up a series of groups at the top level of GitLab to act as categories. KDE's 1,200 repositories were then sorted into each of these categories.\n\nKDE formed this architectural strategy to help make projects more discoverable. KDE wanted to avoid the impracticality of people needing to scroll endlessly through repositories. Setting up top-level categories also allows developers to get an easier overview of merge requests for the categories they are most interested in.\n\nWith regards to permissions, KDE uses a single master \"KDE Developers\" group to manage membership and permission levels. Everyone there is given \"Developer\" access. This group is then invited to all of the groups containing repositories except for the ones containing the KDE website and infrastructure repos. This method of dealing with permissions allows KDE to maintain a single source of truth.\n\n## GitLab + KDE = ❤️\n\nKDE is using the [Community Edition](/install/ce-or-ee/) of GitLab because of their commitment to open source. They are a member of our [GitLab for Open Source](/solutions/open-source/) program, and have been actively collaborating with GitLab team members throughout the migration. One of benefits of using the GitLab for Open Source program for large migration efforts is that the community often offers some extra assistance through the evaluation period and beyond.\n\nFor example, the GitLab for Open Source program has a [public tracker for KDE's migration](https://gitlab.com/gitlab-org/gitlab/-/issues/24900), which is used to communicate and better understand at a glance the issues that are especially important. This allows KDE, GitLab, and the larger open source community to collaborate on challenges together.\n\n\"GitLab's values of [collaboration](https://handbook.gitlab.com/handbook/values/#collaboration) and [transparency](https://handbook.gitlab.com/handbook/values/#transparency) really shine through,\" says Neofytos. We appreciate their openness to accepting merge requests from community members and considering proposals for new features. We have had a great experience so far collaborating with members of the GitLab community and members of the GitLab team – from developers to program managers to product owners alike.\"\n\nNow that phase one of the KDE migration is complete, we look forward to continuing to collaborate with KDE through the remaining phases of the migration.\n\n### Summary of the KDE migration\n\n * Phase 1: Code hosting & review ✅\n * Phase 2: CI\n * Phase 3: Task management for developers\n\n## How to contribute to KDE\n\nKDE has an amazing community and they welcome new members! Existing members are happy to provide feedback on newcomers' contributions with the goal of helping them learn. Every day more and more people join the ever-growing KDE family – and there's always room for more!\n\nKDE has a rich infrastructure of web resources, forums, mailing-lists, IRC (chat), and many other ways to get in touch. To learn more about joining the KDE community, visit their \"[Get Involved](https://community.kde.org/Get_Involved)\" page, which offers guidance to all contributors from all backgrounds.\n\n",[675,1583,1434],{"slug":1825,"featured":6,"template":679},"welcome-kde","content:en-us:blog:welcome-kde.yml","Welcome Kde","en-us/blog/welcome-kde.yml","en-us/blog/welcome-kde",{"_path":1831,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1832,"content":1838,"config":1844,"_id":1846,"_type":16,"title":1847,"_source":17,"_file":1848,"_stem":1849,"_extension":20},"/en-us/blog/3000-contributors-post",{"title":1833,"description":1834,"ogTitle":1833,"ogDescription":1834,"noIndex":6,"ogImage":1835,"ogUrl":1836,"ogSiteName":713,"ogType":714,"canonicalUrls":1836,"schema":1837},"Celebrating 3,000 wider community contributors","We've reached an important contributor milestone and added two new members to the Core Team.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678450/Blog/Hero%20Images/blog-header-3000-contributors.png","https://about.gitlab.com/blog/3000-contributors-post","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Celebrating 3,000 wider community contributors\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2020-06-23\",\n      }",{"title":1833,"description":1834,"authors":1839,"heroImage":1835,"date":1841,"body":1842,"category":14,"tags":1843},[1840],"Ray Paik","2020-06-23","\nLike many open source projects, we have a [community dashboard](https://contributors.gitlab.com) at GitLab and one of the metrics that a few of us were occasionally checking on was the number of **Contributors**. This is the number of wider community members who had merge requests (MRs) merged with the `Community contribution` label across all projects at GitLab. There were some virtual high fives a few weeks ago when the number crossed the 3,000 threshold. There is probably a tendency to place oversized importance on nice round numbers, because if you really think about it the GitLab community wasn't any different at 2,999 vs. 3,000 contributors. However, it was a great occasion to celebrate the continued growth of the wider GitLab community.  \n\n![Community dashboard screenshot](https://about.gitlab.com/images/blogimages/3000-contributors/dashboard-screenshot.png){: .shadow.medium.center}\nCommunity dashboard screenshot from April 23, 2020\n{: .note.text-center}\n\nThe past few months have been a challenging time due to Covid-19, and there was talk in open source circles about the pandemic's potential impact on contributions to open source projects. As people were trying to sort out many new challenges in life, it was reasonable to expect that open source contributions might fall lower on the list of priorities. We actually did see a decline in wider community contributions during the last few weeks of March (125 MRs submitted) compared to the previous two weeks (143 MRs submitted). However, the GitLab community seemed to roar back relatively quickly, and the best evidence of that is from our most recent [Hackathon](/community/hackathon/) when my inbox got innundated with [240 MRs submitted](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/-/issues/35#merge-request-list) over two days. \n\nFirst and foremost, I'm very glad most of the wider community members are doing ok and adjusting to the strange new normal. Moreover, I am grateful that new people are continuing to join and helping to grow the GitLab community with their contributions and enthusiasm even during these challenging times. \n\nWhat all these contributors bring are not just MRs but more importantly valuable feeback and insight that help us improve our product and the community. Some of you may have seen our latest [2020 Global DevSecOps Survey results](/developer-survey/), and one figure that caught my attention was that more than 17% of the respondents actually contribute to GitLab. I hope to see that trend continue.\n\n## Exciting additions to the Core Team\n\nMany of you may already be familar with the [GitLab Core Team](/community/core-team/), but if not, Core Team members are community members who made sustained contribution to GitLab over the years and serve as representatives of the wider contributor community. In keeping with the growth in contributor numbers, I'm happy to report that we are also adding to the GitLab Core Team. \n\nFrom the wider community, I'm excited to introduce [Lee Tickett](https://gitlab.com/leetickett) as a new Core Team member. If you ever posted a question in the [Contributors room on Gitter](https://gitter.im/gitlab/contributors), Lee may have been one of the first to help with your question. Lee has also been very active with [code contributions](https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=all&author_username=leetickett) and participating in [issues](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=all&author_username=leetickett). Lee's contribution to GitLab as someone who's been using GitLab for his own company since 2017 has been extremely valuable. When Lee isn't working, contributing, sleeping or eating, you'll likely find him spending time with his family or kicking back in his home bar with some Pac-Man, a game of pool and an ice cold pint.\n\nThe Core Team also includes up to two GitLab team members, and I'm very happy to have [Natalia Tepluhina](/company/team/#ntepluhina) joining as the first female member in the history of the GitLab Core Team. If you submitted frontend related MRs, there's a good chance that Natalia [reviewed and merged your MRs](https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name[]=Community%20contribution&assignee_username=ntepluhina). Natalia is also a Core Team member in the Vue.js community and brings a wealth of experience from other open source projects. If you want to meet Natalia in person, she is a frequent speaker at Vue.js events around the world and other Javascript conferences such as [JSHeroes](https://jsheroes.io/) and [JSNation](https://jsnation.com/). \n\n![Core Team pictures](https://about.gitlab.com/images/blogimages/3000-contributors/Core-team-pictures.png){: .shadow.medium.center}\nWelcome Lee and Natalia to the Core Team!\n{: .note.text-center}\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can\nlearn how you can contribute to GitLab's code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to [email me](mailto:rpaik@gitlab.com).\n\n**Read more about our GitLab contributors:**\n\n[New tools make contributing to GitLab easier](/blog/13-0-contributor-experience-update/)\n\n[Community contributions in 2019](/blog/community-update-for-2019/)\n\n[What's a GitLab Hackathon _really_ like?](/blog/q4-hackathon-recap/)\n",[268,675,865],{"slug":1845,"featured":6,"template":679},"3000-contributors-post","content:en-us:blog:3000-contributors-post.yml","3000 Contributors Post","en-us/blog/3000-contributors-post.yml","en-us/blog/3000-contributors-post",{"_path":1851,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1852,"content":1858,"config":1864,"_id":1866,"_type":16,"title":1867,"_source":17,"_file":1868,"_stem":1869,"_extension":20},"/en-us/blog/startup-covid-tracking",{"title":1853,"description":1854,"ogTitle":1853,"ogDescription":1854,"noIndex":6,"ogImage":1855,"ogUrl":1856,"ogSiteName":713,"ogType":714,"canonicalUrls":1856,"schema":1857},"How an analytics software startup took aim at COVID-19","Illumina Consulting Group didn’t just sit idle during the pandemic. Here’s how they developed a COVID-19 assessment and analysis tool.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681320/Blog/Hero%20Images/startupcovid.jpg","https://about.gitlab.com/blog/startup-covid-tracking","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How an analytics software startup took aim at COVID-19\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-05-15\",\n      }",{"title":1853,"description":1854,"authors":1859,"heroImage":1855,"date":1861,"body":1862,"category":14,"tags":1863},[1860],"Valerie Silverthorne","2020-05-15","\n\n_In the second of our irregular series on [the intersection of technology and COVID-19](/blog/cobol-programmer-shortage/), here’s a look at how one small software company changed gears to create a tool for symptom tracking._\n\nWe’ve heard a lot about companies around the world moving from [toy production to personal protective equipment](https://sports.yahoo.com/toy-companies-switch-gears-help-022919242.html), or switching gears from [making gin to making hand sanitizer](https://www.bbc.com/worklife/article/20200413-how-factories-change-production-to-quickly-fight-coronavirus).\n\nBut how about companies that have contributed in a more subtle way?\n\n[Illumina Consulting Group](https://icgsolutions.com/) is a Maryland-based data analytics software startup that does most of its work for the intelligence community. Suffice it to say about two months ago the team found themselves with time on their hands, says CEO David Waldrop. \"ICG has a very potent team of developers,\" he explains. \"So when this COVID thing kind of happened, we were sitting around trying to figure out what to do for the next eight weeks or longer sitting at home like groundhog day, with every day the same as the next. How could we help with this COVID thing with our skillset? We build software, that's what we do for a living.\" (For the record ICG is a GitLab customer, but this isn’t a post about that.)\n\nWaldrop’s team defined the requirements and concluded the biggest problem with this very contagious virus is a shortage of primary information. \"Who's really got the disease and how early in the process can we detect them?\" he asks. \"And the answer to that is pretty straightforward. Who's the person who knows if they've got the disease? Every person that's out there that's got a nose and ears and eyes that might have a sniffle and a fever. And so how could we get that information from those people? What if we just asked them?\"\n\nAnd with that simple thought process, a symptom assessment tool, [DoIhaveit.net](https://doihaveit.net/home#home), was born. The tool offers users both a snapshot of COVID-19 in their area (based on zip code) and asks them to take a quick two minute health survey. Using the results of that data, DoIhaveit (or DIHI as they call it) offers advice straight from the Centers for Disease Control. The survey is anonymous – it does not collect personal identifying information or private health data.\n\n![DoIhaveit.net home page](https://about.gitlab.com/images/blogimages/doihaveitscreenshot.png){: .shadow.medium.center.wrap-text}\n\nWaldrop admits the team was skeptical at first about the idea of people being willing to contribute their experiences. But \"everybody's got a mother or a grandmother or an older uncle or somebody,\" he says. \"When that person goes to the hospital, they want there to be a bed and a ventilator and gowns and all that stuff available.\"\n\nTo meet those needs ICG built DoIhaveit with a frontend survey piece and a backend that will aggregate and analyze the data down to the zip code level. \"We made it so the messaging at the assessment and the summary level can be jurisdictionally specific down to the zip code if necessary,\" he says. The team wanted it to be flexible for wherever the cycle takes an area from flattened curve to rising cases and to be modifiable by a public health or safety team that might want to adjust the parameters on the fly.\n\nAnd that’s the real point of DoIhaveit, Waldrop says – to make sure doctors and hospital systems are prepared for a potential onslaught. \"We built this as a public service and it’s ready to go.\" It’s in use in Virginia and the company wants to spread the word across the country. It’s completely free of charge for municipalities and Waldrop stresses ICG isn’t making any money from this. \"We hope to get this into as many hands as possible.\"\n\nCover image by [Centers for Disease Control](https://unsplash.com/@cdc) on [Unsplash](https://unsplash.com)\n{: .note}\n",[864,268,865],{"slug":1865,"featured":6,"template":679},"startup-covid-tracking","content:en-us:blog:startup-covid-tracking.yml","Startup Covid Tracking","en-us/blog/startup-covid-tracking.yml","en-us/blog/startup-covid-tracking",{"_path":1871,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1872,"content":1878,"config":1883,"_id":1885,"_type":16,"title":1886,"_source":17,"_file":1887,"_stem":1888,"_extension":20},"/en-us/blog/cobol-programmer-shortage",{"title":1873,"description":1874,"ogTitle":1873,"ogDescription":1874,"noIndex":6,"ogImage":1875,"ogUrl":1876,"ogSiteName":713,"ogType":714,"canonicalUrls":1876,"schema":1877},"How can we help solve the COBOL programmer shortage?","A shortage of COBOL programmers is causing delays in processing unemployment claims and small business loans. We’re hoping our community can help.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667886/Blog/Hero%20Images/cobolshortage.jpg","https://about.gitlab.com/blog/cobol-programmer-shortage","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How can we help solve the COBOL programmer shortage?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-04-23\",\n      }",{"title":1873,"description":1874,"authors":1879,"heroImage":1875,"date":1880,"body":1881,"category":14,"tags":1882},[1860],"2020-04-23","\n\nIn our current world situation is it any surprise that a shortage of COBOL developers is holding up unemployment benefits and Small Business Association loan processing?\n\nActually, it is kind of surprising. We’ve grown used to the rapid advance of technology and it’s safe to say we’re like most companies – looking forward and not backward.\n\n## COBOL programmers needed\n\nBut it might be time to change that, and we’re reaching out to all of you for ideas and suggestions on ways to help provide a solution to the large number of COBOL programmers needed. What can we, as a community, do to help government agencies overwhelmed with demands on aging mainframes and with too few programmers to get the jobs done?\n\nCNN and a number of other news agencies reported that a lack of COBOL programming expertise has led to [long waits in processing unemployment benefits and small business loans](https://www.techspot.com/news/84796-us-states-desperate-cobol-programmers-ibm-offering-free.html?fbclid=IwAR1M2tlg2MeLHsG7ZzHawzPtsliTBaJX-1EgTlxIdr4BSHihN6sn-JbKpeo) at a time when [joblessness has hit record highs](https://www.washingtonpost.com/business/2020/04/16/unemployment-claims-coronavirus/).\n\n### Oppertunities for COBOL programmers\n\nBut COBOL isn’t limited to government entities: Large financial services and a myriad of other industries are still heavily reliant on mainframes and their primary programming language. As such,there is a large number of COBOL programmers needed with a wide array of oppertunities available. That’s not likely to change anytime soon – IBM says there are 240 billion lines of COBOL running today with an additional 5 billion being written every year.\n\nWhile that may sound like job security, COBOL programming isn’t widely taught today and it certainly lacks the developer interest level of Ruby or TypeScript or Go. A quick search on job site [Glassdoor](https://www.glassdoor.com/) shows about 1700 jobs advertised for COBOL programmers across the US today, while there are well over 4000 potential employers for Go or Ruby developers, and over 30,000 for Java developers.\n\nToday a number of companies [are working to integrate](https://www.rocketsoftware.com/zos-open-source/tools) more \"modern\" software development methodologies with mainframes ([even GitLab](https://gitlab.com/gitlab-org/gitlab-runner/issues/3263)), but that’s not going to solve the short-term need (or probably even the medium-term need).\n\n### Education and Upskilling for COBOL programmers\n\nThere are some educational opportunities available from [Udemy](https://www.udemy.com/course/mainframe-the-complete-cobol-course-from-beginner-to-expert/), [LinkedIn](https://www.linkedin.com/learning/topics/cobol), [Learning Tree](https://www.learningtree.com/courses/2301/enterprise-cobol-programming-part-1/) and a [free COBOL programming course](https://github.com/openmainframeproject/cobol-programming-course) from the openmainframeproject on GitHub.\n\nCan we do more? We don’t have the answers but we’ve opened [a public issue](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/7271) so please leave any ideas there.\n\n_Updated on June 1, 2020: We've had some responses on our public issue including this from contributor [Timothy Austin](https://gitlab.com/taustin288): \"The companies who hold all these large COBOL code bases need to pressure the universities to require all up and coming Java programmers to have a rudimentary knowledge of COBOL. This would allow them the flexibility to convert the COBOL or continue use it as is if they so desire.\" Learn more in [our issue](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/7271)._ \n\nCover image by [Joshua Sortino](https://unsplash.com/@sortino) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[268,865,675],{"slug":1884,"featured":6,"template":679},"cobol-programmer-shortage","content:en-us:blog:cobol-programmer-shortage.yml","Cobol Programmer Shortage","en-us/blog/cobol-programmer-shortage.yml","en-us/blog/cobol-programmer-shortage",{"_path":1890,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1891,"content":1897,"config":1902,"_id":1904,"_type":16,"title":1905,"_source":17,"_file":1906,"_stem":1907,"_extension":20},"/en-us/blog/ultimate-git-guide",{"title":1892,"description":1893,"ogTitle":1892,"ogDescription":1893,"noIndex":6,"ogImage":1894,"ogUrl":1895,"ogSiteName":713,"ogType":714,"canonicalUrls":1895,"schema":1896},"Our ultimate guide to Git","Open source pioneer Git is 15 years old. Here is our guide to making the most of it.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681222/Blog/Hero%20Images/git-15th-anniversary-cover.png","https://about.gitlab.com/blog/ultimate-git-guide","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Our ultimate guide to Git\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-04-20\",\n      }",{"title":1892,"description":1893,"authors":1898,"heroImage":1894,"date":1899,"body":1900,"category":14,"tags":1901},[1860],"2020-04-20","\n\n_Git, a [source code management](/solutions/source-code-management/) tool and arguably the most famous open source software project, turned 15 in April 2020. That’s a milestone no matter how you look at it, and not surprisingly our team has a lot to say about Git. From a look back at the past to newbie-friendly explanations, we’ve pulled together the ultimate guide to Git (as told by GitLab)._\n\n## Meet Git\n\nIf you’re just getting started with software development, you’ll have questions. Luckily, we have answers including background on developer Linus Torvalds in [\"A beginner’s guide to Git\"](/blog/beginner-git-guide/).\n\n![Linus Torvalds](https://about.gitlab.com/images/blogimages/linustorvalds.png){: .shadow.small.center}\n\nThe godfather of Git, Linus Torvalds.\n{: .note.text-center}\n\n## Get more out of Git\n\nWe all spend a ton of time working with Git so it makes sense to polish up your workflow so it shines. We’ve [got the lowdown](/blog/15-git-tips-improve-workflow/) on Git blame, .gitignore, how to pull frequently, and more.\n\n## Missed Git Merge?\n\nNot everyone was lucky enough to attend the actual, in-person Git birthday party. Here’s our [first-person account](/blog/git-merge-fifteen-year-git-party/) of the festivities, complete with lots of pictures.\n\n![birthday balloons](https://about.gitlab.com/images/blogimages/balloons.jpg){: .shadow.small.center}\n\n## Why Git flow doesn’t always go with the flow\n\nYou can have too much of a good thing, and if you doubt that, perhaps it’s because you haven’t yet encountered Git flow. Although designed to streamline development it ends up creating extra effort – too many branches and too much task switching. Never fear, though, [we have a solution](/blog/what-is-gitlab-flow/).\n\n## Git goes (really) big\n\nWhen Git was invented 15 years ago, video streaming (and gaming) weren’t even on the horizon. Git can handle those huge files but there’s one hiccup: You can’t just download the one you need, Git insists you download all of them. Enter Git Partial Clone which speeds up the process so you can just grab the file you need. [Here’s how it works](/blog/partial-clone-for-massive-repositories/).\n\n## GitLab and GitHub on Git\n\nOur senior developer evangelist [Brendan O’Leary](/company/team/#brendan) did a bit of a point counter-point about Git and its past and future with GitHub’s distinguished software engineer [Jeff King](https://www.linkedin.com/in/pefflinkedin/) on [infoq.com](https://www.infoq.com/news/2020/04/git-fifteen-anniversary-qa/).\n\n## Never say never\n\nBrendan also admitted that 15 years ago, he was never ever going to use Git. Ahem. Feel free to enjoy [his mea culpa](https://www.computerweekly.com/blog/Open-Source-Insider/GitLab-guru-15-years-later-were-still-learning).\n\n## Dive into GitOps\n\nYou’ve heard the term, now is the time to understand what [GitOps](/solutions/gitops/) means and how it can work – well – in real world applications. Here’s what you need to know about [continuous delivery to production](/blog/why-gitops-should-be-workflow-of-choice/).\n\nImage by [Adi Gold](https://unsplash.com/@adigold1) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[699,675,1139],{"slug":1903,"featured":6,"template":679},"ultimate-git-guide","content:en-us:blog:ultimate-git-guide.yml","Ultimate Git Guide","en-us/blog/ultimate-git-guide.yml","en-us/blog/ultimate-git-guide",{"_path":1909,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1910,"content":1915,"config":1922,"_id":1924,"_type":16,"title":1925,"_source":17,"_file":1926,"_stem":1927,"_extension":20},"/en-us/blog/15-git-tips-improve-workflow",{"title":1911,"description":1912,"ogTitle":1911,"ogDescription":1912,"noIndex":6,"ogImage":1894,"ogUrl":1913,"ogSiteName":713,"ogType":714,"canonicalUrls":1913,"schema":1914},"15 Git tips to improve your workflow","Learn how to compare commits, delete stale branches, and write aliases to save you some time. It's time to dust off your command line and Git busy!","https://about.gitlab.com/blog/15-git-tips-improve-workflow","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"15 Git tips to improve your workflow\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2020-04-07\",\n      }",{"title":1911,"description":1912,"authors":1916,"heroImage":1894,"date":1918,"body":1919,"category":14,"tags":1920},[1917],"Suri Patel","2020-04-07","\n\nThis year, [Git](https://git-scm.com/) celebrates its 15th anniversary, and we’ve been excitedly posting some thoughts about its creation and impact — from sharing our experience at [Git Merge 2020](/blog/git-merge-fifteen-year-git-party/), discussing [the problem with Git flow](/blog/what-is-gitlab-flow/), or highlighting the newest Git feature [Partial Clone](/blog/partial-clone-for-massive-repositories/).\n\nWhether you’re just getting started with Git, or you know your way around a command line, it’s always nice to brush up on your skills, which is why we’ve gathered 15 methods to improve your Git-based workflow.\n\n### 1. Git aliases\n\nOne of the most impactful ways to improve your daily workflow is to create aliases for common commands to save you some time in the terminal.\n\nYou can use the following commands to create aliases for the most-used Git commands, `checkout`, `commit` and `branch`.\n\n```\ngit config --global alias.co checkout\ngit config --global alias.ci commit\ngit config --global alias.br branch\n```\n\nInstead of typing `git checkout master`, you only need to type `git co master`.\n\nYou could also edit these commands or add more by modifying the `~/.gitconfig` file directly:\n\n```\n[alias]\n    co = checkout\n    ci = commit\n    br = branch\n```\n\n### 2. See the repository status in your terminal’s prompt\n\nIf you’d like to visualize the status of your repository, you can run `git-prompt.sh`\n(you can [download it](https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh) and follow the\ninstructions to use it in your system). If you're using Linux\nand have installed Git with your package manager, it may already be\npresent on your system, likely under `/etc/bash_completion.d/`.\n\nYou can replace your standard shell prompt with something a bit more exciting:\n\n![Git shell prompt](https://about.gitlab.com/images/blogimages/git-tricks/git-shell-info.png){: .shadow}\n\n_Taken from oh-my-zsh's [themes wiki](https://github.com/robbyrussell/oh-my-zsh/wiki/Themes#kafeitu)._\n\n### 3. Compare commits from the command line\n\nA simple way to compare the differences between commits or versions of the same file is to use the `git diff` command.\n\nIf you want to compare the same file between different commits, you run the following:\n\n```\n$ git diff $start_commit..$end_commit -- path/to/file\n```\n\nIf you want to compare the changes between two commits:\n\n```\n$ git diff $start_commit..$end_commit\n```\n\nThese commands will open the diff view inside the terminal, but if you prefer to use a more visual tool to compare your diffs, you can use `git difftool`. [Meld](https://meldmerge.org/) is a useful viewer/editor to visually compare diffs.\n\nTo configure Meld:\n\n```\n$ git config --global diff.tool git-meld\n```\n\nTo start viewing the diffs:\n\n```\n$ git difftool $start_commit..$end_commit -- path/to/file\n# or\n$ git difftool $start_commit..$end_commit\n```\n\n### 4. Stashing uncommitted changes\n\nIf you’re ever working on a feature and need to do an emergency fix on the project, you could run into a problem. You don’t want to commit an unfinished feature, and you also don’t want to lose current changes. The solution is to temporarily remove these changes with the Git stash command:\n\n```\n$ git stash\n```\n\nThe git stash command hides changes, giving you a clean working directory and the ability to switch to a new branch to make updates, without having to commit a meaningless snapshot in order to save the current state.\n\nOnce you’re done working on a fix and want to revisit your previous changes, you can run:\n\n```\n$ git stash pop\n```\n\nAnd your changes will be recovered. 🎉\n\nIf you no longer need those changes and want to clear the stash stack, you can do so with:\n\n```\n$ git stash drop\n```\n\n### 5. Pull frequently\n\nIf you’re using [GitLab Flow](/solutions/gitlab-flow/), then you’re working\non feature branches. Depending on how long your feature takes to implement, there might be several changes made to the master branch. In order to avoid major conflicts, you should frequently pull the changes from the master branch to your branch to resolve any conflicts as soon as possible and to make merging your branch to master easier.\n\n### 6. Autocomplete commands\n\nUsing [completion scripts](https://github.com/git/git/tree/master/contrib/completion), you can quickly create the commands for `bash`, `tcsh` and `zsh`. If you want to type `git pull`, you can type just the first letter with `git p` followed by \u003Ckbd>Tab\u003C/kbd> will show the following:\n\n```\npack-objects   -- create packed archive of objects\npack-redundant -- find redundant pack files\npack-refs      -- pack heads and tags for efficient repository access\nparse-remote   -- routines to help parsing remote repository access parameters\npatch-id       -- compute unique ID for a patch\nprune          -- prune all unreachable objects from the object database\nprune-packed   -- remove extra objects that are already in pack files\npull           -- fetch from and merge with another repository or local branch\npush           -- update remote refs along with associated objects\n```\n\nTo show all available commands, type `git` in your terminal followed by\n\u003Ckbd>Tab\u003C/kbd>+ \u003Ckbd>Tab\u003C/kbd>.\n\n### 7. Set a global `.gitignore`\n\nIf you want to avoid committing files like `.DS_Store` or Vim `swp` files,\nyou can set up a global `.gitignore` file.\n\nCreate the file:\n\n```bash\ntouch ~/.gitignore\n```\n\nThen run:\n\n```bash\ngit config --global core.excludesFile ~/.gitignore\n```\n\nOr manually add the following to your `~/.gitconfig`:\n\n```ini\n[core]\n  excludesFile = ~/.gitignore\n```\nYou can create a list of the things you want Git to ignore. To learn more, visit the [gitignore documentation](https://git-scm.com/docs/gitignore).\n\n### 8. Enable Git’s autosquash feature by default\n\nAutosquash makes it easier to squash commits during an interactive rebase. It can be enabled for each rebase using `git rebase -i --autosquash`, but it's easier to turn it on by default.\n\n```bash\ngit config --global rebase.autosquash true\n```\n\nOr manually add the following to your `~/.gitconfig`:\n\n```ini\n[rebase]\n  autosquash = true\n```\n\n### 9. Delete local branches that have been removed from remote on fetch/pull\n\nYou likely have stale branches in your local repository that no longer exist in the remote one. To delete them in each fetch/pull, run:\n\n```bash\ngit config --global fetch.prune true\n```\n\nOr manually add the following to your `~/.gitconfig`:\n\n```ini\n[fetch]\n  prune = true\n```\n\n### 10. Use Git blame more efficiently\n\nGit blame is a handy way to discover who changed a line in a file. Depending on what you want to show, you can pass different flags:\n\n```\n$ git blame -w  # ignores white space\n$ git blame -M  # ignores moving text\n$ git blame -C  # ignores moving text into other files\n```\n\n### 11. Add an alias to check out merge requests locally\n\nA [merge request](https://docs.gitlab.com/ee/user/project/merge_requests/) contains all the history from a repository, and the additional\ncommits added to the branch associated with the MR. You can check out a public merge request locally even if the source project is a fork (even a private fork) of the target project.\n\nTo check out a merge request locally, add the following alias to your `~/.gitconfig`:\n\n```\n[alias]\n  mr = !sh -c 'git fetch $1 merge-requests/$2/head:mr-$1-$2 && git checkout mr-$1-$2' -\n```\n\nNow you can check out a merge request from any repository and any remote. For example, to check out the merge request with ID 5 as shown in GitLab\nfrom the `upstream` remote, run:\n\n```\ngit mr upstream 5\n```\n\nThis will fetch the merge request into a local `mr-upstream-5` branch and check\nit out. In the above example, `upstream` is the remote that points to GitLab\nwhich you can find out by running `git remote -v`.\n\n### 12. An alias of `HEAD`\n\nBreaking news: `@` is the same as `HEAD`. Using it during a rebase is a lifesaver:\n\n```bash\ngit rebase -i @~2\n```\n\n### 13. Resetting files\n\nYou’re modifying your code when you suddenly realize that the changes you made are not great, and you’d like to reset them. Rather than clicking undo on everything you edited, you can reset your files to the HEAD of the branch:\n\n```\n$ git reset --hard HEAD\n```\n\nOr if you want to reset a single file:\n\n```\n$ git checkout HEAD -- path/to/file\n```\n\nNow, if you already committed your changes, but still want to revert back, you can use:\n\n```\n$ git reset --soft HEAD~1\n```\n\n### 14. The `git-open` plugin\n\nIf you’d like to quickly visit the website that hosts the repository you’re on, you’ll need `git-open`.\n\n[Install it](https://github.com/paulirish/git-open#installation) and take it for a spin by cloning a repository from\n[GitLab.com](https://gitlab.com/explore). From your terminal, navigate to the\nrepository and run `git open` to be transferred to the project’s page on\nGitLab.com.\n\nThe plugin works by default for projects hosted on GitLab.com, but you can also use it\nwith your own GitLab instances. In that case, set up the domain name with:\n\n```bash\ngit config gitopen.gitlab.domain git.example.com\n```\n\nYou can open different remotes and branches if they have been set up. You can learn more by checking out the [examples section](https://github.com/paulirish/git-open#examples).\n\n### 15. The `git-extras` plugin\n\nIf you want to elevate Git with more commands, try out the\n[`git-extras` plugin](https://github.com/tj/git-extras), which includes `git info` (show\ninformation about the repository) and `git effort` (number of commits per file).\n\n## Learn more about Git\n\nWe’re excited to announce that [Brendan O’Leary](/company/team/#brendan), senior developer evangelist, will create 15 videos to celebrate Git's anniversary over the next several months. He’ll focus on a variety of topics, from rebasing and merging to cherry-picking and branching. Take a look at the first video in the series. 🍿\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/9oDNBuive-g\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nCover image by [Brooke Lark](https://unsplash.com/@brookelark?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/birthday?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[699,1921,1541],"workflow",{"slug":1923,"featured":6,"template":679},"15-git-tips-improve-workflow","content:en-us:blog:15-git-tips-improve-workflow.yml","15 Git Tips Improve Workflow","en-us/blog/15-git-tips-improve-workflow.yml","en-us/blog/15-git-tips-improve-workflow",{"_path":1929,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1930,"content":1936,"config":1942,"_id":1944,"_type":16,"title":1945,"_source":17,"_file":1946,"_stem":1947,"_extension":20},"/en-us/blog/git-merge-fifteen-year-git-party",{"title":1931,"description":1932,"ogTitle":1931,"ogDescription":1932,"noIndex":6,"ogImage":1933,"ogUrl":1934,"ogSiteName":713,"ogType":714,"canonicalUrls":1934,"schema":1935},"Git Merge 2020: a celebration of Git","A look at Git Merge 2020 and a look forward to the next decade of remote, async, and powerful source code management.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681154/Blog/Hero%20Images/GitLab-sponsoring-Git-Merge.jpg","https://about.gitlab.com/blog/git-merge-fifteen-year-git-party","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git Merge 2020: a celebration of Git\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jordi Mon\"}],\n        \"datePublished\": \"2020-03-25\",\n      }",{"title":1931,"description":1932,"authors":1937,"heroImage":1933,"date":1939,"body":1940,"category":14,"tags":1941},[1938],"Jordi Mon","2020-03-25","\n\nAlmost 15 years ago [Linus Torvalds](https://www.linkedin.com/in/linustorvalds/) came out of retirement and released a project – Git – that would be adopted by millions who would in turn contribute over time to what is arguably the world's most powerful distributed version control system.\n\n![Git Merge 2020 kicking off](https://about.gitlab.com/images/blogimages/git-merge-2020/Entrance_Git_Merge.gif){: .center}\n\nIn early March, Git was celebrated at [Git Merge 2020](https://git-merge.com/#schedule/), an event that was sponsored by GitHub, GitLab and the [Software Freedom Conservancy (SFC)](https://sfconservancy.org/). A fair share of GitLab team members attended and actively participated in the birthday celebration. We thought we'd share a look at what we liked most.\n\n![Happy birthday Git](https://about.gitlab.com/images/blogimages/git-merge-2020/15_years_of_Git.jpg){: .shadow.medium.center}\n\n## Git police, stop! Open that trunk\n\nThere were lots of bad jokes like that one, but fortunately the content was much better than the jokes. Our users often say the one thing they like about GitLab is it makes Git understandable to them. It's nice to have validation every now and then and that is precisely what we felt during the talk titled **The Zen of Git** in which [Tianyu Pu](https://twitter.com/tianyupu), a software developer at Booking.com, explained in beautifully crafted slides how Git's internals work. By knowing how Git works she is able to approach Git less fearfully and be more productive using it in a day-to-day workflow. Judging by the warm round of applauses received when she finished her talk, we would argue she definitely achieved her goal. The clarity with which she presented each concept was encouraging so we suggest reading through [her deck](https://speakerdeck.com/tianyupu/the-zen-of-git).\n\n![Git 15 year life](https://about.gitlab.com/images/blogimages/git-merge-2020/Git_timeline.jpg){: .shadow.medium.center}\n\n[Ed Thomson](https://twitter.com/ethomson), co-maintainer of libgit2 and a GitHub employee, received some laughter from the audience the minute he was up on stage. His talk was about how lightweight, short-living branches merged fast into trunk – or master, as you wish (more terrible jokes!). He outlined great ideas to keep some sanity in your development branching model. To make this even more compelling, why not a Git workflow alignment chart?\n\n![Ed Thomson's Git workflow alignment chart](https://about.gitlab.com/images/blogimages/git-merge-2020/Git-workflow-alignment-chart.png){: .shadow.medium.center}\n\nEd suggested that pairing this pattern with [continuous delivery practices](/topics/continuous-delivery/) would make a perfect combo. Git flow, however, didn’t get the best of Ed's talk but it is noteworthy that Git flow’s author [Vincent Driessen](https://twitter.com/nvie) shared some timely advice [on his blog](https://nvie.com/posts/a-successful-git-branching-model/) while Git Merge was taking place:\n\n> If your team is doing continuous delivery of software, I would suggest to\n> adopt a much simpler workflow instead of trying to\n> shoehorn git-flow into your team.\n\nBut if there was a star that day, it certainly was [Derrick Stolee](https://twitter.com/stolee?lang=en) from Microsoft. Derrick and his team have recently released [Scalar](https://devblogs.microsoft.com/devops/introducing-scalar/). Barebones Git or Git in combination with the VFS protocol can still struggle when handling large repos like the one hosting Windows' source code. Scalar is an open source project aimed at accelerating Git's workflow regardless of the size of the repos.\n\nI asked Derrick how he and his team combined the request from his employer Microsoft and the larger goals of the Git community which may not be in alignment. For him the answer is simple: Microsoft thinks of Scalar as a good solution for clients and internal teams. The company believes giving Scalar to Git will only make it better since most of the community members are Git veterans and will be able to improve the feature. When designing Scalar Derrick's team always had Git's architecture in mind and the plan is to contribute it to [Git's client](https://devblogs.microsoft.com/devops/introducing-scalar/#git-future). I believe this speaks volumes about Derrick's team's ability to solve a complex problem but also at the same time care about the larger community and Git's design. This is just one example of how enterprises and the larger Git community are getting together and making Git perform better and in more use cases.\n\nAnd Scalar does not only just apply to Window's repo, Office's repo or video game repos. It is having a real-world and timely impact. This [repo](https://github.com/FoldingAtHome/coronavirus/issues/41#issuecomment-602186402) that is collecting real-time datasets to help with the COVID-19 pandemic is getting bigger every minute thanks to the input that many, including [some GitLab teams](https://about.gitlab.com/handbook/engineering/#foldinghome-and-covid-19), are offering. However, it needs technology like Scalar to handle it. \n\nAt the end of our chat Derrick asked me if I knew about the Japanese principle of [Ikigai](https://en.wikipedia.org/wiki/Ikigai):\n\n> Try to find something for your professional career that is fulfilling, something you are good at, something the world needs and something you'll get paid for.\n\nIt's true that contributing features to Git that are useful in such dire times must be a reason to be part of the Git community.\n\n## Work in the open: companies collaborating for the good of Git\n\nScalar isn't the only recent addition to Git – Partial Clone was contributed to Git by [Jeff Hostetler](https://twitter.com/jeffhostetler) from Microsoft and Jonathan Tan from Google. In Derrick's opinion, both of them came from different perspectives to solve the same problem. Had they not collaborated on their approach – even with the community's input – they wouldn't have arrived at the same successful feature that Partial Clone is now. Another very recent example of this same collaboration is some of the updates [Git v2.26 comes with](https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.26.0.txt). And [Peff](https://github.com/peff) from GitHub and [Christian Couder](https://gitlab.com/chriscool) from GitLab contributed changes to the way Git handles packfiles.\n\n## GitLab experts all over: to 15 more years!\n\nOverall we found a lot of validation in GitLab's own work, not only upstream to Git with new features like the ones already mentioned, but also downstream to our users. GitLab gets better at making Git more easily usable and proposes development workflows, like [GitLab Flow](https://docs.gitlab.com/ee/topics/gitlab_flow.html), that allow our users to be fast and productive while keeping a neat code base. GitLab is making [Partial Clone](https://about.gitlab.com/blog/partial-clone-for-massive-repositories/) progressively more stable across any GitLab instance. (If you are already using partial clone, or would like to help us test partial clone on a large project, please get in touch with [James Ramsay](mailto:jramsay@gitlab.com), the group manager, product for Create at GitLab, me [Jordi Mon](mailto:jmon@gitlab.com) or your account manager.)\n\n![GitLab team having fun](https://about.gitlab.com/images/blogimages/git-merge-2020/GitLab_working_together.jpg){: .shadow.medium.center}\n\nWhile our very own [James Ramsay](https://gitlab.com/jramsay) participated in an expert panel in [last year's event](https://github.blog/wp-content/uploads/2019/02/190201_GithubBrussels2019_0330.jpg?resize=1024%2C683?w=1024), this year [Zeger-Jan van de Weg](https://gitlab.com/zj-gitlab) was on stage for a stump the experts panel.\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">\u003Ca href=\"https://twitter.com/gitlab?ref_src=twsrc%5Etfw\">@gitlab\u003C/a>’s \u003Ca href=\"https://twitter.com/ZJvandeWeg?ref_src=twsrc%5Etfw\">@ZJvandeWeg\u003C/a> on a stump the experts panel at \u003Ca href=\"https://twitter.com/hashtag/GitMerge?src=hash&ref_src=twsrc%5Etfw\">#GitMerge\u003C/a> \u003Ca href=\"https://t.co/jfgC5ZxzWa\">pic.twitter.com/jfgC5ZxzWa\u003C/a>\u003C/p>— Ray Paik (@rspaik) \u003Ca href=\"https://twitter.com/rspaik/status/1235333465203183618?ref_src=twsrc%5Etfw\">March 4, 2020\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">Had a great time meeting Git community members at \u003Ca href=\"https://twitter.com/hashtag/GitMerge?src=hash&ref_src=twsrc%5Etfw\">#GitMerge\u003C/a> 2020 yesterday! It was awesome being there as part of the \u003Ca href=\"https://twitter.com/gitlab?ref_src=twsrc%5Etfw\">@gitlab\u003C/a> team and coming together with folk from \u003Ca href=\"https://twitter.com/github?ref_src=twsrc%5Etfw\">@github\u003C/a> \u003Ca href=\"https://twitter.com/Google?ref_src=twsrc%5Etfw\">@Google\u003C/a> \u003Ca href=\"https://twitter.com/conservancy?ref_src=twsrc%5Etfw\">@conservancy\u003C/a>, and many others, to collaborate and then celebrate Git’s upcoming 15th anniversary! \u003Ca href=\"https://t.co/crXr6iT5qI\">pic.twitter.com/crXr6iT5qI\u003C/a>\u003C/p>— Nuritzi Sanchez (@1nuritzi) \u003Ca href=\"https://twitter.com/1nuritzi/status/1235655639554117637?ref_src=twsrc%5Etfw\">March 5, 2020\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\nMingling around with the rest of the community was hands down the best part of Git Merge 2020. It was so much fun to be part of a welcoming, inclusive community.\n\n![GitLab's team having fun](https://about.gitlab.com/images/blogimages/git-merge-2020/GitLab_team_chilling_out.jpg){: .shadow.medium.center}\n\nFor all these reasons and more we would love our involvement to be ever-growing with Git Merge. That's why we look forward to Git Merge 2021! 15 years have passed and Git is still in its best moment.\n",[278,699,675],{"slug":1943,"featured":6,"template":679},"git-merge-fifteen-year-git-party","content:en-us:blog:git-merge-fifteen-year-git-party.yml","Git Merge Fifteen Year Git Party","en-us/blog/git-merge-fifteen-year-git-party.yml","en-us/blog/git-merge-fifteen-year-git-party",{"_path":1949,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1950,"content":1956,"config":1964,"_id":1966,"_type":16,"title":1967,"_source":17,"_file":1968,"_stem":1969,"_extension":20},"/en-us/blog/from-monolith-to-microservices-how-to-leverage-aws-with-gitlab",{"title":1951,"description":1952,"ogTitle":1951,"ogDescription":1952,"noIndex":6,"ogImage":1953,"ogUrl":1954,"ogSiteName":713,"ogType":714,"canonicalUrls":1954,"schema":1955},"From monolith to microservices: How to leverage AWS with GitLab","GitLab recently spent time with Ask Media Group and AWS to discuss how modernizing from self-managed to a cloud native system empowers developers.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679645/Blog/Hero%20Images/askmediablog-.jpg","https://about.gitlab.com/blog/from-monolith-to-microservices-how-to-leverage-aws-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"From monolith to microservices: How to leverage AWS with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brein Matturro\"}],\n        \"datePublished\": \"2020-03-24\",\n      }",{"title":1951,"description":1952,"authors":1957,"heroImage":1953,"date":1959,"body":1960,"category":14,"tags":1961},[1958],"Brein Matturro","2020-03-24","\n\nAsk Media Group operates over 30 websites and provides enriched search results, articles, galleries, and shopping sites to over 100 million unique visitors each month. About two years ago, [Ask Media](https://www.askmediagroup.com/) was looking for ways to grow the business, draw advertisers, and expand its audience. Routine tasks like onboarding developers or releasing software took too long. The monolithic system that was in place had limited capabilities and added financial burdens for services that went unused. \n\nChenglim Ear, principal software engineer at Ask Media, recently sat down with [Trevor Hansen](https://www.linkedin.com/in/startuptrev), solutions architect at AWS, to discuss how adopting GitLab empowered developers to improve the customer experience, release software quicker, and leverage AWS cloud services. \n \n## Building microservices from monoliths\n\nAsk Media was looking to move away from a monolithic system to [microservices](/topics/microservices/) in order to modernize workflow and improve the overall business process. “We wanted to move over to microservices. We wanted to [leverage Kubernetes](/solutions/kubernetes/). It was a new container world that was shaping. When we looked at GitLab, it was very complete in providing what we needed to be able to build images, to run on containers,” according to Chenglim. “That was a very big deciding factor. GitLab had everything that we needed.” \n\nDevelopers can now break services into multiples and develop them independently, own the code, and have full visibility prior to deployment. “We're making the hidden logic transparent and we enable the parts of the logic to be independently developed in parallel. So you can have developers all working on their own, with different skillsets,” Chenglim says. \n\n## Containers, cost, and scalability\n\n“We needed a system that could handle change. When we look at what we did to speed up development, make it simple and transparent, and control the cost, we see a paradigm shift. GitLab gave us push-button releases. Docker and Kubernetes enabled us to switch to a microservices architecture and AWS enabled auto scaling,” says Chenglim. “On Amazon, we started building Kubernetes clusters and GitLab became our command and control interface.” \n \n Ask Media was looking for a tool that could scale and grow as needed. Cost, speed, and functionality are the tenets that AWS focuses on providing to its customers, according to Hansen. AWS works closely with Ask Media to ensure that the containers in place offer the scalability, flexibility, and timeliness they need. \n\nWith [GitLab and AWS](/partners/technology-partners/aws/), Ask Media developers built out a platform that enables the knowledge from all members of the teams. “With AWS, we wanted a product that was fairly complete and mature. AWS has a lot of history and lots of services. We definitely wanted to be able to leverage those services and to build on a platform that was a solid,” Chenglim says. “We set off to build Kubernetes clusters, right on EC2 instances. We continue to look at opportunities to leverage the resources available through AWS.”\n\nTo learn more about how Ask Media made the transition to cloud native, check out the full [webcast](/webcast/cloud-native-transformation/).\n\nCover image by [Eric Muhr](https://unsplash.com/@ericmuhr?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com)\n{: .note}",[1962,1583,780,1963],"webcast","UI",{"slug":1965,"featured":6,"template":679},"from-monolith-to-microservices-how-to-leverage-aws-with-gitlab","content:en-us:blog:from-monolith-to-microservices-how-to-leverage-aws-with-gitlab.yml","From Monolith To Microservices How To Leverage Aws With Gitlab","en-us/blog/from-monolith-to-microservices-how-to-leverage-aws-with-gitlab.yml","en-us/blog/from-monolith-to-microservices-how-to-leverage-aws-with-gitlab",{"_path":1971,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1972,"content":1978,"config":1984,"_id":1986,"_type":16,"title":1987,"_source":17,"_file":1988,"_stem":1989,"_extension":20},"/en-us/blog/partial-clone-for-massive-repositories",{"title":1973,"description":1974,"ogTitle":1973,"ogDescription":1974,"noIndex":6,"ogImage":1975,"ogUrl":1976,"ogSiteName":713,"ogType":714,"canonicalUrls":1976,"schema":1977},"How Git Partial Clone lets you fetch only the large file you need","Work faster with this experimental Partial Clone feature for huge Git repositories, saving you time, bandwidth, and storage, one large file at a time.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681131/Blog/Hero%20Images/partial-clone-for-massive-repositories.jpg","https://about.gitlab.com/blog/partial-clone-for-massive-repositories","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How Git Partial Clone lets you fetch only the large file you need\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"James Ramsay\"}],\n        \"datePublished\": \"2020-03-13\",\n      }",{"title":1973,"description":1974,"authors":1979,"heroImage":1975,"date":1981,"body":1982,"category":14,"tags":1983},[1980],"James Ramsay","2020-03-13","\n\nThe Git project began nearly 15 years ago, on [April 7,\n2005](https://marc.info/?l=linux-kernel&m=111288700902396), and is now the\n[version control system](/topics/version-control/) of choice for developers. Yet, there are certain types of projects that\noften do not use Git, particularly projects that have many large binary files,\nsuch as video games. One reason projects with large binary files don't use Git\nis because, when a Git repository is cloned, Git will download every version of\nevery file in the repo. For most use cases, downloading this history is a\nuseful feature, but it slows cloning and fetching for projects with large binary\nfiles, assuming the project even fits on your computer.\n\n## What is Partial Clone?\n\nPartial Clone is a new feature of Git that replaces [Git\nLFS](https://git-lfs.github.com/) and makes working with very large repositories\nbetter by teaching Git how to work without downloading every file. Partial Clone\nhas been\n[years](https://public-inbox.org/git/xmqqeg4o27zw.fsf@gitster.mtv.corp.google.com/)\nin the making, with code contributions from GitLab, GitHub, Microsoft and\nGoogle. Today it is experimentally available in Git and GitLab, and can be\nenabled by administrators\n([docs](https://docs.gitlab.com/ee/topics/git/partial_clone.html)).\n\nPartial Clone speeds up fetching and cloning because less data is\ntransferred, and reduces disk usage on your local computer. For example, cloning\n[`gitlab-com/www-gitlab-com`](https://gitlab.com/gitlab-com/www-gitlab-com)\nusing Partial Clone (`--filter=blob:none`) is at least 50% faster, and transfers\n70% less data.\n\nNote: Partial Clone is one specific performance optimization for very large\nrepositories. [Sparse\nCheckout](https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout/)\nis a related optimization that is particularly focused on repositories with\ntremendously large numbers of files and revisions such as\n[Windows](https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/)\ncode base.\n\n## A brief history of large files\n\n\"What about Git LFS?\" you may ask. Doesn't LFS stand for \"large file storage\"?\n\nPreviously, extra tools were required to store large files in Git. In 2010,\n[git-annex](https://git-annex.branchable.com/) was released, and five years\nlater in 2015, [Git LFS](https://git-lfs.github.com/) was released. Both\ngit-annex and Git LFS added large file support to Git in a similar way: Instead\nof storing a large file in Git, store a pointer file that links to the large\nfile. Then, when someone needs a large file, they can download it on-demand\nusing the pointer.\n\nThe criticism of this approach is that there are now two places to store files,\nin Git or in Git LFS. Which means that everyone must remember that big files need\nto go in Git LFS to keep the Git repo small and fast. There are downsides to\nthis approach. Besides being susceptible to human error, the pointer encodes\ndecisions based on bandwidth and file type into the structure of the repository\nthat influence all the people using the repository. Our assumptions about\nbandwidth and storage are likely to change over time, and vary by the location,\nbut decisions encoded in the repository are not flexible. Administrators and\ndevelopers alike benefit from flexibility in where to store large files, and\nwhich files to download.\n\nPartial Clone solves these problems by removing the need for two classes of\nstorage, and special pointers. Let's walk through an example to understand how.\n\n## How to get started with Partial Clone\n\nLet's continue to use `gitlab-com/www-gitlab-com` as an example project, since\nit has quite a lot of images. For a larger repository, like a video game with\ndetailed textures and models that could take up a lot of disk space, the benefits will be even more significant.\n\nInstead of a vanilla `git clone`, we will include a filter spec which controls\nwhat is excluded when fetching data. In this situation, we just want to exclude\nlarge binary files. I've included `--no-checkout` so we can more clearly observe\nwhat is happening.\n\n```bash\ngit clone --filter=blob:none --no-checkout git@gitlab.com/gitlab-com/www-gitlab-com.git\n# Cloning into 'www-gitlab-com'...\n# remote: Enumerating objects: 624541, done.\n# remote: Counting objects: 100% (624541/624541), done.\n# remote: Compressing objects: 100% (151886/151886), done.\n# remote: Total 624541 (delta 432983), reused 622339 (delta 430843), pack-reused 0\n# Receiving objects: 100% (624541/624541), 74.61 MiB | 8.14 MiB/s, done.\n# Resolving deltas: 100% (432983/432983), done.\n\n```\n\nAbove we explicitly told Git not to checkout the default branch. Normally\n`checkout` doesn't require fetching any data from the server, because we have\neverything locally. When using Partial Clone, since we are deliberately not downloading everything, Git will need to fetch any missing files when doing a\ncheckout.\n\n```bash\ngit checkout master\n# remote: Enumerating objects: 12080, done.\n# remote: Counting objects: 100% (12080/12080), done.\n# remote: Compressing objects: 100% (11640/11640), done.\n# remote: Total 12080 (delta 442), reused 9773 (delta 409), pack-reused 0\n# Receiving objects: 100% (12080/12080), 1.10 GiB | 8.49 MiB/s, done.\n# Resolving deltas: 100% (442/442), done.\n# Updating files: 100% (12342/12342), done.\n# Filtering content: 100% (3/3), 131.24 MiB | 4.73 MiB/s, done.\n```\n\nIf we checkout a different branch or commit, we'll need to download more missing\nfiles.\n\n```bash\ngit checkout 92d1f39b60f957d0bc3c5621bb3e17a3984bdf72\n# remote: Enumerating objects: 1968, done.\n# remote: Counting objects: 100% (1968/1968), done.\n# remote: Compressing objects: 100% (1953/1953), done.\n# remote: Total 1968 (delta 23), reused 1623 (delta 15), pack-reused 0\n# Receiving objects: 100% (1968/1968), 327.44 MiB | 8.83 MiB/s, done.\n# Resolving deltas: 100% (23/23), done.\n# Updating files: 100% (2255/2255), done.\n# Note: switching to '92d1f39b60f957d0bc3c5621bb3e17a3984bdf72'.\n```\n\nGit remembers the filter spec we provided when cloning the repository so that\nfetching updates will also exclude large files until we need them.\n\n```bash\ngit config remote.origin.promisor\n# true\n\ngit config remote.origin.partialclonefilter\n# blob:none\n```\n\nWhen committing changes, you simply commit binary files like you would any other\nfile. There is no extra tool to install or configure, no need to treat big files\ndifferently to small files.\n\n## Network and Storage\n\nIf you are already using [Git LFS](https://git-lfs.github.com/) today, you might\nbe aware that large files are stored and transferred differently to regular Git\nobjects. On GitLab.com, Git LFS objects are stored in object storage (like AWS\nS3) rather than fast attached storage (like SSD), and transferred over HTTP even\nwhen using SSH for regular Git objects. Using object storage has the advantage\nof reducing storage costs for large binary files, while using simpler HTTP\nrequests for large downloads allows the possibility of resumable and parallel\ndownloads.\n\nPartial Clone\n[already](https://public-inbox.org/git/20190625134039.21707-1-chriscool@tuxfamily.org/)\nsupports more than one remote, and work is underway to allow large files to be\nstored in a different location such as object storage. Unlike Git LFS, however,\nthe repository or instance administrator will be able to choose which objects\nshould be stored where, and change this configuration over time if needed.\n\nFollow the epic for [improved large file\nstorage](https://gitlab.com/groups/gitlab-org/-/epics/1487) to learn more and\nfollow our progress.\n\n## Performance\n\nWhen fetching new objects from the Git server using a [filter\nspec](https://github.com/git/git/blob/v2.25.0/Documentation/rev-list-options.txt#L735)\n to exclude objects from the response, Git will check each object and exclude\n any that match the filter spec. In [Git\n 2.25](https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.25.0.txt),\n the most recent version, filtering has not been optimized for performance.\n\n[Jeff King (Peff)](https://github.com/peff/) (GitHub) recently\n[contributed](https://public-inbox.org/git/20200214182147.GA654525@coredump.intra.peff.net/)\nperformance improvements for blob size filtering, which will likely be included\nin [Git 2.26](https://gitlab.com/gitlab-org/gitaly/issues/2497), and our plan is\nto include it in GitLab 12.10 release.\n\nOptimizing the sparse filter spec option (`--filter:sparse`), which filters\nbased on file path is more complex because blobs, which contain the file\ncontent, do not include file path information. The directory structure of a\nrepository is stored in tree objects.\n\nFollow the epic for [Partial Clone performance\nimprovements](https://gitlab.com/groups/gitlab-org/-/epics/1671) to learn more\nand follow our progress.\n\n## Usability\n\nOne of the drawbacks of Git LFS was that it required installing an additional\ntool. In comparison, Partial Clone does not require any additional tools.\nHowever, it does require learning new options and configurations, such as to\nclone using the `--filter` option.\n\nWe want to make it easy for people get their work done, who simply desire Git to\njust work. They shouldn't need to work out which is the optimal blob size filter\nspec for a project? Or what even is a filter spec?  While Partial Clone remains\nexperimental, we haven't made any changes to the GitLab interface to highlight\nPartial Clone, but we are investigating this and welcome your feedback. Please\njoin the conversation on this\n[issue](https://gitlab.com/gitlab-org/gitlab/issues/207744).\n\n## File locking and tool integrations\n\nAny conversation of large binary files, particularly in regards to video\ngames is incomplete without discussing file locking and tooling integrations.\n\nUnlike plain text [source code](/solutions/source-code-management/), resolving conflicts between different versions of\na binary file is often impossible. To prevent conflicts in binary file editing,\nan exclusive file lock is used, meaning only one person at a time can edit a\nsingle file, regardless of branches. If conflicts can't be resolved, allowing multiple\nversions of a individual file to be created in parallel on different branches is a bug, not\na feature. GitLab already has basic file locking support, but it is really only\nuseful for plain text because it only applies to the default branch, and is not\nintegrated with any local tools.\n\nLocal tooling integrations are important for binary asset workflows, to\nautomatically propagate file locks to the local development environment, and to\nallow artists to work on assets without needing to use Git from the command\nline. Propagating file locks quickly to local development environments is also\nimportant because it prevents work from being wasted before it even happens.\n\nFollow the [file locking](https://gitlab.com/groups/gitlab-org/-/epics/1488) and\n[integrations](https://gitlab.com/groups/gitlab-org/-/epics/2704) epics for more\ninformation about what we're working on.\n\n## Conclusion\n\nLarge files are necessary for many projects, and Git will soon support this\nnatively, without the need for extra tools. Although Partial Clone is still an\nexperimental feature, we are making improvements with every release and the\nfeature is now ready for testing.\n\nThank you to the Git community for your work over the past years on improving\nsupport for enormous repositories. Particularly, thank you to [Jeff\nKing](https://github.com/peff/) (GitHub) and [Christian\nCouder](https://about.gitlab.com/company/team/#chriscool) (senior backend\nengineer on Gitaly at GitLab) for your early experimentation with Partial Clone,\nJonathan Tan (Google) and [Jeff Hostetler](https://github.com/jeffhostetler)\n(Microsoft) for contributing the [first\nimplementation](https://public-inbox.org/git/cover.1506714999.git.jonathantanmy@google.com/)\nof Partial Clone and promisor remotes, and the many others who've also\ncontributed.\n\nIf you are already using Partial Clone, or would like to help us test Partial\nClone on a large project, please get in touch with me, [James\nRamsay](https://about.gitlab.com/company/team/#jramsay) (group manager, product\nfor Create at GitLab), [Jordi\nMon](https://about.gitlab.com/company/team/#jordi_mon) (senior product marketing\nmanager for Dev at GitLab), or your account manager.\n\nFor more information on Partial Clone, check out [the documentation](https://docs.gitlab.com/ee/topics/git/partial_clone.html).\n\nCover image by [Simon Boxus](https://unsplash.com/@simonlerouge) on\n[Unsplash](https://unsplash.com/photos/4ftI4lCcByM)\n{: .note}\n",[699,1021],{"slug":1985,"featured":6,"template":679},"partial-clone-for-massive-repositories","content:en-us:blog:partial-clone-for-massive-repositories.yml","Partial Clone For Massive Repositories","en-us/blog/partial-clone-for-massive-repositories.yml","en-us/blog/partial-clone-for-massive-repositories",{"_path":1991,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1992,"content":1998,"config":2003,"_id":2005,"_type":16,"title":2006,"_source":17,"_file":2007,"_stem":2008,"_extension":20},"/en-us/blog/what-is-gitlab-flow",{"title":1993,"description":1994,"ogTitle":1993,"ogDescription":1994,"noIndex":6,"ogImage":1995,"ogUrl":1996,"ogSiteName":713,"ogType":714,"canonicalUrls":1996,"schema":1997},"The problem with Git flow","Learn why Git flow complicates the lifecycle and discover an alternative to streamline development.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681121/Blog/Hero%20Images/whatisgitlabflow.jpg","https://about.gitlab.com/blog/what-is-gitlab-flow","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The problem with Git flow\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2020-03-05\",\n      }",{"title":1993,"description":1994,"authors":1999,"heroImage":1995,"date":2000,"body":2001,"category":14,"tags":2002},[1917],"2020-03-05","\n  \u003Cscript type=\"application/ld+json\">\n  {\n    \"@context\": \"https://schema.org\",\n    \"@type\": \"BlogPosting\",\n    \"mainEntityOfPage\": {\n      \"@type\": \"WebPage\",\n      \"@id\": \"https://about.gitlab.com/blog/what-is-gitlab-flow/\"\n    },\n    \"headline\": \"The problem with Git flow\",\n    \"description\": \"Learn why Git flow complicates the lifecycle and discover an alternative to streamline development.\",\n    \"image\": \"https://about.gitlab.com/images/blogimages/whatisgitlabflow.jpg\",\n    \"author\": {\n      \"@type\": \"Organization\",\n      \"name\": \"GitLab\"\n    },\n    \"publisher\": {\n      \"@type\": \"Organization\",\n      \"name\": \"\",\n      \"logo\": {\n        \"@type\": \"ImageObject\",\n        \"url\": \"\"\n      }\n    },\n    \"datePublished\": \"2020-03-05\"\n  }\n  \u003C/script>\n\nSometimes, you can have too much of a good thing. That’s certainly true with [Git flow](https://nvie.com/posts/a-successful-git-branching-model/), a well-known software development workflow that offers several options but can bog down users.\n\nWe developed [GitLab Flow](/topics/version-control/what-is-gitlab-flow/) as the solution to eliminate messy complexity and streamline the development process. [GitLab Flow](/topics/version-control/what-is-gitlab-flow/) brings issue tracking to the Git workflow, simplifying the process and removing confusion.\n\n## The problem with Git flow\n\nTo understand how GitLab Flow works, it’s helpful to start by looking at the problems it tries to solve. In Git flow, there are two main pain points, both of which involve unnecessary branch switching.\n\nGit flow forces developers to use the `develop` branch rather than the `master` or default branch. Because most tools default to using the master, there’s a significant amount of branch switching involved. Another frustrating aspect are `release` and [hotfix](https://stackoverflow.com/questions/46729813/how-to-use-a-Gitflow-hotfix-branch) branches, which are overkill for most organizations and completely unnecessary in companies practicing continuous integration and continuous delivery.\n\nThat brings us to GitLab Flow, a simpler workflow and branching model that keeps everything simple and inclusive.\n\n## GitLab Flow: a streamlined branching strategy\n\nGitLab Flow is a simpler alternative to Git flow that combines feature-driven development and feature branches with issue tracking. GitLab Flow integrates the Git workflow with an issue tracking system, offering a simple, transparent, and effective way to work with Git.\n\nGitLab Flow is an approach to make the relationship between the code and the issue tracker more transparent. Each change to the codebase starts with an issue in the issue tracking system. When you’re done coding or want to discuss the code, you can open a merge request. When the code is ready, the reviewer will merge the branch into master, creating a merge commit that makes this event easily visible in the future. Using GitLab Flow, teams can deploy a new version of code by merging master into a `production` branch, enabling them to quickly identify what code is in the production environment. In this workflow, commits only flow downstream, ensuring that everything is tested in all environments.\n\nGitLab Flow prevents the overhead of releasing, tagging, and merging that accompanies Git flow.\n\nGitLab Flow in a nutshell:\n- All features and fixes first go to master\n- Allows for `production` or `stable` branches\n- Bug fixes/hotfix patches are cherry-picked from master\n\nRead more on here [GitLab Flow best practicies](/topics/version-control/what-are-gitlab-flow-best-practices/)\n\n## Breaking down the 10 stages of software development\n\nGitLab Flow is a way to move from the idea stage to production, all while keeping everyone informed and productive. We identified [10 key stages](/topics/version-control/what-is-gitlab-flow/#stages-of-software-development) of the development process that must happen in order for software to get into production. GitLab Flow makes it easy to account for all of them, while continuing to provide full visibility into the development lifecycle.\n\nBroadly speaking, GitLab Flow is broken down into three main areas: `feature` branch, `production` branch, and `release` branch.\n\nA `feature` branch is where the serious development work occurs. A developer creates a feature or bug fix branch and does all the work there rather than on a master branch. Once the work is complete, the developer creates a merge request to merge the work into the master branch.\n\nThe `production` branch is essentially a monolith – a single long-running production `release` branch rather than individual branches. It’s possible to create a tag for each deployable version to keep track of those details easily.\n\nThe last piece, the `release` branch, is key if you release software to customers. With every new release, you’ll create a stable branch from master and decide on a tag. If you need to do a patch release, be sure to cherry-pick critical bug fixes first, and don’t commit them directly to the stable or long-lived branch.\n\n## Follow the rules\n\nWant to get the most out of GitLab Flow? Our CEO [Sid Sijbrandij](/company/team/#sytses) came up with [11 rules teams should always follow to achieve maximum efficiency](/topics/version-control/what-are-gitlab-flow-best-practices/). The article is worth a read in its entirety, but here are a few rules that are timely reminders of the importance of testing, even in a [CI environment](/solutions/continuous-integration/):\n\n* **Test all commits**: Don’t wait to test until everything has been merged into `master`. Test commits along the way to catch problems earlier in the process.\n* **And run _all_ tests on all the commits**, even if you have to run tests in parallel.\n* **Code reviews > merging into `master`.** Why wait? \"Don’t test everything at the end of the week,\" Sid writes. \"Do it on the spot, because you'll be more likely to catch things that could cause problems, and others will also be working to come up with solutions.\"\n\n## Take a deep dive\n\nTake a look at GitLab Flow in action! 🍿\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/InKNIvky2KE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n\n\nCover image by [Fabio Bracht](https://unsplash.com/@bracht?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/_z0DiiaIhB4)\n{: .note}\n",[699,1921,1541],{"slug":2004,"featured":6,"template":679},"what-is-gitlab-flow","content:en-us:blog:what-is-gitlab-flow.yml","What Is Gitlab Flow","en-us/blog/what-is-gitlab-flow.yml","en-us/blog/what-is-gitlab-flow",{"_path":2010,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2011,"content":2017,"config":2026,"_id":2028,"_type":16,"title":2029,"_source":17,"_file":2030,"_stem":2031,"_extension":20},"/en-us/blog/gitlab-taught-in-korean-uni",{"title":2012,"description":2013,"ogTitle":2012,"ogDescription":2013,"noIndex":6,"ogImage":2014,"ogUrl":2015,"ogSiteName":713,"ogType":714,"canonicalUrls":2015,"schema":2016},"Schooled in GitLab: Teaching our handbook at a South Korean university","Students at Hankuk University of Foreign Studies tackled our handbook. The students' favorite topics were compensation and remote work.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673044/Blog/Hero%20Images/books-internship-post.jpg","https://about.gitlab.com/blog/gitlab-taught-in-korean-uni","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Schooled in GitLab: Teaching our handbook at a South Korean university\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Guenjun Yoo\"}],\n        \"datePublished\": \"2020-01-29\",\n      }",{"title":2012,"description":2013,"authors":2018,"heroImage":2014,"date":2020,"body":2021,"category":14,"tags":2022},[2019],"Guenjun Yoo","2020-01-29","\nBusiness students at [Hankuk University of Foreign Studies](http://mis.hufs.ac.kr/) in Seoul, South Korea are studying the GitLab handbook and business model. The students are enthusiastic about GitLab and its story, says lecturer SanJoon Song in an email interview, but there was one problem: Our 3,000+ page handbook is a lot to swallow in one semester.\n\nSo Song had the class divide the handbook into 15 different categories, which different groups of students researched over the course of the semester. At the end of the term, the groups presented a summary of their category to the class.\n\n“Many engineers in Korea said that the GitLab handbook is good to read before starting up a business,” says Song. “However, there is a lot of reading in the handbook; too many pages for me.”\n\nThe level of transparency in the handbook was a revelation to Song and his students.\n\n“We didn't study [the handbook] only to focus on the content itself, but we tried to understand and share about the context of handbook; what conventions GitLab has and what protocols GitLab is trying to develop with its employees by this handbook,” says Song. “In Korea, this is very unusual to share such details of company goals and protocols with entire employees by handbook and for me, this approach is very new and fresh.”\n\n## Inside information\n\nSong was very surprised by how much “insider” information is available in our handbook and says he’s particularly amazed by the detailed explanations of what to do if things go wrong.\n\nOn the other hand, his students were most impressed by the details on [compensation](/handbook/total-rewards/compensation/compensation-calculator/calculator/) and incentives in the handbook, followed closely by the idea of remote work.\n\n“Personally I liked the concept of [‘accept mistakes’](https://handbook.gitlab.com/handbook/values/#accept-mistakes) in the efficiency section,” says Song. “We also talked a lot about GitLab’s [six values](https://handbook.gitlab.com/handbook/values/).”\n\n![Breaking down the handbook](https://about.gitlab.com/images/blogimages/studyingthehandbook.jpg){: .shadow.medium.center}\nStudents in Song's class breaking down the handbook.\n{: .note.text-center}\n\nRemote work was also a big topic of discussion in Song's classroom.\n\n\"Many Koreans are interested in remote work,\" says Song. \"It is really great that people can work anywhere, anytime without having the stress of commuting. Remote work is not common in Korea yet. Only a few software developers are allowed to work from home but that is also partial and in a limited environment only. Many students also want to do the remote work but this is still kind of a dream.”\n\nSong is currently teaching a second GitLab-focused class, this time diving into project management and DevOps by looking at our product and Pivotal Labs. If there is one benefit Song thinks his students have taken away from studying GitLab it’s the importance of communication.\n\n“Communication between employees is one of the most important matters,\" says Song. \"By studying the GitLab handbook, my students and I learned an efficient way of communication between the employer and employees. The handbook explicitly shows how GitLab is trying to do the best way of communication between stakeholders; what is the company goal, why we established the goal and how we are achieving the goal.”\n\nSong hopes to inspire a future generation of entrepreneurs by studying the GitLab handbook in the classroom.\n\n“My students have studied the GitLab handbook for one semester. I hope this study can be their reference when they start their startup, so they can create their company goals and prototype in the direction of success, like GitLab.\"\n\n_If you’re interested in seeing more of Song’s curriculum, he shared it\n[here](https://docs.google.com/document/d/1u5J6Ypj6zwQJVjmrl1wd0eIv7Q_TYLJysDquhGMJimA/edit). You'll need to scroll down a bit._\n\nCover image by [Patrick Tomasso](https://unsplash.com/@impatrickt) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[2023,268,1434,675,2024,2025],"careers","remote work","startups",{"slug":2027,"featured":6,"template":679},"gitlab-taught-in-korean-uni","content:en-us:blog:gitlab-taught-in-korean-uni.yml","Gitlab Taught In Korean Uni","en-us/blog/gitlab-taught-in-korean-uni.yml","en-us/blog/gitlab-taught-in-korean-uni",{"_path":2033,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2034,"content":2040,"config":2047,"_id":2049,"_type":16,"title":2050,"_source":17,"_file":2051,"_stem":2052,"_extension":20},"/en-us/blog/kubecon-na-2019-are-you-about-to-break-prod",{"title":2035,"description":2036,"ogTitle":2035,"ogDescription":2036,"noIndex":6,"ogImage":2037,"ogUrl":2038,"ogSiteName":713,"ogType":714,"canonicalUrls":2038,"schema":2039},"KubeCon NA: Are you about to break Prod?","Use Pulumi and GitLab to build a pipeline that validates your application, infrastructure, and deployment process.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666262/Blog/Hero%20Images/default-blog-image.png","https://about.gitlab.com/blog/kubecon-na-2019-are-you-about-to-break-prod","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"KubeCon NA: Are you about to break Prod?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Erin Krengel, Pulumi\"}],\n        \"datePublished\": \"2020-01-27\",\n      }",{"title":2035,"description":2036,"authors":2041,"heroImage":2037,"date":2043,"body":2044,"category":14,"tags":2045},[2042],"Erin Krengel, Pulumi","2020-01-27","\n\nA couple of months ago, my [Pulumi](https://www.pulumi.com/) colleague Sean Holung, staff sofware engineer, and I had the opportunity to present [\"Are you about to break prod? Acceptance Testing with Ephemeral Environments\"](https://www.youtube.com/watch?v=jAQhDZiRzBQ) at KubeCon NA 2019. In this talk, we covered what is an ephemeral environment, how to create one, and then we walked the audience through a concrete example. Given our limited time, we had to move quickly through a ton of information. This post will recap our presentation and add a few more details we weren't able to cover.\n\nAs software engineers, our job is to deliver business value. To do this, we need to be delivering software both quickly and reliably.\n\nSo the question we ask you is: are you about to break prod? Everyone will break production at some point because there are things we miss. As independent software lead Alexandra Johnson sums up so well in a tweet: \"Failures are part of the cost of building and shipping large systems.\" Building a robust pipeline allows us to move quickly in the case of failure and gain confidence around making changes to our infrastructure and applications.\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">Big takeaway from \u003Ca href=\"https://twitter.com/hashtag/KubeCon?src=hash&ref_src=twsrc%5Etfw\">#KubeCon\u003C/a>: none of us want to break prod, but failures are part of the cost of building and shipping large systems. Using tools like \u003Ca href=\"https://twitter.com/hashtag/AcceptanceTesting?src=hash&ref_src=twsrc%5Etfw\">#AcceptanceTesting\u003C/a> (\u003Ca href=\"https://twitter.com/eckrengel?ref_src=twsrc%5Etfw\">@eckrengel\u003C/a>) and \u003Ca href=\"https://twitter.com/hashtag/ChaosEngineering?src=hash&ref_src=twsrc%5Etfw\">#ChaosEngineering\u003C/a> (\u003Ca href=\"https://twitter.com/Ana_M_Medina?ref_src=twsrc%5Etfw\">@Ana_M_Medina\u003C/a>) can increase your confidence in your infrastructure changes!\u003C/p>— Alexandra Johnson (@alexandraj777) \u003Ca href=\"https://twitter.com/alexandraj777/status/1198373475049623552?ref_src=twsrc%5Etfw\">November 23, 2019\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\nWith this in mind, we use Pulumi and GitLab to build a pipeline that validates both our application, infrastructure, and deployment process. \n\n## Ephemeral environments\n\nWhat is an ephemeral environment? It is a short-lived environment that mimics a production environment. To maintain agility, boundaries are defined in the environment to only encompass the first-level dependencies of the particular microservice that is being deployed. It means you don't have to spin up every single microservice or piece of infrastructure that's running in production. Yet you may need to spin up extra pieces of infrastructure to properly test the microservice. For example, you may need to create a subscription to pull from a PubSub topic your microservice writes to. This subscription would allow your acceptance tests to pull from a topic in order to validate an outbound message is published.\n\n## Why this is important\n\nInfrastructure is a key part of an application's behavior. The architecture and requirements are continually evolving. How can you incorporate these into a testing suite to give us a high degree of confidence?\n\nEphemeral environments allow you to integrate infrastructure and deployment processes into a testing suite. They ensure your testing environment is always in-sync with production and therefore allow you to iterate quickly to meet new requirements.\n\nEphemeral environments also encourage you to lean on automated tests over manual tests. If you use ephemeral environments as a replacement for a testing environment, there is not enough time to go in and run a manual check. Shifting your mindset to automated tests can be challenging, yet it's imperative that we do so. Automated tests guarantee your application behaves as expected today as well as months from now when you're out on vacation.\n\n## Our demo application\n\nTo demonstrate the effectiveness of integrating acceptance testing with ephemeral environments into your deployment process, we created a simple demo application. The service is written in Go and accepts a message on the `/message` endpoint, then places it in a storage bucket and sends a notification about the new object on a PubSub topic. The code for this application lives in our [main.go](https://gitlab.com/rocore/demo-app/blob/master/main.go) file. While you can walk through this code yourself, the most important thing to call out is that our application is *configurable*. This means we take configuration in at the very beginning of our main function and shut down the application if the values are not present.\n\n```go\nfunc main() {\n    ...\n\t// Get configuration from environment variables. These are\n\t// required configuration values, so we use an helper\n\t// function get the values and exit if the value is not set.\n\tproject := getConfigurationValue(\"PROJECT\")\n\ttopicName := getConfigurationValue(\"TOPIC\")\n\tbucketName := getConfigurationValue(\"BUCKET\")\n    ...\n}\n\nfunc getConfigurationValue(envVar string) string {\n\tvalue := os.Getenv(envVar)\n\tif value == \"\" {\n\t\tlog.Fatalf(\"%s not set\", envVar)\n\t}\n\tlog.Printf(\"%s: %s\", envVar, value)\n\treturn value\n}\n```\n\n### Infrastructure\n\nThere are many pieces of infrastructure to spin up and we can use Pulumi to easily wire it all together. Our architecture looks like this:\n\n![Pulumi Architecture](https://about.gitlab.com/images/blogimages/pulumidemoarch.jpg){: .medium.center}\n\nYou can check out the Pulumi code that we use to reproduce both our ephemeral environments as well as production in the [infrastructure/index.ts](https://gitlab.com/rocore/demo-app/blob/master/infrastructure/index.ts) file. The neat thing about using Pulumi is that we can create the Google Cloud Platform (GCP) resources we need and then directly reference them in our Kubernetes deployment. Using Pulumi ensures we're always configuring our application with the correct GCP resources for that environment.\n\nFor example, in our Kubernetes deployment, we set the environment variables by using the topic and bucket variables created just above.\n\n```typescript\n// Create a K8s Deployment for our application.\nconst appLabels = { appClass: name };\nconst deployment = new k8s.apps.v1.Deployment(name, {\n    metadata: { labels: appLabels },\n    spec: {\n        selector: { matchLabels: appLabels },\n        template: {\n            metadata: { labels: appLabels },\n            spec: {\n                containers: [{\n                    ...\n                    env: [\n                        { name: \"TOPIC\", value: topic.name }, // referencing topic just created\n                        { name: \"BUCKET\", value: bucket.name }, // referencing bucket just created\n                        { name: \"PROJECT\", value: project },\n                        {\n                            name: \"GOOGLE_APPLICATION_CREDENTIALS\",\n                            value: \"/var/secrets/google/key.json\"\n                        },\n                    ],\n                    ...\n                }]\n            }\n        }\n    },\n});\n```\n\n### Acceptance tests\n\nThe acceptance tests validate that our service, when stood up, functions as expected. They are run against an ephemeral environment. The tests live in the `acceptance/acceptance_test.go` [file](https://gitlab.com/rocore/demo-app/blob/master/acceptance/acceptance_test.go). You'll notice we're once again using the helper function `getConfigurationValue`. Our acceptance test must also be configured to ensure they're validating against the correct resources for that particular ephemeral environment.\n\nSince the service is only accessible from within the Kubernetes cluster, we use a Kubernetes job to run our acceptance tests. Using a Kubernetes job is a good technique to use when your CI is running externally, such as from GitLab, and you do not want to expose your service publicly. Our ephemeral environment plus acceptance test looks like this:\n\n![Acceptance Tests](https://about.gitlab.com/images/blogimages/pulumiacceptancetestarch.jpg){: .medium.center}\n \nWe spin up a Kubernetes Job and additional resources by using an if statement at the bottom of our `infrastructure/index.ts` file. The conditional depends on the environment's name as follows:\n\n```typescript\n// If it's a test environment, set up acceptance tests.\nlet job: k8s.batch.v1.Job | undefined;\nif (ENV.startsWith(\"test\")) {\n    job = acceptance.setupAcceptanceTests({\n        ...\n    });\n}\n\n// Export the acceptance job name, so we can get the logs from our\n// acceptance tests.\nexport const acceptanceJobName = job ? job.metadata.name : \"unapplicable\";\n```\n\nThat covers all the major aspects of our application and infrastructure, and if you'd like to view the code in detail, it is available in our `demo-app` [GitLab repository](https://gitlab.com/rocore/demo-app).\n\n## Our pipeline\n\nWhen developing a new service, we must establish a solid deployment strategy upfront. We want to make sure we're building in quality from day one. As we develop the service, we can add acceptance tests for every feature we add while the context and requirements are still fresh in our minds. This ensures we have thorough coverage of our app's functionality.\n\nWe used GitLab to set up our pipeline. We chose GitLab because it's straightforward to set up and allows us to run our pipeline on our Docker image of choice. We use a [base-image](https://gitlab.com/rocore/global-infra/blob/master/base-image/Dockerfile) that has all our dependencies installed and then reference that Docker image and tag in our `demo-app` pipeline. The Docker image allows us to bundle and version the dependencies for building our application and infrastructure.\n\n![GitLab Pipelines](https://about.gitlab.com/images/blogimages/pulumibloggitlabci.png){: .shadow.medium.center}\n \n1. **Test and Build** - This runs our unit tests and builds both our application and acceptance test images. To build our images, we used [Kaniko](https://github.com/GoogleContainerTools/kaniko), a tool for building images within a container or Kubernetes cluster. GitLab has excellent documentation on [how to incorporate Kaniko](https://docs.gitlab.com/ee/ci/docker/using_kaniko.html) into your pipeline. The application image is an immutable image that is used for both running our acceptance tests and deploying to production.\n1. **Acceptance Test** - This is what spins up our ephemeral environments and runs our acceptance tests. This acts as a quality gate catching issues before production.\n\n    Our ephemeral environment and Kubernetes job are all spun up in the `script` portion of the acceptance test job definition. We do a bit of setup for our new acceptance test stack and then run `pulumi up`. Here is the print out from our acceptance tests.\n\n    ```bash\n    ...\n    $ pulumi stack init rocore/$ENV-app\n    Logging in using access token from PULUMI_ACCESS_TOKEN\n    Created stack 'rocore/test-96425413-app'\n    $ pulumi config set DOCKER_TAG $DOCKER_TAG\n    $ pulumi config set ENV $ENV\n    $ pulumi config set gcp:project rocore-k8s\n    $ pulumi config set gcp:zone us-west1-a\n    $ pulumi up --skip-preview\n    Updating (rocore/test-96425413-app):\n    ...\n    Resources:\n        + 16 created\n\n    Duration: 4m10s\n\n    Permalink: https://app.pulumi.com/rocore/demo-app/test-96425413-app/updates/1\n    ```\n\n    The `after_script` destroys our stack as well as prints the logs of both our Kubernetes job and deployment, which help with debugging if our tests were to fail. We use the `after_script` to make sure that we always clean up and print logs even when our acceptance tests fail.\n    \n    ```bash\n    ...\n    $ pulumi stack select rocore/$ENV-app\n    $ kubectl logs -n rocore --selector=appClass=$ENV-demo-app-acc-test --tail=200\n    === RUN   TestSimpleHappyPath\n    === RUN   TestSimpleHappyPath/message_is_sent_to_PubSub_topic\n    === RUN   TestSimpleHappyPath/message_is_stored_in_bucket\n    ",[2046,780,675,110,232,278],"testing",{"slug":2048,"featured":6,"template":679},"kubecon-na-2019-are-you-about-to-break-prod","content:en-us:blog:kubecon-na-2019-are-you-about-to-break-prod.yml","Kubecon Na 2019 Are You About To Break Prod","en-us/blog/kubecon-na-2019-are-you-about-to-break-prod.yml","en-us/blog/kubecon-na-2019-are-you-about-to-break-prod",{"_path":2054,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2055,"content":2061,"config":2067,"_id":2069,"_type":16,"title":2070,"_source":17,"_file":2071,"_stem":2072,"_extension":20},"/en-us/blog/whitesource-gitlab-security-integration",{"title":2056,"description":2057,"ogTitle":2056,"ogDescription":2057,"noIndex":6,"ogImage":2058,"ogUrl":2059,"ogSiteName":713,"ogType":714,"canonicalUrls":2059,"schema":2060},"GitLab and WhiteSource: the easy way to secure your open source code","How we integrated with GitLab's security dashboards to make it easier to secure your open source code earlier in the dev lifecycle","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681016/Blog/Hero%20Images/gitlab-whitesource.png","https://about.gitlab.com/blog/whitesource-gitlab-security-integration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab and WhiteSource: the easy way to secure your open source code\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Guy Bar-Gil, Product Manager at WhiteSource\"}],\n        \"datePublished\": \"2020-01-14\",\n      }",{"title":2056,"description":2057,"authors":2062,"heroImage":2058,"date":2064,"body":2065,"category":14,"tags":2066},[2063],"Guy Bar-Gil, Product Manager at WhiteSource","2020-01-14","\n\nDevelopment teams have gotten used to relying on open source components to build powerful innovative software at a neck-breaking pace. The speed is certainly accelerating, but what about the security of our applications? Unfortunately, this is often treated as an afterthought, which is not surprising since security has traditionally been seen as a tiresome and time-consuming task that comes after the development stage and slows down production.\n\nIn an attempt to keep security up to speed with the pace of development, organizations are realizing that it can no longer be introduced in the later stages of the software development lifecycle (SDLC). Instead, fusing security into the earlier stages of the SDLC can enable development teams to detect and remediate vulnerabilities when they are significantly easier, quicker and cheaper to fix.\n\nBut how can we integrate security into our development process without adding more work and slowing down our pace?\n\nWell that's where GitLab and WhiteSource come in.\n\n## Secure open source code while in your GitLab UI\n\nWhiteSource has leveraged GitLab's Open Core to empower developers with the tools needed to find and fix open source vulnerabilities. The integration provides developer-focused security tools that operate within the native coding environment and within the [GitLab CI/CD pipeline](/topics/ci-cd/), allowing them to continuously address security without having to compromise on agility.\n\nWith the newest integration to GitLab Ultimate, developers gain richer insight into vulnerable open source components discovered by WhiteSource right in the merge request pipeline. At the same time security pros can see this in the GitLab Security Dashboard alongside scan results from SAST, DAST, containers, and license compliance. WhiteSource supports many more languages and provides richer dependency insight than GitLab alone. With GitLab, both security users and developers can see new, unresolved vulnerabilities for every code commit, with actionable insights on vulnerable open source libraries as well as all of their dependencies as soon as they are added to their projects.\n\n## Ensuring a secure future, together\n\nWith our partnership, we want to ensure that developers are able to harness the power of open source to create innovative products without having to compromise on security, speed, or agility.\n\n## So, what's next?\n\nVery soon, we'll be sharing a blog post with a step-by-step guide on how to integrate WhiteSource into your native GitLab environment. The best tips and tricks will be included to ensure you'll be able to secure your open source components freely and fearlessly.\n",[232,675,843],{"slug":2068,"featured":6,"template":679},"whitesource-gitlab-security-integration","content:en-us:blog:whitesource-gitlab-security-integration.yml","Whitesource Gitlab Security Integration","en-us/blog/whitesource-gitlab-security-integration.yml","en-us/blog/whitesource-gitlab-security-integration",{"_path":2074,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2075,"content":2081,"config":2088,"_id":2090,"_type":16,"title":2091,"_source":17,"_file":2092,"_stem":2093,"_extension":20},"/en-us/blog/how-enterprise-dev-teams-use-gitlab-mattermost-chatops",{"title":2076,"description":2077,"ogTitle":2076,"ogDescription":2077,"noIndex":6,"ogImage":2078,"ogUrl":2079,"ogSiteName":713,"ogType":714,"canonicalUrls":2079,"schema":2080},"Teams speed development with GitLab & Mattermost ChatOps","A complete DevOps toolchain plus open source messaging and ChatOps – what’s not to love?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680983/Blog/Hero%20Images/mattermost-gitlab.png","https://about.gitlab.com/blog/how-enterprise-dev-teams-use-gitlab-mattermost-chatops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How enterprise dev teams use GitLab and Mattermost ChatOps to accelerate development\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jason Blais – Mattermost\"}],\n        \"datePublished\": \"2020-01-13\",\n      }",{"title":2082,"description":2077,"authors":2083,"heroImage":2078,"date":2085,"body":2086,"category":14,"tags":2087},"How enterprise dev teams use GitLab and Mattermost ChatOps to accelerate development",[2084],"Jason Blais – Mattermost","2020-01-13","\n\nThere has never been more pressure on development teams to build software faster and more efficiently. The rise in popularity of DevOps has largely been the result of its promise to speed up dev cycles, increase agility, and help teams resolve issues more quickly. And while the availability and sophistication of DevOps tools have improved greatly in the last few years, simply choosing the latest and greatest tools is no guarantee of a smooth, problem-free development lifecycle.\n\n## Why GitLab\n\nIn an ecosystem with exponentially increasing choice and complexity, GitLab provides a complete open source [DevOps platform](/solutions/devops-platform/) that can speed up cycles, reduce development costs, and improve developer efficiency. From planning and code to deployment and monitoring (and back again), GitLab brings a myriad of tools together into one open source toolset.\n\n## Why Mattermost ChatOps\n\nWe’re big fans of GitLab here at Mattermost, which is why Mattermost is packaged with GitLab Omnibus and why we work to make sure Mattermost is easy to [set up with GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master/doc/gitlab-mattermost).\n\n[Mattermost’s open source ChatOps platform](https://mattermost.com/blog/introducing-mattermost-chatops/) allows you to surface relevant information to your team and enables you to take action directly where you’re having conversations. When an issue comes in, a ChatOps workflow can alert relevant team members, who all work together to make a fix directly within Mattermost.\n\nChatOps provides a method to interact with CI/CD jobs through messaging. Many organizations’ discussion, collaboration, and troubleshooting is taking place in messaging services these days, and having a method to run CI/CD jobs with output posted back to the channel can significantly accelerate a team’s workflow. ChatOps not only increases communication and collaboration, but a searchable history of the conversations associated with your development cycle increases transparency and creates a repository of valuable information for the team.\n\n## Mattermost + GitLab\n\nA complete DevOps toolchain plus open source messaging and ChatOps – what’s not to love? With GitLab and Mattermost, teams can not only simplify their DevOps process, but also bring their processes into the same chat interface where team members are discussing issues, collaborating, and making decisions.\n\nHere are a couple of examples of how development teams use Mattermost and GitLab together to accelerate developer productivity through ChatOps.\n\n### itk uses GitLab and Mattermost to ship more code on time and 6x production deployments per year\n\n[Itk](https://www.itk.fr/en/), based in Montpellier, France, develops tools and applications to help farmers optimize yields, increase the quality of crops, and manage risks more effectively.\n\nThey began using GitLab around 2014 and primarily used a legacy chat tool for day-to-day collaboration, messaging, and video calling. However, as the company grew, this tool didn’t scale with them; there was no persistent, easily searchable messaging, and collaboration across the team became more difficult. They began to look for an alternative.\n\nShortly thereafter, they discovered that the GitLab Omnibus package ships with an open source messaging platform for developers: Mattermost. They immediately fell in love with its easy code-sharing capabilities – including automatic syntax highlighting and full Markdown support, and the ease of sharing knowledge, searching past conversations, and collaborating on ideas across the team to develop new solutions all integrated together with GitLab.\n\nBefore switching to Mattermost, team members hadn’t been able to easily get notified about their development process. But they wanted to be able to visibly track projects, merge requests, and other activities from GitLab.\n\nThis is when Romain Maneschi, a software developer at itk, began writing a GitLab plugin for Mattermost that would further enable his team to subscribe to GitLab notifications in Mattermost and receive notifications about new issue assignments and review requests in one place.\n\nToday, [the plugin supports](https://github.com/mattermost/mattermost-plugin-gitlab):\n\n- **Daily reminders** – get informed on what issues and merge requests need your attention\n- **Notifications** – get notified in Mattermost when someone mentions you, requests your review, or assigns an issue to you on GitLab\n- **Sidebar buttons** – stay up-to-date with how many reviews, unread messages, assignments and open merge requests you have with buttons in the Mattermost sidebar\n- **Subscribe to projects** – use slash commands to subscribe a Mattermost channel to receive notifications of new merge requests or issues in a GitLab project\n\nNow, his whole company uses both GitLab and Mattermost to accelerate workflows through ChatOps. As a result, they now ship more code on time, resulting in 3x growth in the number of projects and microservices managed by the team and 6x growth in the number of production deployments within a year – all while growing their dev and agronomist teams by 5x.\n\n![GitLab Mattermost plugin](https://about.gitlab.com/images/blogimages/gitlab-mattermost-plugin.png){: .shadow.medium.center}\n\u003C!-- image: https://user-images.githubusercontent.com/13119842/70714554-5b52cc80-1cb6-11ea-9cd6-705a68f9ac1b.png -->\n\n### A software development company increases productivity through better transparency and visibility into code and configuration changes\n\nA software development and data services company based in the state of Maryland has also rolled out Mattermost integrated with GitLab to increase productivity and seamlessly collaborate.  They provide analytics, data management, and software development services to biomedical researchers and organizations worldwide.\n\nGitLab is heavily used across their team and they consider it a huge asset in their DevOps workflows.\n\nThey have also integrated GitLab and Mattermost together by pushing GitLab commits to a single Mattermost channel via webhooks, enabling senior management to get a bird’s-eye view of everything that’s rolling through in a given day. It includes updates for configuration management and version control, giving a snapshot of different changes made to internal infrastructure and systems throughout the day.\n\nThe team has also set up separate “Heartbeat” channels to send notifications on application events. Having these messages funnel to specific Heartbeat channels avoids distracting the flow of conversations in regular project collaboration channels while empowering team members to jump on issues posted in the Heartbeat channels.\n\nOne of the key benefits this integration brings to the team is the visibility of changes made to versions and configuration management in real time; as soon as a change is committed and pushed live, a notification is sent to the Heartbeat channel which anyone can subscribe to. No more switching between apps, asking team members, or tracking down commits – it’s now all in one place inside Mattermost while configuration management and app development takes place in GitLab.\n\n### GitLab and Mattermost ChatOps improve transparency and productivity to accelerate development\n\nMattermost [ships as part of the GitLab Omnibus package](https://docs.gitlab.com/omnibus/gitlab-mattermost/), providing out-of-the box support for GitLab SSO, pre-packaged GitLab integrations, and PostgreSQL support, along with a Prometheus integration that enables systems monitoring and [incident response management](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#taking-action-on-incidents). Finally, Mattermost can now also be deployed [with GitLab Cloud Native](https://docs.mattermost.com/install/install-mmte-helm-gitlab-helm.html).\n\nThere’s never been a better time for DevOps teams to get the full benefits of open source ChatOps. Try it out by installing GitLab Omnibus with Mattermost today.",[864,232,675],{"slug":2089,"featured":6,"template":679},"how-enterprise-dev-teams-use-gitlab-mattermost-chatops","content:en-us:blog:how-enterprise-dev-teams-use-gitlab-mattermost-chatops.yml","How Enterprise Dev Teams Use Gitlab Mattermost Chatops","en-us/blog/how-enterprise-dev-teams-use-gitlab-mattermost-chatops.yml","en-us/blog/how-enterprise-dev-teams-use-gitlab-mattermost-chatops",{"_path":2095,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2096,"content":2102,"config":2108,"_id":2110,"_type":16,"title":2111,"_source":17,"_file":2112,"_stem":2113,"_extension":20},"/en-us/blog/athlinks-cuts-runtime-in-half-with-giltab",{"title":2097,"description":2098,"ogTitle":2097,"ogDescription":2098,"noIndex":6,"ogImage":2099,"ogUrl":2100,"ogSiteName":713,"ogType":714,"canonicalUrls":2100,"schema":2101},"Athlinks cuts runtime in half with GitLab","Athlinks, a time management solution platform, shares how moving from Jenkins to GitLab cut CI runtimes in half.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671909/Blog/Hero%20Images/Athlinks_running.jpg","https://about.gitlab.com/blog/athlinks-cuts-runtime-in-half-with-giltab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Athlinks cuts runtime in half with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brein Matturro\"}],\n        \"datePublished\": \"2019-12-17\",\n      }",{"title":2097,"description":2098,"authors":2103,"heroImage":2099,"date":2104,"body":2105,"category":14,"tags":2106},[1958],"2019-12-17","\nIf you’ve ever run a [Spartan race](https://www.spartan.com/en), then you’ve likely used Athlinks, the only suite of time management solutions for a variety of racing events. The [Athlinks](https://www.athlinks.com) platform includes race registration, timing, scoring, results -- everything from the check-in process to the orange wrist bands worn by participants. The solution stores over 300 million race results at any given time.\n\n## Athlinks previous DevOps tools run short\n\nThe Athlinks DevOps team previously had experience with several Agile planning tools, including Jira, Rally, and VersionOne. All of the tools they tried didn’t exactly fit what the team needed. They were looking for a tool that offers transparency and a voice for other parts of the business. “(We wanted) to give transparency and a voice to what engineering is working on so that other departments can have input into what is going on,” says Christopher Annannie, engineering manager, Athlinks.\n\n## Athlinks sprint to GitLab CI from Jenkins\n\nAthlinks started using GitLab CE in 2015, migrating over from GitHub. In January of 2018, the team adopted EE and after doing a GitLab CI proof of concept, they moved to Ultimate and away from [Jenkins](/blog/migrating-from-jenkins/). “We quickly discovered that we really wanted the full suite of tools for the Agile and the product side, so we went to GitLab Ultimate,” explains Aaron Rorvig, DevOps manager.\n\nThe group previously had about 300 jobs in Jenkins and now are at less than 40. “We use a wide variety of languages and technologies -- pretty much every operating system, both Android and iOS. We’re all over the place and we use GitLab CI for all of it,” Aaron says. The Athlinks team estimates a 50% savings across the board, both in code and in time spent running jobs.\n\n## A win for Athlinks collaboration and communication\n\nSince all of the issues, the code, and [CI pipelines](/blog/defend-cicd-security/) are inside of GitLab, it provides a single view from start to finish. Each team can view all the issues and the labeling helps everyone understand what stage each project is in, how much work has been done, and what the next steps are. “GitLab is not necessarily all that opinionated about how you do issue tracking,” Christopher says. Everything can be tracked, even when the teams don’t use the same issue tracking, it can all exist in one place.\n\nThe issue templates provide structure for the all departments to understand what they need to fill out. “Engineering will get to it quicker without so much back and forth before a problem is actually solved,” Christopher says.\n\nThe communication among the marketing, DevOps and engineering teams is improving. “We’re getting marketing involved in this so we get better about communicating all the new features we’ve deployed this month, so that timers, race directors, and athletes will actually know about the work we’re doing,” Christopher says.\n\nWant to learn more about Athlink’s transition from Jenkins to GitLab? Watch the presentation here:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Dy_a79_PsNk\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nCover image by [Ben Stern](https://unsplash.com/@benst287) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[110,864,2107],"agile",{"slug":2109,"featured":6,"template":679},"athlinks-cuts-runtime-in-half-with-giltab","content:en-us:blog:athlinks-cuts-runtime-in-half-with-giltab.yml","Athlinks Cuts Runtime In Half With Giltab","en-us/blog/athlinks-cuts-runtime-in-half-with-giltab.yml","en-us/blog/athlinks-cuts-runtime-in-half-with-giltab",{"_path":2115,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2116,"content":2122,"config":2127,"_id":2129,"_type":16,"title":2130,"_source":17,"_file":2131,"_stem":2132,"_extension":20},"/en-us/blog/observability",{"title":2117,"description":2118,"ogTitle":2117,"ogDescription":2118,"noIndex":6,"ogImage":2119,"ogUrl":2120,"ogSiteName":713,"ogType":714,"canonicalUrls":2120,"schema":2121},"We're moving our observability suite to Core","Our gift to you for 2020: Metrics, logging, and tracing and alerting are coming soon to Core!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665651/Blog/Hero%20Images/gitlab-holiday-2019-blog-cover.png","https://about.gitlab.com/blog/observability","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"We're moving our observability suite to Core\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2019-12-16\",\n      }",{"title":2117,"description":2118,"authors":2123,"heroImage":2119,"date":2124,"body":2125,"category":14,"tags":2126},[1684],"2019-12-16","\nHappy New Year to our developer community! We're moving a big portion of our [observability features](/blog/monitoring-team-update/) – custom metrics, logging, tracing and alerting – from our proprietary codebase to our open source codebase in 2020. We aim to complete this migration by early next year, and [you can follow along with our progress in this Epic](https://gitlab.com/groups/gitlab-org/-/epics/2310). While we're giving you the gift of 20/20 vision into your production environment as a thank you for all you've contributed, there are also three practical reasons as to why we're moving our observability suite to Core.\n\n## Why we're moving observability to Core\n\n### It's part of our stewardship model\n\nThe first reason being that it is our [stewardship](/company/stewardship/) mandate. Our product is open-core and our pricing model is transparent and buyer-based. A [buyer-based pricing model](/company/pricing/#the-likely-type-of-buyer-determines-what-features-go-in-what-tier) means we try to think about what type of buyer is going to get the most value out of a feature as we determine whether a feature belongs in our open source Core product or our paid versions of GitLab.\n\n\"If it's a feature for a single developer who might be working on his or her own individual project, we want that to be in Core because it invites more usage of those tools and we get great feedback in the form of new feature requests and developer contributions,\" says [Kenny Johnston](https://about.gitlab.com/company/team/#kencjohnston), director of product, [Ops](/direction/ops/) at GitLab. \"It's an important part of our product philosophy to ensure we keep developer focused features in our Core product.\"\n\n### Observability belongs in Core\n\nOur mission is to provide an end-to-end DevOps solution for developers that is also open source, and we were falling a bit short on the Ops side of things by keeping essential observability tools in a proprietary codebase.\n\n\"Before this move, If you were using Gitlab's open source version, you could attach a Kubernetes cluster and deploy applications to it, but then your ability to observe how your users are interacting with it in production was limited,\" says Kenny. \"Now, you can get out-of-the-box metrics, create customized ones, get access to log tailing and searching and see traces – all within GitLab. Those were all non-existent in Core previously.\"\n\nThe fact is, the three pillars of observability: [custom metrics](/direction/monitor/platform-insights/), [logging](/direction/monitor/#logging), and [tracing and alerting](/direction/monitor/platform-insights/), are fundamental to the complete DevOps lifecycle even for those single developers working on their own projects. That means they belong in our Core product.\n\n### We want your input on monitoring\n\nThe third reason is that we value your contributions, and we're hoping that by making our observability tools open source you will make valuable improvements to the code so that other developers can benefit from your insight. This is the gift you offer us every day, and so now we have a wishlist for you.\n\n## The three pillars of observability are on our wish list\n\n### Custom metrics\n\nGitLab has a strong integration with Prometheus that allows users like you to [monitor key metrics for applications](/direction/monitor/platform-insights/) deployed on Kubernetes or a different [Prometheus server](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#manual-configuration-of-prometheus), without ever leaving our interface. Common reporting metrics include system metrics such as memory consumption, as well as error and latency rates. GitLab will automatically detect certain metrics from our metrics library, and you can customize these metrics based on your needs.\n\nBut there is always room for improvement. If you see something that you think needs improvement with metrics, or any of our observability features, please submit an issue or a merge request, or even contribute changes to our open source codebase.\n\n### Logging\n\nYou can see [logs of running pods on your Kubernetes clusters](https://docs.gitlab.com/ee/user/clusters/agent/index.html), without the hassle of having to toggle between applications, since logging is integrated within GitLab. But our [current logging capabilities](/direction/monitor/platform-insights/) are best described as log tailing. Users can see what is essentially a live stream of their logs within GitLab. Is our log tailing providing enough observability into the health of your deployed Kubernetes clusters? We're hoping you can help us innovate new ways to make our logging tools more valuable.\n\n\"I would love to have more insight into how users want to interact with [logging], if log tailing is sufficient, how much they want to move back and forth,\" says Kenny. \"Some of those contributions can come in the form of commentary or issues being created, but people could also take it upon themselves to adjust that view so that is better suited to their needs when tailing a log.\"\n\n### Tracing and alerting\n\nWhile there are certain metrics that are commonly reported about a deployed application — such as how much CPU is being consumed, the speed to process a request, etc., [tracing](https://docs.gitlab.com/ee/operations/tracing.html) allows you to monitor deployed applications in more depth and be alerted to any issues with the performance or health of the application. But, like logging, our [tracing and alerting capabilities are in the earliest stages](/direction/monitor/platform-insights/).\n\n\"Today, our tracing is fairly minimal,\" says Kenny. \"We have an embedded UI for Jaeger, but we'd love to see contribution from members of the Jaeger community for more deep integration into GitLab. Maybe developers and operators who use GitLab would like to see more of the Jaeger UI experience directly in GitLab.\"\n\nOur alerting capabilities are also a bit clunky. You have to define it directly in the UI and code configuration. By better uniting our tracing integration with Jaeger with our alerting capabilities, we could create a more synchronized user experience.\n\n## Closing the DevOps loop\n\nIn order for GitLab to function as an end-to-end DevOps solution, our users must be able to apply our ticketing system all the way from issue to production.\n\n\"I'm really interested in the use case where people are creating issues for alerting when something goes wrong with their production environments, and then how they interact with observability information in the incident management issue itself,\" explains Kenny.\n\nPerhaps you need an issue template for incidents that will show a particular log line. Or there might be a custom metric that is so commonly used, it ought to be added to our metrics library.\n\n\"If you don't like the way that your alerting is set up, or you don't like the way that your log system is aggregated we'd love your contributions. If you don't like how metric charts, logs or traces are displayed in fire-fighting issues we'd love your contributions. GitLab is open source. You can contribute improvements to your observability tool just like you can the rest of your developer platform,\" says Kenny.\n\nSo go for it!\n\nThe three pillars of observability on GitLab are ripe for iteration, and there is still so much creative potential for each of these tools. We look forward to seeing what you come up with in 2020!\n",[675,1765],{"slug":2128,"featured":6,"template":679},"observability","content:en-us:blog:observability.yml","Observability","en-us/blog/observability.yml","en-us/blog/observability",{"_path":2134,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2135,"content":2141,"config":2147,"_id":2149,"_type":16,"title":2150,"_source":17,"_file":2151,"_stem":2152,"_extension":20},"/en-us/blog/aws-lambda-usage-stats",{"title":2136,"description":2137,"ogTitle":2136,"ogDescription":2137,"noIndex":6,"ogImage":2138,"ogUrl":2139,"ogSiteName":713,"ogType":714,"canonicalUrls":2139,"schema":2140},"AWS Lambda usage survey results","The results of our quick AWS Lambda usage survey","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664102/Blog/Hero%20Images/gitlab-values-cover.png","https://about.gitlab.com/blog/aws-lambda-usage-stats","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"AWS Lambda usage survey results\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Viktor Nagy\"}],\n        \"datePublished\": \"2019-11-27\",\n      }",{"title":2136,"description":2137,"authors":2142,"heroImage":2138,"date":2144,"body":2145,"category":14,"tags":2146},[2143],"Viktor Nagy","2019-11-27","\nThis blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2019-12-03.\n{: .alert .alert-info .note}\n\nIn early October, I asked the community to [share your AWS Lambda tooling habits](https://forms.gle/9xhjaPxKdZsHDs2V9), so we can better serve your needs from within GitLab. This blog post presents the results of that survey. The survey was shared on Reddit, some Facebook Groups, and on the GitLab Twitter and Facebook channels. All told we received 58 responses which makes the results thought-provoking, but certainly not conclusive. \n\n## Intro\n\nSo, what did I ask you about? I had a few assumptions in mind when I put together the survey.\n\n- Lambda is mostly used by developers, but - at least in the enterprise - ops people might be involved too, because of monitoring or security.\n- There are differences between hobby and professional usage, and I wanted to be able to try to filter out hobby users.\n- Serverless has an adoption path in the enterprise. This might result in it being used only for backoffice scripts at first. So I wanted to know if it's used in production or backoffice scripting only.\n\nBesides testing these assumptions, I wanted to learn about usage habits with respect to:\n\n- Frameworks used (if any)\n- Testing tools and approaches used\n- CI/CD tools used\n- Monitoring and debugging tools and approaches followed\n\nWho answered the survey?\n{: .note.text-center}\n\n![User role](https://about.gitlab.com/images/blogimages/aws-lambda-survey-2019/aws-population.png)\n\n## How do we write code for AWS Lambda\n\nThe first interesting topic was what frameworks were being used for AWS Lambda. It was possible to select multiple options and responders could even provide a free text answer.\n\n![Company size](https://about.gitlab.com/images/blogimages/aws-lambda-survey-2019/aws-frameworks.png){: .small.left.wrap-text}\n\nAs many responders chose more than just a single option, we should look a bit behind the data to understand more. From that you can see that the [serverless framework](/topics/serverless/) is popular with these respondents and its use is  wide-spread. The *Other* section is quite scattered and there are no other big players; responses included Zappa, Chalice, Netlify function, etc. \n\nI thought that there might be differences once I controlled for the company size. I expected more Terraform and less CLI usage as the company size increases. I didn't look into statistical significance, but a simple eye-ball test shows that SMBs are going heads down with tech stacks. They are the strongest users of both serverless and Terraform. I'd say that enterprise users try to follow along, but have a quite big direct usage of AWS CLI too. Why might this be true? A few scenarios come to mind that can think about:\n\n- Enterprises are lagging in terms of technology adoption, thus their Terraform usage is lower\n- They use AWS CLI more extensively as the serverless framework can't fulfill all their use cases\n- Possibly we don't have enough data and with a stronger analysis it would turn out that there are no differences\n\n## What about testing\n\nWhen asked about the challenges serverless technologies pose one topic repeatedly arose: the lack of good testing infrastructure.\n\nAt GitLab we strive to provide outstanding CI/CD capabilities for testing. We also work hard to spread best practices. \n\nI asked the community about the current approaches they take to CI/CD and testing. Here again, multiple answers were allowed.\n\n![Company size](https://about.gitlab.com/images/blogimages/aws-lambda-survey-2019/aws-testing.png){: .small.right.wrap-text}\n\nThis pie chart is filtered to show only non-hobby projects. Even here, almost every fifth project has no testing at all! Otherwise, we can barely speak about test pyramids here as the majority of the projects either don't run any tests or run only unit tests.\n\nGetting into the data by company size, we see what we would expect: as the company size grows, testing becomes more important.\n\n## CI/CD bias\n\nThe survey also contained a question about which CI/CD tools are being used. I skipped the analysis here. As the survey was mostly shared by GitLab team members, and through GitLab channels, clearly the majority of responders use GitLab. A wise choice! \n\n## Monitoring\n\nAlongside developing and deploying software, thinking about its operational health in production is just as important. This led me to ask a few questions on Lambda monitoring habits.\n\n![Company size](https://about.gitlab.com/images/blogimages/aws-lambda-survey-2019/aws-monitoring.png){: .small.left.wrap-text}\n\nEven given the small sample size, I was surprised the vast majority choose AWS CloudWatch. I expected most production environments would use more advanced instrumentation, and I was wrong.\n\nA related question I asked is, \"What metrics are you  most interested in?\" This was a free-text answer. There were no surprises here with \"error rates\" coming out as the clear winner.\n\n## Conclusion\n\nBased on the survey it became clear that even today, GitLab can be used very well with AWS lambda. To make getting started easy, we've created a project template that uses GitLab Pages to host the frontend of your app, and AWS Lambda for your backend needs. Besides the basic hosting needs, our templates have `serverless-offline` support added, so you can start writing tests against it without any additional setup needed. You can easily begin by starting a [new project using the Serverless Framework/JS template](https://gitlab.com/projects/new).\n\n![Easy getting started with project templates](https://about.gitlab.com/images/blogimages/aws-lambda-survey-2019/aws-project-template.png){: .medium}\n\nThese were the insights I gathered about the data. Because this data was provided by the community, I'm making it available to everyone. You can [download the responses as a csv](/images/blogimages/aws-lambda-survey-2019/aws-lambda-survey-responses.csv). In case you are serious about Serverless usage in production, I'd love to hear your insights! Feel free to [reach out to me](https://gitlab.com/nagyv.gitlab)!\n",[268,675,232],{"slug":2148,"featured":6,"template":679},"aws-lambda-usage-stats","content:en-us:blog:aws-lambda-usage-stats.yml","Aws Lambda Usage Stats","en-us/blog/aws-lambda-usage-stats.yml","en-us/blog/aws-lambda-usage-stats",{"_path":2154,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2155,"content":2161,"config":2166,"_id":2168,"_type":16,"title":2169,"_source":17,"_file":2170,"_stem":2171,"_extension":20},"/en-us/blog/creationline-post",{"title":2156,"description":2157,"ogTitle":2156,"ogDescription":2157,"noIndex":6,"ogImage":2158,"ogUrl":2159,"ogSiteName":713,"ogType":714,"canonicalUrls":2159,"schema":2160},"Meet Creationline team members who contribute to GitLab","Creationline contributes to GitLab as a reseller. Three team members explain how it works.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673096/Blog/Hero%20Images/contributors-cover.png","https://about.gitlab.com/blog/creationline-post","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Meet Creationline team members who contribute to GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2019-11-27\",\n      }",{"title":2156,"description":2157,"authors":2162,"heroImage":2158,"date":2144,"body":2163,"category":14,"tags":2164},[1840],"\nFor this edition of the [GitLab contributor blog posts](/blog/tags.html#contributors), I'm\nexcited to introduce Creationline, which is a [GitLab reseller in Japan](/resellers/creationline/). As you read this blog post, you will find Creationline is not a typical reseller. Their team were able to help both their customers and the GitLab community through their contributions. Here's what three Creationline employees had to share with us. \n\n## Decision to partner with Gitlab and contributing as a reseller\n#### [Jean-Baptiste Vasseur](https://gitlab.com/jvasseur), Agile Coach and DevOps Consultant \n\nWhen we explored the [DevOps](/topics/devops/) landscape about 3 years ago, we accidentally came across [GitLab’s handbook](/handbook/). This was a revelation for us! Pushing transparency to a point where job applicants know how GitLab members are expected to behave with candidates, a company culture where people are not afraid to communicate their failures, published company business targets and how the team is planning to achieve them, and of course how an open source software philosophy applied to every aspect of GitLab. We felt connected to so many aspects of GitLab’s company culture that I wanted to find a way to work together.\n\nAs [Creationline](http://www.creationline.com/gitlab) was already reselling licenses for other cloud and DevOps companies, and as GitLab was looking for more partners in different countries at that time, we felt confident we had a very good match and started distributing GitLab licenses in June, 2017.\n\nI usually invest a lot of my time prospecting clients, providing technical and value chain consulting, and contributing to the local community by co-organizing meetups and delivering CI/CD workshops. While I also love writing code – I come from an engineering background – it's a challenge to find the time to make open source contributions. However, while I was consulting for a large IT firm that was developing an internal DevOps package built around GitLab, I had an opportunity to make a valuable contribution to GitLab on the company's behalf. The team had a lot of passion for the project and loved working with the GitLab product, but they got blocked by a missing API and were not comfortable enough with their English to open a merge request.\n\nAs consultants, we did not have the responsibility of adding features or fixing issues on GitLab, but I really wanted to help our client. I explored the source code, figured out the pattern/coding style, and opened my first [merge request](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/22296). Review happened almost immediately, and GitLab team members were very nice and also challenged me to apply some refactoring, which helped me learn even more about the source code.\n\n![Open Source Summit Japan, 2019](https://about.gitlab.com/images/blogimages/creationline-blogpost/Creationline-OSS-Japan.jpg){: .shadow.medium.center}\nCreationline and GitLab team members at Open Source Summit-Japan\n{: .note.text-center}\n\n## Journey from an end user to a regular contributor to an evangelist\n#### [Hiroyuki Sato](https://gitlab.com/hiroponz), GitLab Evangelist\n\nI started to contribute to GitLab back in 2012. At that time I was already using GitLab at work, and I wanted to fix a bug that I was facing. This issue was preventing the source code diff from being displayed on the screen, but it was only occurring when using Japanese. As this issue was not seen in other languages, this was not a high priority bug, but it was impacting us severely. I found it very natural to fix it myself and to open a [merge request](https://github.com/gitlabhq/gitlabhq/pull/2100). In order to solve this, I also had to first fix the gem ‘grit_ext’ that GitLab was using, and created [another merge request](https://github.com/gitlabhq/grit_ext/pull/1).\n\nBoth merge requests got reviewed and merged within three days! This experience was so exciting that I started to contribute more and created [multiple merge requests](https://github.com/gitlabhq/gitlabhq/pulls?q=is%3Apr+author%3Ahiroponz+is%3Aclosed), and eventually I was awarded the [MVP](https://about.gitlab.com/community/mvp/) for GitLab's 5.1 release.\n\nLater on, as I really loved GitLab as a product, I started to explore if there was a way for me to work more closely with GitLab. This is when I met Creationline, which had just become the exclusive reseller in Japan and I decided to join them in April, 2018.\n\nNow, I am involved in pre-sales, marketing, customer support, and I also offer trainings on how to get the best out of GitLab. Of course, I still invest a part of my time to [contribute to GitLab](https://gitlab.com/groups/gitlab-org/-/merge_requests?%0Ascope=all&utf8=%E2%9C%93&state=merged&author_username=hiroponz) to help customers overcome issues/challenges, and this is one of my favorite parts of the job!\n\n## Dogfooding at Creationline\n#### [Yuko Takano](https://gitlab.com/takano_cl), Customer Success Manager\n\nAs a reseller team, we wanted to have more opportunities to use GitLab on a daily basis so we can support our customers better. We also wanted to experience the continuous server side operations, and set up our own instance so that we can capitalize on this experience.\n\nWe started using GitLab inside the GitLab reseller team, and then expanded it to various business functions within our organization. We now use a lot of GitLab features in order to manage source code, visualize our sales and marketing workflow, track translation work, organize OKRs with epics, and we continue to look for other areas to explore.\n\n![GitLab CI workshop](https://about.gitlab.com/images/blogimages/creationline-blogpost/Creationlin-GitLab-workshop.jpg){: .shadow.medium.center}\nCreationline team running the GitLab CI Workshop\n{: .note.text-center}\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can\nlearn how you can contribute to GitLab's code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n",[268,675,865,2165],"releases",{"slug":2167,"featured":6,"template":679},"creationline-post","content:en-us:blog:creationline-post.yml","Creationline Post","en-us/blog/creationline-post.yml","en-us/blog/creationline-post",{"_path":2173,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2174,"content":2180,"config":2186,"_id":2188,"_type":16,"title":2189,"_source":17,"_file":2190,"_stem":2191,"_extension":20},"/en-us/blog/gitlab-serverless-with-cloudrun-for-anthos",{"title":2175,"description":2176,"ogTitle":2175,"ogDescription":2176,"noIndex":6,"ogImage":2177,"ogUrl":2178,"ogSiteName":713,"ogType":714,"canonicalUrls":2178,"schema":2179},"Announcing GitLab Serverless deploying to Cloud Run for Anthos","Discover how we're making it easier to deploy serverless workloads on-premise with Anthos.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666851/Blog/Hero%20Images/gitlab-serverless-blog.png","https://about.gitlab.com/blog/gitlab-serverless-with-cloudrun-for-anthos","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Announcing GitLab Serverless deploying to Cloud Run for Anthos\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mayank Tahilramani\"}],\n        \"datePublished\": \"2019-11-19\",\n      }",{"title":2175,"description":2176,"authors":2181,"heroImage":2177,"date":2183,"body":2184,"category":14,"tags":2185},[2182],"Mayank Tahilramani","2019-11-19","\nThis week at Google Cloud Next ’19 UK, Google Cloud grew its Anthos product portfolio with the addition of Cloud Run for Anthos running on-prem. I’m excited to share that GitLab has been collaborating with Google Cloud product teams to support this launch and enable customers with CI/CD and [GitLab Serverless](/topics/serverless/) capabilities for quicker and easier adoption of serverless solutions. In the spirit of our partnership, our support for [Cloud Run for Anthos](https://cloud.google.com/run) is a continuation of our collaboration [announced earlier this year at Google Cloud Next ’19 in San Francisco](/blog/running-a-consistent-serverless-platform/), where we showed how you can deploy a serverless function to Cloud Run using the same developer workflow you’re already familiar with in GitLab. Now, we’re looking to bring that same UX and workflow consistency to Cloud Run deployments on Anthos running on-premise. Overall, together, GitLab and Google Cloud are aiming to lower the barrier of adoption for customers looking to architect scalable, cloud native solutions. \n\nHowever, when discussing cloud native, oftentimes ‘public cloud infrastructure’ comes to mind. But when I think of cloud native, I think of the various, modern ways of architecting scalable solutions, backed by managed services to make operations more convenient. Until very recently, infrastructure-centric managed services like Google Kubernetes Engine (GKE), Cloud Run, StackDriver, etc. have been traditionally associated with workloads running within cloud data centers. Given the recent announcements of [Google Cloud Anthos](https://cloud.google.com/blog/products/serverless/knative-based-cloud-run-services-are-ga), Google is clearly broadening the boundaries of cloud native across hybrid and heterogeneous environments, including customer data centers. As the infrastructure landscape diversifies, as application development intertwines with abstraction layers of managed services, and as workload flexibility becomes inherent with microservice containerization, the one thing you can rely on staying consistent is GitLab’s developer workflow to supplement all the above. In the context of all things [serverless](/topics/serverless/), let's take a closer look at what’s available today, what we’re still working on, and what that means for our users.\n\n## What’s available today\n\nGitLab serves as a single application for all of [DevOps](/topics/devops/), which includes building, deploying, and managing serverless applications. GitLab serverless enables developers to focus on writing application code without having to worry about Kubernetes or Knative YAML configuration. GitLab provides templates allowing developers to easily build and deploy Knative services that can be deployed to Cloud Run. Here is a [quick video walkthrough on the anatomy of a serverless project hosted in GitLab and deployed to Knative](https://youtu.be/IIM8JWhAbNk?t=210). With Google, you have a few options on how to leverage Cloud Run as a deployment target for GitLab CI/CD. As of this week, you can run Cloud Run in three different flavors: \n\n1. **Cloud Run**: This is a fully managed cloud service powered by Knative for serverless apps. GitLab supports deploying to Cloud Run and the full CI/CD workflow to leverage GitLab Runners to build and test functions. GitLab takes in the [`serverless.yml`](https://docs.gitlab.com/ee/update/removals.html) file within the root of your source code repository to define and deploy to Cloud Run.  \n\n2. **Cloud Run for Anthos running on Google Cloud**: This is a managed deployment of Knative on Anthos GKE clusters running on Google Cloud Platform. This enables you to install a managed Cloud Run deployment on top of your own Kubernetes cluster. Similar to above, GitLab also supports deploying to Cloud Run via the full CI/CD workflow, but as of right now, the highest version of Knative supported by GitLab is 0.7. Latest version support for Knative is coming in [GitLab 12.6](/releases/) on Dec. 22, 2019.  \n\n3. **Cloud Run for Anthos running on-premise**: Similar to above, this flavor of Cloud Run enables users to run a managed Cloud Run deployment on top of Anthos GKE On-Prem in your own data center. Currently, Knative v.0.9 is deployed in GKE-OP clusters. GitLab is soon to release support for Knative v0.9 and users can track the progress of this work in [this open issue](https://gitlab.com/gitlab-org/gitlabktl/issues/55) today. If you like what we’re working on, stop by and give us a thumbs up for feedback. So far, internal testing has been very positive and we look forward to formally supporting Cloud Run for Anthos running on-premise in the coming months/releases. The user experience will be almost identical to the prior two use cases listed above as you would expect.\n\n## Where to get started\n\nIf you’re interested in getting started with some sample code, check out our [documentation](https://docs.gitlab.com/ee/update/removals.html) and [sample app project](https://gitlab.com/knative-examples/functions) for reference. Additionally, [here is a walkthrough of deploying a demo app to Cloud Run from GitLab](https://youtu.be/lb_bRRAgEyc?t=1103). If you’re looking to get started with Serverless on Google Cloud Platform, [sign up for GitLab.com here](https://gitlab.com/users/sign_up) and then [sign up for $200 additional free GCP credits](https://cloud.google.com/partners/partnercredit/?PCN=a0n60000006Vpz4AAC).\n",[110,1391,1434,232,2023],{"slug":2187,"featured":6,"template":679},"gitlab-serverless-with-cloudrun-for-anthos","content:en-us:blog:gitlab-serverless-with-cloudrun-for-anthos.yml","Gitlab Serverless With Cloudrun For Anthos","en-us/blog/gitlab-serverless-with-cloudrun-for-anthos.yml","en-us/blog/gitlab-serverless-with-cloudrun-for-anthos",{"_path":2193,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2194,"content":2200,"config":2205,"_id":2207,"_type":16,"title":2208,"_source":17,"_file":2209,"_stem":2210,"_extension":20},"/en-us/blog/sourcegraph-code-intelligence-integration-for-gitlab",{"title":2195,"description":2196,"ogTitle":2195,"ogDescription":2196,"noIndex":6,"ogImage":2197,"ogUrl":2198,"ogSiteName":713,"ogType":714,"canonicalUrls":2198,"schema":2199},"Native code intelligence is coming to GitLab","We're enhancing code review with Sourcegraph – no extra plugins required.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673090/Blog/Hero%20Images/random_code.jpg","https://about.gitlab.com/blog/sourcegraph-code-intelligence-integration-for-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Native code intelligence is coming to GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mayank Tahilramani\"}],\n        \"datePublished\": \"2019-11-12\",\n      }",{"title":2195,"description":2196,"authors":2201,"heroImage":2197,"date":2202,"body":2203,"category":14,"tags":2204},[2182],"2019-11-12","\nAlmost a year ago, our CEO [Sid Sijbrandij](/company/team/#sytses) opened an issue proposing [GitLab integrate with Sourcegraph to provide advanced code navigation and cross-referencing functionality for source code we host](https://gitlab.com/gitlab-org/gitlab/issues/20642). We knew this feature would be a big improvement to the Developer UX in our product, particularly for efficient code review. We also knew [Sourcegraph](https://about.sourcegraph.com/) has an open-core product with one of the best-in-class code navigation capabilities. It only made sense to have a tighter integration between the two products.\n\n## How we built this\n\nSo, our generous friends at Sourcegraph got to work. A [browser extension supporting GitLab](https://docs.sourcegraph.com/integration/gitlab) was already available, but Sourcegraph collaborated with our engineering and product management teams and added the integration directly to the GitLab codebase – powered by GitLab.com and Sourcegraph.com. The integration gives users a fully browser-based developer platform, with no extra plugins required.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/LjVxkt4_sEA\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\nGitLab CEO and co-founder Sid Sijbrandij and Sourcegraph CEO and co-founder Quinn Slack explain the new integration.\n{: .note.text-center}\n\nFor now, get a sneak preview of how our integration with Sourcegraph works by watching a [quick screencast tutorial](https://vimeo.com/372226334/de668e24fa).\n\nThe process of building the integration between Sourcegraph and GitLab is a great example of our [transparency](https://handbook.gitlab.com/handbook/values/#transparency) and [collaboration](https://handbook.gitlab.com/handbook/values/#collaboration) values at work.\n\n## Collaboration in the open\n\n[Sourcegraph’s contribution to GitLab](https://gitlab.com/gitlab-org/gitlab/merge_requests/16556) is significant for developer productivity. For example, their merge request (MR) adds native support for features like ‘go-to-definition’ and ‘find references’ within a hover tooltip. Users can engage the tooltip UI in code views, file views, merge requests, and code diffs. Developers can stay in context during code reviews when they need to investigate a function implementation by simply hovering over the name of the function to navigate efficiently. Within the tooltip, users can see the definition of the function, navigate to the definition, or show other references in the code where the function is being used. In addition to making code reviews higher quality and more efficient, developers will have an easier time investigating complex implementations when reading the source of their favorite library. With Sourcegraph, we’re enabling developers with a richer UX by gathering more information about the code they are reading.\n\nSee for yourself by reading the discussions on the [MR](https://gitlab.com/gitlab-org/gitlab/merge_requests/16556) and viewing changes made to the code. As always, we’re collaborating in the open and encourage the community to provide constructive feedback on our project. Drop a line in the blog comments to share your thoughts.\n\nFor a more detailed overview of the UX of functionality and features, check out [this blog post](https://about.sourcegraph.com/blog/gitlab-integrates-sourcegraph-code-navigation-and-code-intelligence) by Christina Forney, product manager at Sourcegraph.\n\n## What does this mean for our users?\n\nGitlab’s integration with Sourcegraph will be available in our [12.5 release](/upcoming-releases/) on November 22, 2019. We aim to provide code intelligence and code navigation functionality in this integration which was historically provided by the Sourcegraph’s browser extension. Now that we built this integration the browser extension is no longer needed to provide this functionality.\n\nIn the spirit of [iteration](https://handbook.gitlab.com/handbook/values/#iteration) our rollout strategy on GitLab.com is to **first dogfood** the functionality within our [*gitlab-org*](https://gitlab.com/gitlab-com/) group, which is where GitLab stores [source code for GitLab.com](/solutions/source-code-management/) and GitLab Enterprise. Over time, we aim to roll out Sourcegraph capabilities across code views within projects to all *public projects* on GitLab.com. Users will still require the browser extension configured to a private instance of Sourcegraph for **private projects** on GitLab.com.\n\nIf you’re self-managing your GitLab EE deployment and would like to enable Sourcegraph code intelligence, you must have a private Sourcegraph instance running as an external service. This is required because Sourcegraph.com does not index any private code for privacy and security reasons. We will have formal documentation on how to get started with GitLab EE and Sourcegraph soon, but if you’re super curious, [you can see our work in progress here](https://gitlab.com/gitlab-org/gitlab/blob/ps-sourcegraph-playground/doc/integration/sourcegraph.md) within the MR branch.\n\n## What’s next?\n\nStay tuned for our 12.5 release announcement on November 22 and updates containing details around our integration with Sourcegraph. Give us a [thumbs up](https://gitlab.com/gitlab-org/gitlab/merge_requests/16556) if you like what we’re working on. If you’re new to Sourcegraph and/or GitLab, [sign up here](https://gitlab.com/users/sign_up) and install [the browser extension](https://docs.sourcegraph.com/integration/gitlab#browser-extension) to test out these features right away. [Here is a link to a file in one of our public projects where you can test out these features](https://gitlab.com/gitlab-org/gitlab-runner/blob/master/executors/ssh/executor_ssh.go).\n\n[Cover photo](https://unsplash.com/photos/qjnAnF0jIGk) by [Markus Spiske](https://unsplash.com/@markusspiske) on Unsplash.\n{: .note}\n",[110,1391,232],{"slug":2206,"featured":6,"template":679},"sourcegraph-code-intelligence-integration-for-gitlab","content:en-us:blog:sourcegraph-code-intelligence-integration-for-gitlab.yml","Sourcegraph Code Intelligence Integration For Gitlab","en-us/blog/sourcegraph-code-intelligence-integration-for-gitlab.yml","en-us/blog/sourcegraph-code-intelligence-integration-for-gitlab",{"_path":2212,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2213,"content":2219,"config":2224,"_id":2226,"_type":16,"title":2227,"_source":17,"_file":2228,"_stem":2229,"_extension":20},"/en-us/blog/optimize-gitops-workflow",{"title":2214,"description":2215,"ogTitle":2214,"ogDescription":2215,"noIndex":6,"ogImage":2216,"ogUrl":2217,"ogSiteName":713,"ogType":714,"canonicalUrls":2217,"schema":2218},"Optimize GitOps workflow with version control from GitLab","A GitOps workflow improves development, operations and business processes and GitLab’s CI plays a vital role.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673081/Blog/Hero%20Images/gitops-image-unsplash.jpg","https://about.gitlab.com/blog/optimize-gitops-workflow","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Optimize GitOps workflow with version control from GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brein Matturro\"}],\n        \"datePublished\": \"2019-10-28\",\n      }",{"title":2214,"description":2215,"authors":2220,"heroImage":2216,"date":2221,"body":2222,"category":14,"tags":2223},[1958],"2019-10-28","\nGitOps is a way for IT operations to manage changes across infrastructure and development teams. At GitLab\nConnect in Denver, [Tyler Sparks](https://www.linkedin.com/in/sparksconcept/), principal engineer and\nowner of Sparks Concept, presented a talk on why GitOps is a productive workflow and how\nusing GitLab can increase communication and version control.\n\n[GitOps](/topics/gitops/) uses infrastructure as code but with processes in place on top of it, including extensive use of\nmerge requests for everything from policy to infrastructure changes. “Success for most companies and\nengineering groups is based on the interactions of a large, complex, distributed system,” Tyler says.\nThe goal of GitOps is to incorporate Git beyond development and operations teams, improving the\nbusiness as a whole with the right tool. “It's a really cool way that GitLab integrates and it's a way to\nshift things left in your organization.”\n\n## The Git in GitOps\n\n“Git is the single source of truth. You shouldn’t be able to make any change outside of Git,” Tyler says. This creates one clean transaction between teams. Git establishes a unified location for anything from security, infrastructure changes, deployments, process changes, and even the integration of other tools. “Git is serving as the glue to make these safe transitions so that you can move faster as a team,” Tyler says.\n\nCreating that interaction between groups is often elaborate and difficult to manage. “Anyone building software these days is finding it more and more complex...everything is changing, the landscape is constantly changing,” Tyler says. Services are being run on stacks upon stacks and there is a lot of risk involved in maintenance. A tool, like [GitLab CI](/solutions/continuous-integration/), simplifies the processes and grants visibility.\n\n## GitOps best practices\n\nIn a GitOps workflow, where one simple change can impact three different teams, a strong [version control is imperative for communication](/topics/version-control/). Between disparate tools and poorly defined handoffs, the solution is to move into one repository for all tools and teams. With one overarching repository, “You can have a bunch of parallel workstreams running safely… you will have minimum viable change and a way to observe it,” Tyler says.\n\nWith GitLab’s version control system in place, teams can see what’s going on to work together and to know what change is going to impact where. “GitLab CI is one of the original products that made it possible to start to take an integrative view of the system,” Tyler says. “This is the penultimate way to [promote collaboration](/topics/gitops/gitops-gitlab-collaboration/) and to break down silos within an organization. GitLab is a tool that helps with that.”\n\nGitLab’s version control not only safeguards the infrastructure, but ultimately trickles throughout the entire enterprise. “As companies adopt GitLab, they’re not just more successful with their technology...it really comes down to how they’re functioning as a group,” Tyler says. “GitLab encourages some really good practices around development and how teams interact.”\n\n>“That’s why GitLab is the clear winner...They’re not just leading Gartner and Forrester because they paid somebody off. They’re actually an amazing tool.” Tyler Sparks, principal engineer and owner of Sparks Concept\n\nLearn more about GitOps best practices and Tyler’s work with GitLab CI in his presentation below:\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/5ykRuaZvY-E\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\nCover image by [David Rangel](https://unsplash.com/@rangel) on [Unsplash](https://unsplash.com)\n{: .note}\n",[699,1021,232,1583],{"slug":2225,"featured":6,"template":679},"optimize-gitops-workflow","content:en-us:blog:optimize-gitops-workflow.yml","Optimize Gitops Workflow","en-us/blog/optimize-gitops-workflow.yml","en-us/blog/optimize-gitops-workflow",{"_path":2231,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2232,"content":2238,"config":2243,"_id":2245,"_type":16,"title":2246,"_source":17,"_file":2247,"_stem":2248,"_extension":20},"/en-us/blog/kubernetes-101",{"title":2233,"description":2234,"ogTitle":2233,"ogDescription":2234,"noIndex":6,"ogImage":2235,"ogUrl":2236,"ogSiteName":713,"ogType":714,"canonicalUrls":2236,"schema":2237},"Getting Started with Kubernetes","Pods, nodes, clusters – oh my! Get the lowdown on Kubernetes from Brendan O'Leary's talk at Contribute 2019.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678474/Blog/Hero%20Images/clouds_kubernetes101.jpg","https://about.gitlab.com/blog/kubernetes-101","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Getting Started with Kubernetes\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2019-10-24\",\n      }",{"title":2233,"description":2234,"authors":2239,"heroImage":2235,"date":2240,"body":2241,"category":14,"tags":2242},[1684],"2019-10-24","\nKube-uh-not-a-clue?\n\nIt's the most common response to anyone who hears the term “Kubernetes” for the first time. If Kubernetes is, quite literally, Greek to you, then this blog post and [the corresponding video](https://www.youtube.com/watch?v=rq4GZ_GybN8) are two good places to start.\n\nWhile at [Contribute 2019](/blog/how-we-scaled-our-summits/), senior solutions manager [Brendan O’Leary](/company/team/#brendan) gave a presentation explaining the nuts and bolts of Kubernetes and how we use this open source tool at GitLab.\n\n## What is Kubernetes?\n\n“[Kubernetes](https://kubernetes.io/) is an open source system for automating deployment, scaling, and management of containerized applications,” according to the [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/).\n\n>“You'll hear [Kubernetes] called a lot of different things. You'll hear people say, ‘Well, it's a container scheduler.’ You'll hear people say it's a desired state manager. You'll hear people say it's an orchestrator,” says Brendan. “All these things just basically boil down to it's _a system that keeps the system how we want it to be_, which sounds kind of crazy. But when we're a software company for software companies, you can relate a little bit.”\n\nSo a system that keeps the system how we want it to be, what does that mean exactly?\n\nTo understand what Kubernetes is and what it does, it’s best to dig a bit deeper into the origin story of this technology.\n\nThe journey to Kubernetes started at Google, when infrastructure developers were searching for a way to deploy new applications on hundreds of thousands of globally distributed servers. The result was Borg, a private tool developed by Google engineers for this purpose. The engineers iterated on Borg to launch Project Seven – an open source project that wasn’t entirely Borg, but took elements of Borg to produce version 1.0 of Kubernetes.\n\nKubernetes, which translates from Greek to “pilot,\" “helmsman,” or \"governor,\" is managed by CNCF, a foundation created by Google and Linux to house Kubernetes and other open source computing projects.\n\n## The benefits of Kubernetes\n\nKubernetes is highly portable across multiple cloud platforms and simplifies container management across however many of them are in use. Kubernetes make it easy to achieve greater scalability, flexibility, and productivity. \n\nAnother big benefit of Kubernetes is of course the fact that it’s open source – it’s continuously improved and updated so that there are minimal workflow interruptions.\n\n## What features does Kubernetes offer?\n\nKubernetes is one of the fastest growing open-source software projects around today. Here are some of the reasons why:\n\n* Deployments can be sent to one cloud or multiple cloud services without losing any application functionality or performance.\n\n* Kubernetes automation capabilities handle scheduling and deploying containers regardless of where it comes from (on-premise, cloud, or other). The automation also auto-scales up and down to increase efficiency and reduce waste and it creates new containers if dealing with a heavy workload.\n\n* Kubernetes allows for rolling back an application change if something goes wrong. \n\n* The open-source nature of Kubernetes lets users take advantage of a vast ecosystem of open-source tools.\n\n* The software is never outdated due to previously launched versions – it is always updating.\n\n## The role of containers\n\nContainers are a lightweight technology that lets you securely run an application and its dependencies without impacting other containers or your operating system (OS). This makes containers more nimble and scalable than using other tools for application management, like virtual machines (VMs) or bare metal. Like VMs, containers can repeat the application as it’s in development, but unlike VMs, the container does not duplicate the OS each time and instead shares the infrastructure, container technology (e.g., Docker), and OS with the host computer. Containers are lightweight and easier to run on the cloud because the OS is not duplicated along with the application, but container technology can be challenging to manage without a tool.\n\n“As you get more and more containers... it has a huge advantage technically, but it really creates a mess as to how are we managing all these containers,” says Brendan. “And there’s another problem – bare metal, virtual machines, containers, these all assume to some extent that you know what's going on with the computer that's running them.”\n\n![Evolution of containers](https://about.gitlab.com/images/blogimages/evolution_of_containers.png){: .shadow.medium.center}\nContainers make application deployment simpler, but containers are hard to orchestrate without a tool like Kubernetes.\n{: .note.text-center}\n\nBut orchestrating the various application deployments in containers is a level of abstraction that is difficult for the human mind to grapple with and is challenging to manage manually, which is where Kubernetes comes in.\n\n## Kubernetes as scheduler\n\nKubernetes is an open source container orchestrator that automates container management from deployment to scaling and operating.\n\nThere are a few key advantages to using Kubernetes, namely that the technology takes an extremely abstract method of application management – containers – and schedules the deployments to occur automatically.\n\nBrendan mentions other advantages to using Kubernetes, including that is can run routine health checks and is a very self-healing technology. A second key advantage to using Kubernetes for [DevOps](/topics/devops/) is that it is a declarative technology at its core. By using the [desired state manager](https://medium.com/@yannalbou/kubernetes-desired-state-4c5c4e873743), you can describe how you want your application to run and Kubernetes makes it happen.\n\n## Core Kubernetes concepts and definitions\n\n*   **Pod**: An abstraction that represents a group of one or more application containers. “The pod is just a unit that says these are the containers that represent the front end website, or these are the containers that represent the payment system,” explains Brendan.\n*   **Node**: A worker machine in Kubernetes that may be a VM or a physical machine (e.g., a computer), depending upon the cluster. The node often includes Docker, the pods (“group of containers”), and the VM or computer that includes the OS.\n*   **Cluster**: The highest level of abstraction in Kubernetes, it contains all the nodes, pods, and a **master** – which maintains the desired state of your application by orchestrating the nodes.\n*   **Service**: Defines a logical set of pods (e.g., “payment system”) and sets a policy about who can access them. “Pods come and go, but a service is forever,” or so the saying goes, Brendan says. “A pod is going to get scheduled into a node. But if that node went away, the fact that this pod is a member of this service means I've got to go find somewhere else to make a new pod that has this container running in it.” A service allows Kubernetes to route traffic to your application regardless of where the pod is running.\n\nThere are plenty of other buzzwords and phrases that are associated with Kubernetes, and Brendan dives into some of them in his presentation (captured in the video below). More concepts are explained on the [Kubernetes website at CNCF](https://kubernetes.io/docs/concepts/).\n\n## GitLab and Kubernetes\n\nThere are three key touchpoints between GitLab and Kubernetes:\n\n1. **GitLab is an application, so it can be run on Kubernetes.**\nIf a GitLab customer is already using a cloud native environment (i.e., containers and Kubernetes), then GitLab the application can be installed in that cloud native environment. We have already set-up [Helm Charts](https://docs.gitlab.com/charts/), which describe [how to install GitLab in a cloud native environment](https://docs.gitlab.com/charts/#installing-gitlab-using-the-helm-chart).\n2. **Customers that build their applications in GitLab using CI/CD can deploy to Kubernetes.**\nThe [Configure team at GitLab](/handbook/engineering/development/ops/configure/) works on the integration between GitLab and Kubernetes so developers can deploy their applications automatically to a Kubernetes cluster. [The GitLab and Kubernetes integration](https://docs.gitlab.com/ee/user/project/clusters/) allows customers to create and dismantle Kubernetes clusters, use review apps, run pipelines, deploy apps, view pod logs, detect and monitor Kubernetes, and much more. The Ops product teams at GitLab are always working to enhance the integration between Kubernetes and GitLab to make Auto DevOps faster and more efficient.\n3. **Moving our production system for GitLab.com to a Kubernetes cluster.**\nWe recently moved our giant GitLab.com application from Microsoft Azure [to a Google Cloud Platform](/blog/moving-to-gcp/). A key reason we changed platforms is that we wanted to move our GitLab.com project to a Kubernetes cluster. This project is ongoing but we are making major strides toward continuous deployment using Kubernetes.\n\n## Is Kubernetes easy to use?\n\nEveryone’s favorite answer: it depends. As with any software, there’s a learning curve to using Kubernetes (like having a basic understanding of how containers work). And it also may not be the right software fit for your needs. But if it is, adopting it doesn’t have to be complicated. \n\nKubernetes gives users the basic building blocks for creating developer projects while still allowing user flexibility where it’s needed. It can get a little more labor-intensive if users choose to build their own Kubernetes clusters rather than letting the service do it for them. But most companies don’t choose this route. \n\n## But wait, there’s more\n\nIf you have more questions, like why the heck Kubernetes is abbreviated to K8s, or are searching for more resources, you’re in luck. Brendan dives into more detail about some of the etymology, key concepts, vocabulary and even pop culture that shapes Kubernetes in his presentation. Watch the video below to learn more about how Kubernetes has been the impetus behind a major shift toward cloud native in the DevOps industry, and why we’re on the front lines of that change here at GitLab.\n\n### Watch\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/rq4GZ_GybN8\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n### Supplemental reading\n\n[Kubernetes and the open source community](/blog/kubernetes-chat-with-joe-beda/): A conversation between GitLab CEO [Sid Sijbrandij](/company/team/#sytses) and the co-creator of Kubernetes, Joe Beda.\n\n[Kubernetes and the future of cloud native](/blog/kubernetes-chat-with-kelsey-hightower/): Sid chats with Kelsey Hightower, Google staff developer advocate about cloud native.\n\n[Kubernetes, containers, cloud native – the basics](/blog/containers-kubernetes-basics/): Get a quick overview of the key Kubernetes concepts.\n\n[Kubernetes + GitLab](/solutions/kubernetes/): Explore how GitLab and Kubernetes interact at various touchpoints.\n\n[Cover Photo](https://unsplash.com/photos/9BJRGlqoIUk) by [Pero Kalimero](https://unsplash.com/@pericakalimerica?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/cloud?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[1391,780],{"slug":2244,"featured":6,"template":679},"kubernetes-101","content:en-us:blog:kubernetes-101.yml","Kubernetes 101","en-us/blog/kubernetes-101.yml","en-us/blog/kubernetes-101",{"_path":2250,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2251,"content":2257,"config":2262,"_id":2264,"_type":16,"title":2265,"_source":17,"_file":2266,"_stem":2267,"_extension":20},"/en-us/blog/delta-cloud-native",{"title":2252,"description":2253,"ogTitle":2252,"ogDescription":2253,"noIndex":6,"ogImage":2254,"ogUrl":2255,"ogSiteName":713,"ogType":714,"canonicalUrls":2255,"schema":2256},"How Delta made the journey to cloud native","Delta tossed aside the rule book to go cloud native and achieve workflow portability. Here's how it's done.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678376/Blog/Hero%20Images/deltacommit.jpg","https://about.gitlab.com/blog/delta-cloud-native","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How Delta made the journey to cloud native\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2019-10-17\",\n      }",{"title":2252,"description":2253,"authors":2258,"heroImage":2254,"date":2259,"body":2260,"category":14,"tags":2261},[1860],"2019-10-17","\n_Delta Air Lines is the top domestic carrier in the United States, flying over 200 million people a year to more than 300 destinations in 50 countries. Delta is in a highly competitive industry with a lot of moving parts and that’s why, in 2016, the company began a sweeping digital transformation journey. At [GitLab Commit in Brooklyn](/blog/wrapping-up-commit/), Jasmine James, IT manager, DevOps Center of Excellence at Delta, shared how the company journeyed to [cloud native](/topics/cloud-native/) while avoiding vendor lock-in._\n\nDelta’s primary goal was business agility, Jasmine says, and the plan was to get there using cloud native. “We'll do cloud native and then we'll get the business agility, we thought,” she says. “But at Delta, because we have such large, complex systems and a very mission-critical environment, it was not that easy at all.”\n\nTo start, Delta took a hard look at its existing environment and at ways it could be improved. Metrics-based process mapping made it clear the infrastructure was standing in the way of delivering value. A flexible architecture would also make it easier to have scalable and reliable workloads, she explains. The company’s existing tools wouldn’t work with cloud native, so Jasmine’s team set out to find tools that could provide version control, [continuous integration, and continuous delivery](/solutions/continuous-integration/) – the three areas the team considered the [MVP](https://www.techopedia.com/definition/27809/minimum-viable-product-mvp) to get the job done.\n\n## Stick with vowels\n\nThe team came up with an easy-to-remember acronym to describe the criteria used during the tool search: **AEIOU**. **A** is for applicability: Will the tool be applicable for the heavy Java and Linux users at Delta? **E** meant enterprise-ready because Delta needed tried and true maturity. **I** stands for integration, and Jasmine was quick to point out that in this case, it wasn’t about legacy integration but simply a matter of ensuring all the new tools worked well together. **O** is for overhead, which has particular meaning for Jasmine’s team since they manage all the development tools at Delta. “We had to ask ourselves how easy it would be to manage and administer tools for 5000 developers at Delta,” she says. And finally, **U** represents usefulness, which is another way of saying the team wanted to ensure it would choose the right building blocks that would work together.\n\nDelta’s first choice of tools was GitLab, followed by [Sonatype Nexus](https://www.sonatype.com/product-nexus-repository) and Jenkins for CI, Jasmine says. Today Delta is considering expanding its options for developers to also include [GitLab CI](/solutions/continuous-integration/).\n\n## Careful choices = concrete benefits\n\nThe careful thought process has already shown a number of concrete benefits, Jasmine says. Delta created an API to allow customers flying different legs using partner airlines to check in just one time. And the airline’s employees have enhanced decision support around weather events that help to minimize the impact of canceled flights.\n\nBut the benefits go further, Jasmine stresses. “We now have the ability to play the field,” she says. “We not only can leverage the best of breed features in the public cloud space, we also can pick and choose based on public cloud provider performance and cost. With the cost savings we have been able to do a lot (which means we can) fund more great features.”\n\nDelta’s also been able to offer what Jasmine calls a “first class developer experience” because programmers can leverage both the airline’s on premises [Open Shift](https://www.openshift.com) private cloud and scale to the public cloud as needed, all while using familiar programming languages and tools.\n\nJasmine’s take away: “Be you, be different, be great in cloud native. What that means is that although I’ve talked a lot about Delta’s journey, there is no one way to implement cloud native.”\n\nWatch all of Jasmine’s presentation:\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/zV_hFcxoN8I\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\nCover image by [Angela Compagnone](https://unsplash.com/@angelacompagnone) on [Unsplash](https://unsplash.com/).\n{: .note}\n",[1391,780,1583,1391],{"slug":2263,"featured":6,"template":679},"delta-cloud-native","content:en-us:blog:delta-cloud-native.yml","Delta Cloud Native","en-us/blog/delta-cloud-native.yml","en-us/blog/delta-cloud-native",{"_path":2269,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2270,"content":2276,"config":2282,"_id":2284,"_type":16,"title":2285,"_source":17,"_file":2286,"_stem":2287,"_extension":20},"/en-us/blog/devops-on-the-edge-a-conversation-about-gitlab-and-arm",{"title":2271,"description":2272,"ogTitle":2271,"ogDescription":2272,"noIndex":6,"ogImage":2273,"ogUrl":2274,"ogSiteName":713,"ogType":714,"canonicalUrls":2274,"schema":2275},"DevOps on the edge: Upcoming collaborations between GitLab and Arm","Check out the latest news from the technical evangelist team about upcoming initiatives from GitLab and Arm.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682923/Blog/Hero%20Images/gitlab-arm-collaboration.jpg","https://about.gitlab.com/blog/devops-on-the-edge-a-conversation-about-gitlab-and-arm","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"DevOps on the edge: Upcoming collaborations between GitLab and Arm\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Priyanka Sharma\"}],\n        \"datePublished\": \"2019-10-08\",\n      }",{"title":2271,"description":2272,"authors":2277,"heroImage":2273,"date":2279,"body":2280,"category":14,"tags":2281},[2278],"Priyanka Sharma","2019-10-08","\nDevOps has moved from being a trend to an established cornerstone of the software development and delivery lifecycle. Today, the best practices of DevOps are being applied, in new and unique ways, to edge computing. As a board member of the Cloud Native Computing Foundation, I participate in open source communities regularly and over the years, I have collaborated with various folks from Arm because today where there is the edge, there is Arm.\n\nAs the technical evangelism leader at GitLab, I got involved with folks from the Arm project when collaborating on [CNCF.ci](http://cncf.ci). GitLab is a complete [DevOps platform](/solutions/devops-platform/), delivered as a single application. A key component of our product is our CI/CD pipeline that is well loved and used in the industry. Arm, through its market leadership in the mobile and embedded space, is now expanding into infrastructure space for edge-to-cloud applications. There is tremendous potential to grow within this emerging space and offer software developers a frictionless environment to develop innovative software at a rapid pace, securely.\nArm is having their annual conference [Arm TechCon 2019](https://www.armtechcon.com/) this week in San Jose, California, and I thought this is a great opportunity to highlight key projects and activities happening within the ecosystem involving Arm and GitLab:\n\n### GitLab for edge base research projects\n\nEric Van Hensbergen, R&D fellow from Arm's Research team, has been leading an effort to [use GitLab for edge base research projects](https://community.arm.com/developer/research/b/articles/posts/continuous-cross-architecture-integration-with-gitlab) creating multi-architecture images using Docker containers, including running GitLab’s 64-bit Runner on Arm instances on public cloud providers such as Packet Cloud and AWS. You can [access the runner](https://packages.gitlab.com/runner/gitlab-runner) for yourself too!\n\n### Stream processing on the edge\n\nLast month at [GitLab Commit Brooklyn](/blog/wrapping-up-commit/), GitLab’s first ever user conference, Eduardo Silva, principal engineer from Arm Treasure Data, [delivered a talk on the benefits of stream processing on the edge](https://gitlabcommit2019brooklyn.sched.com/event/TPDd/picking-up-speed-logging-stream-processing) in distributed systems using [Fluent Bit](https://fluentbit.io/) (a [Fluentd](https://www.fluentd.org/) open source sub-project).\n\n### Join the CNCF CI Working Group Monthly Meeting\n\nToday, all projects on [CNCF.CI](https://cncf.ci/) are being built and tested on both x86 and Arm architecture inside a Kubernetes test environment hosted on Packet’s bare metal infrastructure. For anyone interested, the working group hosts open meetings every month. More details are available in their [Monthly Meeting doc](https://docs.google.com/document/d/1NA4N6PvNEkHX1yzaDFr19Xlru-amRxNi2pliqudmYNA/edit). It’s a great group and I recommend people attend.\n\nThere are a lot of exciting activities happening in the edge-to-cloud and DevOps space. As a developer evangelist, I know the value Arm brings to the ecosystem and am excited to see the commencement of the GitLab and Arm partnership. More announcements to come in the near future. Stay tuned!",[110,1391,232,268],{"slug":2283,"featured":6,"template":679},"devops-on-the-edge-a-conversation-about-gitlab-and-arm","content:en-us:blog:devops-on-the-edge-a-conversation-about-gitlab-and-arm.yml","Devops On The Edge A Conversation About Gitlab And Arm","en-us/blog/devops-on-the-edge-a-conversation-about-gitlab-and-arm.yml","en-us/blog/devops-on-the-edge-a-conversation-about-gitlab-and-arm",{"_path":2289,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2290,"content":2296,"config":2301,"_id":2303,"_type":16,"title":2304,"_source":17,"_file":2305,"_stem":2306,"_extension":20},"/en-us/blog/redbox-on-demand-delivers-with-gitlab",{"title":2291,"description":2292,"ogTitle":2291,"ogDescription":2292,"noIndex":6,"ogImage":2293,"ogUrl":2294,"ogSiteName":713,"ogType":714,"canonicalUrls":2294,"schema":2295},"Redbox delivers On Demand with GitLab","Redbox's Joel Vasallo and Nicholas Konieczko explain how they ‘deliver software like a fox’ with GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673064/Blog/Hero%20Images/redbox-blog-jannes-glas-unsplash.jpg","https://about.gitlab.com/blog/redbox-on-demand-delivers-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Redbox delivers On Demand with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brein Matturro\"}],\n        \"datePublished\": \"2019-10-01\",\n      }",{"title":2291,"description":2292,"authors":2297,"heroImage":2293,"date":2298,"body":2299,"category":14,"tags":2300},[1958],"2019-10-01","\nAt GitLab Connect Chicago, Redbox's [Joel Vasallo](https://www.linkedin.com/in/joelvasallo) and [Nicholas Konieczko](https://www.linkedin.com/in/nick-konieczko-42895354) presented a talk called “Delivering software like a fox.” Redbox, primarily known for providing movie and video game rentals via automated retail kiosks, has recently expanded to provide streaming services.\n\nRedbox On Demand is the company's newest streaming platform, built on .NET Core in containers on Linux in the cloud. The video retail company had a few goals in mind when building its latest platform. Joel, cloud DevOps manager, and Nicholas, mobile applications manager, share their three main objectives and how GitLab provides the tool that ensures success.\n\n## Goal #1: Modernize software development processes\n\nThe mobile and development teams wanted to be able to create the platform using the latest technology in order to provide the best product for the customer. “[There was] nothing wrong with the way they were done, but in the sense that the world has really come a long way from traditional Windows servers... in a data center running .NET frameworks and stuff like that, we really wanted to empower developers to use containers,” Joel says.\n\n**Outcome**: The mobile and development teams currently use GitLab CI, leveraging Fastlane. The power of GitLab and its ability to work along with other tools helped to modernize software development processes.\n\n## Goal #2: Speed up delivery to the cloud\n\nProviding an on-demand service means that the application has to actually be ready at the very moment of demand. Being new to the streaming arena, it was important for Redbox to move to the cloud. “We also wanted to leverage the power of the cloud and have the scaling perspective of the cloud. We wanted to be in the cloud, as everyone wants to be nowadays. We also wanted to ensure that our features go out the door faster because, in the streaming business, it's all about being first to market with your features,” Joel says.\n\n**Outcome**: The teams now use GitLab CI along with Spinnaker. “We wanted to increase software delivery and do what's best for the teams. I don't want to dictate what developers should do in their day-to-day workflow,” Joel says.\n\n## Goal #3: Empower developers to own their applications\n\nThe hope was that a developer would be able to deploy code to production at any time with a single click of a button. Developers would then have the ability to just write the code and a working tool will be able to pick up the errors. “Code goes out the door based on an approval process. Developers are able to own and operate their code, essentially,” Joel says.\n\n**Outcome**: The objective was achieved, according to Joel. “Ultimately, developers own their own apps. GitLab Enterprise allowed teams to own their own verticals as well as Spinnaker, which allows them to deploy it to whatever cloud provider that they so choose.”\n\nTo learn more about how GitLab helped the mobile and development teams achieve their platform goals (and more), watch the presentation below.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/3eG8Muorafo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Key takeaways\n\n### Putting the version in version control\n\n“There was a disparate amount of Git and source control tools. Namely, we had an internal Git server, which... I don't know what it was actually running. We had GitHub.com. We had Team Foundation Server. We had Azure DevOps. So all this stuff... Teams were really all over the place. They all had their source code. Getting access to things was just a nightmare.\n\n“So what did we do? Let's get another version control system into the mix. We need a fifth one. So we picked GitLab. Honestly, GitLab was the most tried and true solution from our perspective. It has support for a few things, like on-prem, also in the cloud as well on the .com offering. But, more than that, at the end of the day it let developers control their namespace within a large organization.” – _Joel Vasallo_\n\n### GitLab works for mobile development\n\n“The mobile teams were the first to get to try out GitLab.com. It's simple. It's extremely easy to get started. There's a lot of documentation out there, all the things I love. It's very cost effective. We were able to get a free trial running, get repos open, test out different things, different features, to see if it could work for our teams.\" – _Nick Konieczko_\n\n### Yes, you can use Jenkins too\n\n“This is, honestly, one of the best things about GitLab, is they just want us to be successful. Batteries are included. There's a lot of great tools in there, such as GitLab CI, the GitLab Issue Board... and GitLab's Artifact Repository. It's built into the platform. GitLab's pipelines with the CI/CD process, all of this comes in. But if you don't want to use it, it'll adapt to your business model.\n\n“For example, my team uses Jenkins. We can still use GitLab. There's no blocking event where it says, ‘Oh, you're using Jenkins. You can't talk to us. Error. Blocked.’ No, we use Jira. We type ‘Jira, take us into GitLab’ all the time. We have JFrog Artifactory. We also use Spinnaker for our software delivery. Again, it transforms to what you need as a business, and that's the thing that I really appreciate, being on the DevOps side.” – _Joel Vasallo_\n\nCover image by [Jannes Glas](https://unsplash.com/@jannesglas) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[1583,1021,699,232],{"slug":2302,"featured":6,"template":679},"redbox-on-demand-delivers-with-gitlab","content:en-us:blog:redbox-on-demand-delivers-with-gitlab.yml","Redbox On Demand Delivers With Gitlab","en-us/blog/redbox-on-demand-delivers-with-gitlab.yml","en-us/blog/redbox-on-demand-delivers-with-gitlab",{"_path":2308,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2309,"content":2315,"config":2323,"_id":2325,"_type":16,"title":2326,"_source":17,"_file":2327,"_stem":2328,"_extension":20},"/en-us/blog/open-source-nasa-gl",{"title":2310,"description":2311,"ogTitle":2310,"ogDescription":2311,"noIndex":6,"ogImage":2312,"ogUrl":2313,"ogSiteName":713,"ogType":714,"canonicalUrls":2313,"schema":2314},"MRI Technologies used GitLab for unified toolchains to NASA","Live from GitLab Commit: NASA will be flying Kubernetes clusters to the moon and GitLab is helping.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678434/Blog/Hero%20Images/nasagitlab.jpg","https://about.gitlab.com/blog/open-source-nasa-gl","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Commit: How MRI Technologies used GitLab to bring unified toolchains to NASA\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2019-09-17\",\n      }",{"title":2316,"description":2311,"authors":2317,"heroImage":2312,"date":2318,"body":2319,"category":14,"tags":2320},"GitLab Commit: How MRI Technologies used GitLab to bring unified toolchains to NASA",[1860],"2019-09-17","\nNASA can put [Rovers on Mars](https://mars.nasa.gov/mer/), but a complex legacy software system proved a bit of a challenge. Speaking at GitLab Commit in Brooklyn, [Marshall Cottrell](https://www.linkedin.com/in/marshall-cottrell-27b385181) of [MRI Technologies](https://www.mricompany.com) explained how the company teamed up with NASA to launch the space agency into the era of modern application development using Kubernetes and GitLab.\n\nIn September 2018 MRI began work on a new software development platform called APPDAT. \"It's the only platform taking a totally 'fresh approach' to application development and data science activities within the Agency,\" Marshall said. The team's challenge was to update an Oracle-based legacy SCM solution using open source technologies and APIs. At the time NASA had no toolchains to support CI/CD during development and lots of silos of information. \"There was no mechanism for us to disseminate innovations, best practices, or what we learned,\" Marshall said. NASA needed a unified toolchain and platform for software delivery. \"GitLab was chosen as the platform source control management solution because it is the only product in this space that integrates all stages of the DevSecOps lifecycle.\"\n\n## A laser focus helps\n\nPerhaps not surprisingly MRI had ambitious goals for APPDAT, Marshall explained. The overarching hope was to build an automated DevOps platform that served as the single source of truth. Until MRI got involved, NASA had no way to actually \"own\" the software development process; teams operated in a piecemeal fashion, choosing contractors and solutions based on situational needs rather than looking at the big picture. Those decisions left NASA subject to potentially \"abusive behavior,\" Marshall explained.\n\nSo MRI laid out a number of goals:\n\n- Empower teams to fully manage the resources they support\n- Demonstrate and promote fully open project management and collaboration\n- Create a sandbox for protoyping with no barriers to entry\n- Assemble an API and data economy that would eliminate silos and promote reusability\n- Establish platform-level security controls with a goal of \"compliant by fault\"\n\nTo get there, MRI emphasized collaboration and tried to reach out to the \"forward-leaning\" customers and individual civil servant developers, engineers and researchers who were eager to contribute. The team adhered strictly to cloud native, Zero Trust and open source approaches and, in the end, came up with a Kubernetes platform that met the space agency's needs for today and in the future. The technology choices were important, but so was the time spent laying the groundwork for a culture change. \"Many modernization proposals try to meet everyone where they're at,\" Marshall explained. \"A more opinionated approach allows us to provide a succinct and unified toolchain that all parties can contribute to, evolve, and improve over time.\"\n\nToday the 61-year old space agency has a modern platform where developers can easily collaborate with non-developers, no complex tooling is required, and context switching is a thing of the past, Marshall said. APPDAT syncs from the agency's existing SCM solutions so everyone was able to continue to use the same tools.\n\nPerhaps most exciting, NASA's plans to have astronauts established on the moon by 2024 as part of the [Artemis program](https://www.nasa.gov/what-is-artemis). That will include a data center, and Marshall is confident Kubernetes will be part of the launch.\n\n\"We’ve already begun to change minds at NASA and you can do it at your enterprise too,\" Marshall said. His last best advice: Play the long game, only innovate when it makes things easier, and a bottom-up approach is an easy way to make friends.\n\nWatch Marshall's entire presentation here:\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/RsUw4Ueyn-c\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\nDon't miss out on the chance to network with others on the same DevOps journey. Get your tickets to [Commit London on October 9](/events/commit/).\n\nCover image by [David Torres](https://unsplash.com/@djjabbua) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[2321,780,1583,675,2322],"GKE","frontend",{"slug":2324,"featured":6,"template":679},"open-source-nasa-gl","content:en-us:blog:open-source-nasa-gl.yml","Open Source Nasa Gl","en-us/blog/open-source-nasa-gl.yml","en-us/blog/open-source-nasa-gl",{"_path":2330,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2331,"content":2337,"config":2343,"_id":2345,"_type":16,"title":2346,"_source":17,"_file":2347,"_stem":2348,"_extension":20},"/en-us/blog/creating-a-transparent-digital-democracy",{"title":2332,"description":2333,"ogTitle":2332,"ogDescription":2333,"noIndex":6,"ogImage":2334,"ogUrl":2335,"ogSiteName":713,"ogType":714,"canonicalUrls":2335,"schema":2336},"Government agency builds transparent democracy using GitLab","The Cook County Assessor’s office explains how they're using GitLab to help create a new level of government transparency.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679611/Blog/Hero%20Images/cook-county-blog-unsplash.jpg","https://about.gitlab.com/blog/creating-a-transparent-digital-democracy","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How one government agency is creating a transparent digital democracy with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brein Matturro\"}],\n        \"datePublished\": \"2019-09-02\",\n      }",{"title":2338,"description":2333,"authors":2339,"heroImage":2334,"date":2340,"body":2341,"category":14,"tags":2342},"How one government agency is creating a transparent digital democracy with GitLab",[1958],"2019-09-02","\n\nAt GitLab Connect Chicago, Robert Ross, chief data officer at the Cook County Assessor’s Office,\npresented the talk, “An experiment in digital democracy: How the Cook County Assessor’s\nOffice is using GitLab to reach a new level of transparency.”\n\nThe Chicago Assessor’s Office is responsible for predicting the value of over a million pieces of\nreal estate and reassessing them every three years. Record keeping has always been on paper and\nonly recently has “marginally sophisticated computer programming” been used. Now the Assessor's Office\nwants to turn the process over to software algorithms.\n\n“In a world where the computer is doing the heavy lifting, policy is code and code is policy,”\nRobert says. The algorithms used in assessing a property are dependent on a number of variables. If the\ncode variables are central to the assessment office, as it is for Cook County, it becomes\nimperative that it is made public. “[Our office] ran on a platform of fair, ethical, and\ntransparent assessments. In order to achieve that third pillar, we absolutely have to publish\nthe code that we use to value (a) house,” Robert says.\n\n## Modernizing software and viewpoints\n\nThe Assessment Office had a limited number of days to completely replicate the existing data\nformats that were in place from the previously elected office and to create a transparent\nplatform where property owners could understand how their assessment came to be. There were other\nchallenges too, such as legacy scripts, the inability to integrate older software, and zero\nassistance from the previous office.\n\nRobert and his team turned to GitLab to publish all of their code on residential modeling.\nThey have four repositories with more than 880 commits, all of which the public is able to access.\n“We’re using GitLab completely differently. Our product is your tax assessment and we have to\ndeploy the product on time because if we don’t, the entire government falls apart,” Robert says.\n“We will make mistakes and we have to document those mistakes so that we can be transparent and\ndo our jobs as well as we can.”\n\n## Creating radical policy shifts with transparency\n\nThe ability for property owners to access and own the information that creates their estate value\nhas never been done before at this level. “No county assessor has ever used a public-facing\nrepository for their work,” Robert says. In fact, establishing governing policies has customarily\nbeen done behind closed doors. Cook County has taken an experimental step towards open source\ngovernment policies. “Very few government agencies do it,” he says.\n\nThe Cook County office doesn’t want to stop there. This is just the first step in what it hopes\nare future electoral victories. “We need to demonstrate that transparency is ‘good politics’…\nif transparency becomes a successful evolutionary trait among politicians, you get more of it.”\n\nWant to hear about how Robert and the Cook County Assessment Office use GitLab? Watch his\npresentation in its entirety here:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/K8ROmhwphMg\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nCover image by [Element5 Digital](https://unsplash.com/@element5digital) on [Unsplash](https://unsplash.com)\n{: .note}\n",[1583,268,675],{"slug":2344,"featured":6,"template":679},"creating-a-transparent-digital-democracy","content:en-us:blog:creating-a-transparent-digital-democracy.yml","Creating A Transparent Digital Democracy","en-us/blog/creating-a-transparent-digital-democracy.yml","en-us/blog/creating-a-transparent-digital-democracy",{"_path":2350,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2351,"content":2357,"config":2364,"_id":2366,"_type":16,"title":2367,"_source":17,"_file":2368,"_stem":2369,"_extension":20},"/en-us/blog/managing-your-snowflake-spend-with-periscope-and-dbt",{"title":2352,"description":2353,"ogTitle":2352,"ogDescription":2353,"noIndex":6,"ogImage":2354,"ogUrl":2355,"ogSiteName":713,"ogType":714,"canonicalUrls":2355,"schema":2356},"How to manage your Snowflake spend with Periscope and dbt","The GitLab data team is open sourcing the dbt package they use to manage their Snowflake spend.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670255/Blog/Hero%20Images/data-servers.jpg","https://about.gitlab.com/blog/managing-your-snowflake-spend-with-periscope-and-dbt","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to manage your Snowflake spend with Periscope and dbt\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Taylor Murphy\"},{\"@type\":\"Person\",\"name\":\"Emilie Schario\"}],\n        \"datePublished\": \"2019-08-26\",\n      }",{"title":2352,"description":2353,"authors":2358,"heroImage":2354,"date":2361,"body":2362,"category":14,"tags":2363},[2359,2360],"Taylor Murphy","Emilie Schario","2019-08-26","\nOn the data team at GitLab, we are grateful to be empowered with best in-class tools that enable us to produce high-quality work. At the 2018 DataEngConf (now Data Council), GitLab data engineer [Thomas La Piana](/company/team/#tlapiana) spoke about how a team of three was supporting the data needs of a billion-dollar company. As he explains in this talk, we focus a lot on processes and workflows.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/eu623QBwakc\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## Where are the existing gaps?\nToday, the data team has grown from three to seven: three engineers and four analysts.\nSince we've more than doubled in the last six months, we've had to take a step back and revisit our processes.\n\n![GitLab Team Headcount](https://about.gitlab.com/images/blogimages/team_headcount.png){: .shadow.medium.center}\nThe GitLab team has grown significantly in the past few months.\n{: .note.text-center}\n\n### GitLab is growing fast\n\nDespite the significant jump in the data team's headcount, our growth has not matched the exponential growth of the team supporting GitLab.\nAs GitLab grows, more folks aim to include more data in their decision-making process.\nThis means we're iterating quickly, collecting feedback, and constantly improving on the quality of the analyses we are producing for our business stakeholders.\nThe demand for more data means there is a lot more to accomplish – making now an opportune time to review our processes and improve the data team's impact across GitLab.\n\nFor example, a data team member pointed out that refinement isn't a part of our [milestone planning process](/handbook/business-technology/data-team/how-we-work/#milestone-planning).\nNo wonder our backlog wasn't moving anywhere! We identified the root of the problem by asking our team, \"What is the problem we're trying to solve?\" and then laid out a plan to address it.\n\n### Onboarding can be hard\n\nWe've made some great data analyst hires recently!\nWe don't require our new team members to be familiar with our existing data stack (Stitch/Singer - Snowflake - dbt - Periscope), but we do require them to have technical skills that match their role.\nThis usually includes Git, SQL, and Python (Pandas) at the bare minimum, though we welcome R (tidyverse) as well.\nWhile onboarding at any company can be difficult, it's especially challenging in an all-remote organization such as GitLab.\n\nIn addition to introducing candidates to our specific technologies, part of the [data analyst onboarding](https://gitlab.com/gitlab-data/analytics/blob/master/.gitlab/issue_templates/data_onboarding.md) includes a unit on resource consumption.\nWe spend time introducing the concepts of databases and warehouses in Snowflake, because storage and compute being separate are often novel ideas to folks joining GitLab from an on-premise data organization.\nIn some cases, we are teaching our new hires a new way to think about the data-related problems they're solving, and introducing different resources to remedy these problems.\n\n### With great power comes great responsibility\n\nWe consume more resources as the data team headcount grows. I think about this like folks using water in a household. If everyone is on vacation, the water bill will be low, but if all the cousins come visit for a week, the bill will be high.\nSimilarly to why we encourage a big group of visiting relatives to take shorter showers to conserve water, on the data team we work to steward resources effectively. This means we must identify wasted resources to recapture them.\nIt's important that our operating expenses not balloon with headcount.\n\n## Are you protected against a leak?\n\nAs a homeowner, I can share a myriad of appliance-gone-wrong stories, but one tops them all: the time there was a leak in our front yard that we only discovered because of a $1,000 water bill.\nOften, homeowners can only measure water usage when the bill arrives, when it's always too late to fix it.\n\nLucky for our team and yours, Snowflake is much more generous than my water company.\nWe *can* monitor our costs as it accrues.\nAfter having this process in place for a bit now, we'd encourage you to implement it in your stack.\n\n## Monitor your Snowflake spend with dbt and Periscope\n\nWe're excited to make our [Snowflake spend dbt package](https://gitlab.com/gitlab-data/snowflake_spend) widely available for use.\nDoing this is in line with our belief in the value of [open source analytics](/blog/open-source-analytics/).\n\nTo get started, you'll need to grant access to the `snowflake` database to your dbt-specific role with:\n```\nGRANT IMPORTED PRIVILEGES ON DATABASE snowflake TO ROLE \u003Crole>;\n```\n\nThen you'll need to update the `packages.yml` file in your dbt project to include the following:\n```\npackages:\n  - git: https://gitlab.com/gitlab-data/snowflake_spend.git\n    revision: v1.0.0\n```\n\nToday, you can only install the package directly from Git.\nSince it doesn't depend on any other packages, you don't have to worry about version management, so this should not cause any problems.\nYou can run `dbt deps` to ensure the package is installed correctly.\n\nYou will need a csv called `snowflake_contract_rates.csv` which has two columns: effective date and rate. The effective date is the day the new contracted rate started and it should be in YYYY-MM-DD format. The rate is the per credit price for the given time period. You can see how the data team configures [their csv file](https://gitlab.com/gitlab-data/analytics/blob/master/transform/snowflake-dbt/data/snowflake_contract_rates.csv). You will need to run `dbt seed` for the csv to be loaded as a table and for the model to run succesfully.\n\nFinally, you will need to update your `dbt_project.yml` file to enable this package with the following block.\n```\nmodels:\n  snowflake_spend:\n    enabled: true\n```\nYou can see [how the data team has configured the package](https://gitlab.com/gitlab-data/analytics/blob/master/transform/snowflake-dbt/dbt_project.yml#L68) in our `dbt_project.yml` file.\n\nRunning `dbt compile` will not only test that you've configured all of this correctly, but also will compile the files in the `analysis` directory. These are the queries that we use to underlie the exact Periscope dashboard that we have automatically posted in Slack every day.\n\n![GitLab's Periscope dashboard for managing Snowflake spend](https://about.gitlab.com/images/blogimages/periscope_snowflake_spend1.png){: .shadow.medium.center}\n![GitLab's Periscope dashboard for managing Snowflake spend](https://about.gitlab.com/images/blogimages/periscope_snowflake_spend2.png){: .shadow.medium.center}\n\nOnce you've set up this dashboard, you can configure it to auto-refresh daily.\nThen use Slack's `/remind app.periscopedata.com/dashboardurl` to have it regularly publish in the channel of your choice.\n\nYou can see how our resource management initiatives have been effective.\nWe hope you'll find monitoring a key step to helping manage your own Snowflake spend.\n\nHave any thoughts, questions, or suggestions? [Create an issue](https://gitlab.com/gitlab-data/snowflake_spend/issues).\n\nPhoto by [Taylor Vick](https://unsplash.com/photos/M5tzZtFCOfs) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[864,268,675,2165],{"slug":2365,"featured":6,"template":679},"managing-your-snowflake-spend-with-periscope-and-dbt","content:en-us:blog:managing-your-snowflake-spend-with-periscope-and-dbt.yml","Managing Your Snowflake Spend With Periscope And Dbt","en-us/blog/managing-your-snowflake-spend-with-periscope-and-dbt.yml","en-us/blog/managing-your-snowflake-spend-with-periscope-and-dbt",{"_path":2371,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2372,"content":2377,"config":2382,"_id":2384,"_type":16,"title":2385,"_source":17,"_file":2386,"_stem":2387,"_extension":20},"/en-us/blog/katrin-contributor-post",{"title":2373,"description":2374,"ogTitle":2373,"ogDescription":2374,"noIndex":6,"ogImage":2158,"ogUrl":2375,"ogSiteName":713,"ogType":714,"canonicalUrls":2375,"schema":2376},"Meet GitLab Contributor Katrin Leinweber","Katrin Leinweber shares her experience contributing to GitLab documentation and translations.","https://about.gitlab.com/blog/katrin-contributor-post","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Meet GitLab Contributor Katrin Leinweber\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2019-07-17\",\n      }",{"title":2373,"description":2374,"authors":2378,"heroImage":2158,"date":2379,"body":2380,"category":14,"tags":2381},[1840],"2019-07-17","\n\nFor this edition of the [GitLab contributor blog posts](/blog/tags.html#contributors), I'm\nexcited to introduce [Katrin Leinweber](https://gitlab.com/katrinleinweber). Let's get to know more about her!\n\n### Can you tell us where you live and what you like about your area?\n\nI live in [Hanover, Germany](https://www.google.com/maps/place/Hanover,+Germany/@52.3815678,9.6148482,10.97z/data=!4m5!3m4!1s0x47b00b514d494f85:0x425ac6d94ac4720!8m2!3d52.3758916!4d9.7320104),\nwhich is transitioning from a car manufacturing hub to a more modern and diversified city.\nThe city is reasonably bicycle friendly with large parks and gardens, which are worth a visit.\nI don't find Hanover too touristy, which is probably a plus for us citizens.\n\n### How long have you used GitLab and why did you want to make a contribution?\n\nI started using GitLab CE at my university in April 2015 as a backup server for my PhD thesis,\ndata analysis scripts, etc. [My first merge request](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/6531)\nwas simply fixing a typo in a blog post.\n\n### You also help translating GitLab into German. How is that different from making contributions via MRs and why is translating GitLab important to you?\n\nLocalization is one of the tasks that got me into contributing to open source software projects in general.\nEven though I myself don't need a localized UI, I think it's valuable to many people to be able to\nuse a complex software in their native language. Since I think that GitLab has\n[valuable uses beyond programming](https://openbiblio.social/@katrinleinweber/102258903864249981),\nI hope lowering the barrier to entry for non-programmers will help support those use cases.\nAlso for me, doing quick translations is a sort of productive procrastination.\n\n![Canoeing on Hanover's river Leine (image credit Corinna John, [NABU Laatzen](https://www.nabu-laatzen.de/)](https://about.gitlab.com/images/blogimages/Katrin_Leinweber.jpg){: .shadow.medium.center}\nCanoeing on Hanover's river Leine\n{: .note.text-center}\n\n### What has been your experience contributing to GitLab?\n\nTechnically, it's pretty straightforward and something people should be familiar with if\nthey've contributed to other projects or used tools like GitHub. Every time I contribute,\nI feel like I'm living (in) the future where projects allow people to change something of theirs.\n\nHowever, we shouldn't forget that \"No, this Wiki page is only editable by colleagues in the XYZ department\"\nis still the default in so many work environments. So the future isn't quite here for everyone yet.\n\nOne of the things that bothers me about GitLab's contribution process is the fact that even simple changes\n– like documentation updates – get pushed into the same CI pipeline as code changes in many cases.\nIt seems like a waste of electricity. Maybe not in terms of absolute kWh, but since the risk of anything\nbreaking due to a typo fix or an updated hyperlink is almost zero, those kWh are effectively wasted.\nThere should be a smarter way to minimize human effort in preventing build breakages than to use\nmore CPU cycles for testing. We all know that humanity can't afford to waste resources anymore.\n\nIn that vein, I wouldn't mind seeing GitLab also supporting the renewable energy industry as\nI don't see that listed in the\n[market segmentation page](/handbook/marketing/strategic-marketing/market-segmentation/#oil--gasenergy) yet.\n\n### Do you participate in other open source projects? If yes, what do you like about other communities and what are some of the things that GitLab can learn?\n\nI do, for example in [The Carpentries](https://carpentries.org/teach/), which provides Open Educational\nResources and basic programming training for researchers. I find the GitLab community is\nquite thoughtful about sharing what they learn about successfully pushing the product and\nthe company forward. So I think other open source projects will find lots of advice in GitLab's\nblog and handbook that is worth considering.\n\n### What do you like to do when you're not working?\n\nI enjoy gardening and going cycling, hiking, and canoeing.\n\n### Anything else you want to share with the community?\n\nWherever appropriate, use [`[skip ci]`](https://docs.gitlab.com/ee/ci/pipelines/#skip-a-pipeline)\nmore often in your commit messages and MR titles.\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can\nlearn how you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[268,675,865],{"slug":2383,"featured":6,"template":679},"katrin-contributor-post","content:en-us:blog:katrin-contributor-post.yml","Katrin Contributor Post","en-us/blog/katrin-contributor-post.yml","en-us/blog/katrin-contributor-post",{"_path":2389,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2390,"content":2396,"config":2401,"_id":2403,"_type":16,"title":2404,"_source":17,"_file":2405,"_stem":2406,"_extension":20},"/en-us/blog/thoughts-on-open-source",{"title":2391,"description":2392,"ogTitle":2391,"ogDescription":2392,"noIndex":6,"ogImage":2393,"ogUrl":2394,"ogSiteName":713,"ogType":714,"canonicalUrls":2394,"schema":2395},"What to consider with an open source business model","CEO Sid Sijbrandij discusses the role of transparency and contribution in an open source business model.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682919/Blog/Hero%20Images/opensourcecover.jpg","https://about.gitlab.com/blog/thoughts-on-open-source","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What to consider with an open source business model\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2019-07-05\",\n      }",{"title":2391,"description":2392,"authors":2397,"heroImage":2393,"date":2398,"body":2399,"category":14,"tags":2400},[1860],"2019-07-05","\nAn open source business model used to be relatively rare but successes at companies like Red Hat and our own have changed that. As the idea of open source continues to gain traction with startups, our CEO [Sid Sijbrandij](/company/team/#sytses) talked with [OSS Capital](https://oss.capital) founder Joseph “JJ” Jacks about some of the changing – and nuanced – requirements to play in this complicated and competitive space.\n\n## How to build a business model for open source software businesses\n\nOpen source has always required a social contract between the owners of the project and the community that uses and contributes to it, Sid explains, and that’s something GitLab benefited from when the company was experimenting with the idea of [how to get paid](/blog/monetizing-and-being-open-source/). But today, with an [“open core” business model](/blog/gitlab-is-open-core-github-is-closed-source/) involving both open source and proprietary code, there’s another level, one where the community can have a much bigger voice on releases. “How much of what you make ends up in the open source and how much is proprietary?” Sid asks. “We try to find a good balance then when we go for a few releases where we're a bit weak on the open source side, people will post comments on our blog post and we can point to the stuff that's coming down the pipe. The wider community keeps us honest.”\n\nJJ, whose company is focused on investing in commercial open source startups, asks Sid about the ways open source licensing has changed. It’s a broad landscape, Sid offers: “You can go from the free software movement to open source to open core to these new licenses that are now made by Redis and Mongo and Confluent, the so-called non-compete licenses, which say it's kind of open source except if you're a hyper cloud, then you have to pay us.”\n\nThe “freemium” business model has also come along. “(That) makes it very easy to get trials and you can use it for free for a long time, but it's commercial. And then you have the completely proprietary Oracle light model. So licensing is much more of a spectrum today.”\n\n> The wider community keeps us honest.\n\n## Time to contribute\n\nThe spectrum of licensing isn’t necessarily a bad thing. Sid points to the free software movement that requires a user to contribute as a positive sign, but admits there is still a long way to go before this behavior is second nature. Companies try to put restrictions in, or to enforce things via copyright, Sid says, “but we’re not there yet, not by a long stretch. Lots of car manufacturers don’t contribute back to Linux so please start doing that everyone.”\n\nOf course, contributions from the community can only take a company so far. “Open core allowed us to compete with the proprietary vendors,” Sid says. “GitLab would not have survived as an open source project because open source projects sometimes implode under their popularity. There are some great examples of projects that did well – Kubernetes, Linux, and PostgreSQL – but without our business model we would not be able to compete at this point in this market with Microsoft and Atlassian.”\n\n> Open core allowed us to compete with the proprietary vendors.\n\n## Transparency in all things\n\nJJ wonders how much transparency and expectation setting have helped GitLab as an open core company, and Sid’s quick to point out it’s essential. “[Transparency](https://handbook.gitlab.com/handbook/values/#transparency) is in our top three values and we started with that because we didn’t want to alienate the wider community.” Transparency shortens the feedback loop and makes it more straightforward to deal with mistakes or challenging situations. When we [decided to merge both of GitLab’s code bases](/blog/merging-ce-and-ee-codebases/), we did it openly and honestly, wrote a blog post about it, and then waited to see how it was received. “I think by being transparent about our plan up front, what could have turned into a big flame war was a really positive experience for both the people at the company working really hard on this project, but also the wider community feeling like we take their interests seriously. And if we would have made a mistake, this was a proposal. They could have just said, ‘Okay, you're making a mistake here and there,’ and we could have fixed it before people were upset, and we lost trust.”\n\nWould Sid recommend “transparency first” to a startup open core company? Absolutely and it has to be there from the beginning, he says. “Values are really hard to introduce later in a company. I'm pushing for a bit more transparency now, and it's super, super, super, super hard. So, if you plan to do it, do it from the start, and (understand) it feels very counterintuitive to be open. And there are some areas where it's naturally harder to be as transparent. Security comes to mind. So, it's a daily struggle. People see that it works, but it requires effort at any layer of the company to actually do it, but I'm really proud of how far we've come.”\n\n_GitLab CEO Sid Sijbrandij occasionally sits down for a \"[pick your brain](/handbook/eba/ceo-scheduling/#pick-your-brain-meetings)\"\nmeeting with people seeking advice on open source, remote work, or a discussion of other things related to GitLab. Read [other posts in the series here](/blog/tags.html#pick-your-brain)._\n\nCover image by [Natasha Miller](https://unsplash.com/@tashography?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com)\n{: .note}\n",[268,864,675,675],{"slug":2402,"featured":6,"template":679},"thoughts-on-open-source","content:en-us:blog:thoughts-on-open-source.yml","Thoughts On Open Source","en-us/blog/thoughts-on-open-source.yml","en-us/blog/thoughts-on-open-source",{"_path":2408,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2409,"content":2414,"config":2419,"_id":2421,"_type":16,"title":2422,"_source":17,"_file":2423,"_stem":2424,"_extension":20},"/en-us/blog/q2-hackathon-recap",{"title":2410,"description":2411,"ogTitle":2410,"ogDescription":2411,"noIndex":6,"ogImage":1737,"ogUrl":2412,"ogSiteName":713,"ogType":714,"canonicalUrls":2412,"schema":2413},"What went down at the Q2'2019 GitLab Hackathon","Here's a recap of GitLab community accomplishments during the Hackathon on May 29-30.","https://about.gitlab.com/blog/q2-hackathon-recap","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What went down at the Q2'2019 GitLab Hackathon\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2019-06-24\",\n      }",{"title":2410,"description":2411,"authors":2415,"heroImage":1737,"date":2416,"body":2417,"category":14,"tags":2418},[1840],"2019-06-24","\n\nThe GitLab community gathered on May 29-30 for the Q2 Hackathon, and I was again excited to see new contributors participating. We also had more people joining the tutorial sessions and watching the recordings on [the Hackathon playlist](https://www.youtube.com/playlist?list=PLFGfElNsQthapq-CyXBTVnT2yKqg1JrNh). I was surprised when one of the community members told me he joined the kickoff session when it was past 1am his time!\n\n![Hackathon playlist](https://about.gitlab.com/images/blogimages/Hackathon_playlist.png){: .shadow.medium.center}\n\n## So what did we accomplish?\n\nEven though the Hackathon was during a holiday week in many countries, [44 merge requests (MRs)](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/issues/18) were submitted and more than 30 of these MRs were merged within two weeks of the event. One of the things we did during this recent Hackathon was to maintain [a list of suggested issues](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/issues/17#suggested-issues-list), and one of the issues was picked up shortly after it was discussed during [the GitLab Monitor tutorial session](https://www.youtube.com/watch?v=mm_8wVjn808&list=PLFGfElNsQthapq-CyXBTVnT2yKqg1JrNh&index=3&t=0s). Now, that's what I call just-in-time hacking.\n\n## Hackathon prizes\n\nSimilar to past events, everyone who had MRs merged will receive a token of our appreciation for their contribution. During the Q2 Hackathon, [18 people](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/issues/20) had their MRs merged and we decided to award a second place prize along with the grand prize based on the number of MRs merged. I'm happy to announce that we have a tie for the second place with [Michel Engelen](https://gitlab.com/michel.engelen) and [Marc Schwede](https://gitlab.com/schwedenmut) who both had three MRs merged. The grand prize winner goes to [Marcel Amirault](https://gitlab.com/Ravlen) (a former [MVP](/community/mvp/)), with nine merged MRs.\n\nThanks and congratulations to everyone!\n\n## When is the next Hackathon?\n\nSome of the feedback I received was a suggestion to release future Hackathon dates earlier, so I'm happy to announce that the Q3 Hackathon will take place on August 28-29. It is already advertised on [the Hackathon page](/community/hackathon/) with a new countdown clock. Please look out for more announcements as we get closer to the next Hackathon date. Also, if you have any suggestions for the Q3 Hackathon please feel free to bring them to [the GitLab Contributors Gitter](https://gitter.im/gitlabhq/contributors).\n\n![Q3 Hackathon date](https://about.gitlab.com/images/blogimages/Q3_hackathon_date.png){: .shadow.medium.center}\n\n## How do I get started with contributing?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n[\"GitLab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel) on Unsplash\n{: .note}\n",[268,864,675],{"slug":2420,"featured":6,"template":679},"q2-hackathon-recap","content:en-us:blog:q2-hackathon-recap.yml","Q2 Hackathon Recap","en-us/blog/q2-hackathon-recap.yml","en-us/blog/q2-hackathon-recap",{"_path":2426,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2427,"content":2432,"config":2437,"_id":2439,"_type":16,"title":2440,"_source":17,"_file":2441,"_stem":2442,"_extension":20},"/en-us/blog/cern-contributor-post",{"title":2428,"description":2429,"ogTitle":2428,"ogDescription":2429,"noIndex":6,"ogImage":2158,"ogUrl":2430,"ogSiteName":713,"ogType":714,"canonicalUrls":2430,"schema":2431},"GitLab Code Contributor: Daniel Juarez","Daniel Juarez shares his experience contributing to GitLab from CERN.","https://about.gitlab.com/blog/cern-contributor-post","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Code Contributor: Daniel Juarez\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2019-06-19\",\n      }",{"title":2428,"description":2429,"authors":2433,"heroImage":2158,"date":2434,"body":2435,"category":14,"tags":2436},[1840],"2019-06-19","\n\nFor this edition of the [GitLab contributor blog posts](/blog/tags.html#contributors), I'm excited to introduce [Daniel Juarez](https://gitlab.com/danieljg) from [CERN](https://home.cern/).\n\n### Can you tell us about you do at CERN and what Geneva is like?\n\nI started working at CERN in September 2017 as an associate for the Version Control Systems team. I came to CERN from the [University of Oviedo](http://www.uniovi.es/en) in Spain, as the university has an arrangement with CERN to give its students an opportunity to work here. One of my main responsibilities is to improve, maintain, and support the GitLab setup at CERN, as well as the continuous integration (CI) infrastructure.\n\n[Geneva](https://www.google.com/maps/place/Geneva,+Switzerland/@46.2050241,6.1089833,13z) feels like an extension of CERN, as you can meet people from all over the world with so many international organizations in the city. It may not be the best place in the winter if you are not into skiing, but the city has a wonderful lake and is full of life in the summer.\n\n![Daniel Juarez](https://about.gitlab.com/images/blogimages/Daniel_Juarez.jpeg){: .shadow.small.right.wrap-text}\n\n### How long have you used GitLab and why did you decide to make contributions?\n\nI first used GitLab when I joined CERN. Contributing to GitLab is part of my job, and [my first merge request (MR)](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/965) was on [the Runner project](https://gitlab.com/gitlab-org/gitlab-runner).\n\nIn addition to MRs, I create issues and work with the GitLab team to find solutions. A good example is the [storage performance issue](https://gitlab.com/gitlab-org/gitlab-ee/issues/11556) that we ran into recently.\n\n### Do you plan/coordinate contributions to GitLab at CERN or is contribution done on an individual basis? Any advice for GitLab customers who want to make contributions?\n\nWe keep track of our current GitLab issues and improvement areas in our internal Jira instance, and from there we organize who will submit an MR or open an issue with GitLab. We have a few other GitLab contributors at CERN, like [Alex Lossent](https://gitlab.com/alexcern) and [Borja Aparicio](https://gitlab.com/baparici).\n\nIn terms of advice for others, I encourage people to ping GitLab team members, such as product managers or maintainers, if you feel like your MRs or issues are not being picked up in a timely manner. You can find GitLab team members either on the [team page](/company/team/) or the [product categories page](/handbook/product/categories/). It's also helpful to note how many users are being impacted by your issue. Even though only one person from your organization may be commenting on an issue or MR, it could actually have an impact on thousands of people.\n\n### What has been your experience when contributing to GitLab?\n\nGitLab team members are always eager to help. They show interest in community issues and MRs, which is highly appreciated. Engagement from the GitLab team has helped us improve the service we provide to ~16,000 GitLab users at CERN.\n\nHowever, we are concerned about the large number of open issues at GitLab. Even if issues have the `customer` label, we are concerned that sometimes they could be forgotten.\n\n### Are there any community contributions (MRs) to GitLab that you thought were particularly interesting/useful?\n\nFrom CERN, we were definitely happy to have [SAML support](/releases/2015/06/22/gitlab-7-12-released/) a few years ago. We also found [Shared CI Runners for groups](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9646) to be helpful, because some of our users were required to have the same runner registered against multiple projects instead of having it per group. This clearly improved the service for many of our users that rely on private runners and cannot use our shared infrastructure.\n\n### What do you like to do when you're not working?\n\nI love playing video games no matter the genre. Recently, I started watching bad movies and learning to cook new dishes (usually at the same time). I find that cooking helps me digest the bad movies!\n\n### Anything else you want to share with the community?\n\nDo not be afraid to submit MRs! It might look difficult in the beginning, but GitLab team members will do their best to help your changes \"go upstream\" to GitLab. I learned that wider community members are also willing to help.\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[268,864,675,865],{"slug":2438,"featured":6,"template":679},"cern-contributor-post","content:en-us:blog:cern-contributor-post.yml","Cern Contributor Post","en-us/blog/cern-contributor-post.yml","en-us/blog/cern-contributor-post",{"_path":2444,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2445,"content":2451,"config":2456,"_id":2458,"_type":16,"title":2459,"_source":17,"_file":2460,"_stem":2461,"_extension":20},"/en-us/blog/1-mil-merge-requests",{"title":2446,"description":2447,"ogTitle":2446,"ogDescription":2447,"noIndex":6,"ogImage":2448,"ogUrl":2449,"ogSiteName":713,"ogType":714,"canonicalUrls":2449,"schema":2450},"You contributed 1 million merge requests in a month!","GitLab.com surpassed 1 million merge requests in March 2019, hitting a new record for monthly engagement.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680631/Blog/Hero%20Images/1m-merge-requests-cover.png","https://about.gitlab.com/blog/1-mil-merge-requests","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"You contributed 1 million merge requests in a month!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2019-06-06\",\n      }",{"title":2446,"description":2447,"authors":2452,"heroImage":2448,"date":2453,"body":2454,"category":14,"tags":2455},[1684],"2019-06-06","\n\nWhile the open source community comes together this week to celebrate the [fifth anniversary of Kubernetes](https://www.eventbrite.com/e/kubernetes-5th-anniversary-celebration-tickets-62064099392?aff=ebdssbdestsearch), at GitLab, we've hit a milestone of our own 🎉\n\nGitLab.com received a record **1 million merge requests** (MRs) in March 2019, the largest number of monthly MRs since the project began. The increase in engagement continued through April, when another million MRs were created. There was a 17% spike in the number of merge requests between February and March 2019 – a significant increase in engagement.\n\nThe amount of monthly MR activity has outpaced the number of active monthly users on GitLab.com. In fact, the number of new MRs per active user has increased by 40% year-over-year (May 2019 vs. May 2018). The primary driver of this spike is MRs in private projects on GitLab.com, indicating there is opportunity to increase the wider community's engagement in public projects.\n\n## Everyone can contribute\n\nWe built GitLab so [everyone can contribute](/company/mission/#mission)! We regularly receive MRs from software developers, project managers, and writers (like me!) pertaining to different private and public projects.\n\nGitLab may be a DevOps tool, but these MRs are in no way limited to developer activities. GitLab was designed so contributors can collaborate on projects, taking an idea from the conceptual to the actionable through a series of iterative changes. These 1 million MRs in March 2019 don’t all represent monumental changes to GitLab. Instead, they represent a million different ways the community has contributed to GitLab.\n\n\"Our [ambitious, shared vision](/direction/#vision) to make it easier and faster to innovate with a [single application](/handbook/product/single-application/) is only achievable with the support of the wider community,\" says Jeremy Watson, senior product manager for the Manage team at GitLab. \"We can't do it alone; we're happy to welcome first-time contributors, and [members of the community can help in a variety of ways](/community/contribute/) – even if you're not comfortable with contributing with code.\"\n\n\"We've had about 40-50 new contributors in the past six to seven releases,\" adds Ray Paik, code contributor program manager. \"These are first-time contributors who had their MRs merged.\"\n\nWe see MRs that span highly technical topics, such as executing on our [monitoring product roadmap](/direction/monitor/), to MRs that are more operational, such as making improvements to the GitLab onboarding process. A lot of first-time contributors start by making improvements to our documentation, which doesn't involve writing code at all. There's also [more to contributing than submitting MRs](/blog/how-do-you-contribute/)!\n\nSo whether you spot a typo in the [GitLab handbook](/handbook/), or want to [contribute to our documentation](/community/contribute/), start a conversation with us and open an issue or submit an MR today.\n",[268,675],{"slug":2457,"featured":6,"template":679},"1-mil-merge-requests","content:en-us:blog:1-mil-merge-requests.yml","1 Mil Merge Requests","en-us/blog/1-mil-merge-requests.yml","en-us/blog/1-mil-merge-requests",{"_path":2463,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2464,"content":2470,"config":2476,"_id":2478,"_type":16,"title":2479,"_source":17,"_file":2480,"_stem":2481,"_extension":20},"/en-us/blog/fluentd-using-gitlab-ci-cd",{"title":2465,"description":2466,"ogTitle":2465,"ogDescription":2466,"noIndex":6,"ogImage":2467,"ogUrl":2468,"ogSiteName":713,"ogType":714,"canonicalUrls":2468,"schema":2469},"Thanks Fluentd for betting on GitLab CI/CD!","We're happy to support fresh CNCF graduate Fluentd with GitLab CI/CD, and excited about their latest innovation offering stream processing on the edge.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678614/Blog/Hero%20Images/gitlab-fluentd.png","https://about.gitlab.com/blog/fluentd-using-gitlab-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Thanks Fluentd for betting on GitLab CI/CD!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Priyanka Sharma\"}],\n        \"datePublished\": \"2019-05-21\",\n      }",{"title":2465,"description":2466,"authors":2471,"heroImage":2467,"date":2472,"body":2473,"category":14,"tags":2474},[2278],"2019-05-21","\nFluentd, the [latest project to graduate](https://www.fluentd.org/blog/fluentd-cncf-graduation) in the CNCF, announced on stage at KubeCon Barcelona today that it is using [GitLab CI/CD](/solutions/continuous-integration/) for continuous integration. We are thrilled about the shout out and honored to support such an influential and innovative project.\n\nFor those who haven’t yet worked with Fluentd, it is an [open source data collector](https://www.fluentd.org/architecture), which lets you unify the data collection and consumption for a better use and understanding of data. Fluent Bit is their lighter-weight forwarder for those with exacting memory requirements. The project sports 7,868 stars on GitHub and their community has contributed more than 900 contributed plugins. They witness more than 100K downloads a day!\n\nThe latest innovation from Fluentd around [stream processing on the edge](https://docs.fluentbit.io/stream-processing/) can be very useful for our industry. As many of those who monitor large-scale, complex, distributed systems, run IoT businesses, or build smart cities will attest, more and more data is generated by these systems and analysis often needs to happen blazingly fast to be meaningful. The standard data analysis model, where it is first stored and indexed in a database (presumably in some cloud) and then analyzed, is not good enough for some real-time and complex analysis needs. The latencies associated with such data transfer may not be able to support applications involving time-critical, data-driven decision making. With Fluent bit, the Fluent team is looking to process the data while it's still in motion in the Log processor – bringing a lot of advantages of speed.\n\nWhile I am reading papers by others attempting to build stream processing on the edge, I find Fluentd’s efforts exciting because they already have major community traction and are part of companies’ observability workflows for logging. The [CNCF graduation criteria](https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc) that Fluentd met will further embolden enterprises to try it out, as part of the requirements are a diverse contributor community and security audits.\n\nWe've spent the past few months collaborating with Fluentd on their CI needs, and it's been very educational for us. We learned about the unique challenges that fast-moving projects in the CNCF face, and how we can be of assistance with our CI/CD offering. A large part of the answer is providing clear and consistent guidance around converting pipelines and then supporting the projects to success. If you are a CNCF project interested in working with GitLab CI/CD, holler at us and we’d be delighted to help.\n\nUntil then, enjoy KubeCon Barca!\n",[110,675,2475,1391,278,780],"demo",{"slug":2477,"featured":6,"template":679},"fluentd-using-gitlab-ci-cd","content:en-us:blog:fluentd-using-gitlab-ci-cd.yml","Fluentd Using Gitlab Ci Cd","en-us/blog/fluentd-using-gitlab-ci-cd.yml","en-us/blog/fluentd-using-gitlab-ci-cd",{"_path":2483,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2484,"content":2490,"config":2496,"_id":2498,"_type":16,"title":2499,"_source":17,"_file":2500,"_stem":2501,"_extension":20},"/en-us/blog/kubernetes-chat-with-joe-beda",{"title":2485,"description":2486,"ogTitle":2485,"ogDescription":2486,"noIndex":6,"ogImage":2487,"ogUrl":2488,"ogSiteName":713,"ogType":714,"canonicalUrls":2488,"schema":2489},"Kubernetes and the open source community: We chat with Joe Beda","Our CEO sits down with Kubernetes co-creator Joe Beda to talk about the future of open source.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680604/Blog/Hero%20Images/tech-explorers-cover.png","https://about.gitlab.com/blog/kubernetes-chat-with-joe-beda","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Kubernetes and the open source community: We chat with Joe Beda\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-05-20\",\n      }",{"title":2485,"description":2486,"authors":2491,"heroImage":2487,"date":2493,"body":2494,"category":14,"tags":2495},[2492],"Chrissie Buchanan","2019-05-20","\n\nJoe Beda is the Principal Engineer at VMWare and co-creator of Kubernetes. Beda and Craig McLuckie’s Google project to build a container orchestration tool has exploded and Kubernetes is now a large, open source community with thousands actively contributing to the project thanks to the [Cloud Native Computing Foundation](https://cncf.io/). In the world of open source they don’t get much better than Joe Beda, which is why we were thrilled to speak with him as part of our TechExplorers series where we sit down with the industry’s tech leaders.\n\nJoe and GitLab CEO [Sid Sijbrandij](/company/team/#sytses) went over a variety of topics like cloud native, Kubernetes, the business of open source, and many others. What was most interesting, but not surprising, was the integral role the open source community had in the success of these projects.\n\n“I think open source is evolving… It’s never been something that’s sat still. One of the lessons from Kubernetes more than anything else is that open source today is about community, if not more than code,” Beda says. He admits that right now is a tumultuous time for open source, with the line between product and project getting blurred. The “business” of open source can sometimes alienate the community that supported these initiatives in the first place, something many leaders will have to navigate in the years ahead.\n\n“It’s like there’s the code and the license for the code, and then there’s the community that builds around it. And even if it’s not a legal contract, I think there’s a social contract between the leaders of an open source project and the people who are members of that community. And I think you have to be very respectful of that social contract.”\n\nOne of the most important things an open source project can do to maintain the trust of the community, according to Beda, is to be very explicit about its motivations from the beginning. At GitLab, we’ve taken this message to heart and have [our promises to the open source community](/company/stewardship/) public on our website.\n\nKubernetes has already made a major impact on the way we deploy applications, and users continue to contribute and add to the project. “I think I’m still blown away with just the diversity of the projects that are building on top of Kubernetes,” he says. Even with recent challenges, Beda’s encouraged at the innovation he continues to see in open source. It all boils down to buy-in from the community and giving them the tools to keep innovating. “I think this is part of the excitement... There is a really vibrant set of projects that are experimenting, trying things out. And it’s going to be the users who decide what’s successful here.”\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/6IlyxHFedpo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nVideo directed and produced by [Aricka Flowers](/company/team/#arickaflowers)\n{: .note}\n\n\n## Takeaways\n\n\n### On the future of open source:\n\n>“I think open source is evolving… It’s never been something that’s sat still. One of the lessons from Kubernetes more than anything else is that open source today is about community, if not more than code.”\n\n\n### On building an open source company:\n\n>“My advice to anybody who is building a company around open source is to understand sort of where are your levers, where is the value that you’re adding, and try and be creative about finding ways to add value where something like this can’t happen.”\n\n\n### On the early days of Kubernetes:\n\n>“The real story is that there was a set of us that just wanted to be able to hack on some stuff and not have to go through all the process of shipping stuff to Google… But also we very much had the idea from the start that we wanted to build a community. We wanted to enable other people to own it, to be part of it, to really feel like they were instrumental in making it happen. And that’s what happened.”\n\n\n### On enterprise cloud adoption:\n\n>“I think that as we start to see these enterprises start to adopt cloud, understanding the power dynamics and the relationship with cloud, I think that there is a lot of concern about how do I get some independent advice, independent thought, independent support that’s going to actually stay with me as I figure out where my position lands as I move from on-prem to cloud and beyond.”\n\nWe’ll be at KubeCon Barcelona May 20 – 23, booth #S21. Learn how you can get started with GitLab and Kubernetes, and be sure to check out Joe Beda’s keynote on May 21.\n",[1434,1391,780],{"slug":2497,"featured":6,"template":679},"kubernetes-chat-with-joe-beda","content:en-us:blog:kubernetes-chat-with-joe-beda.yml","Kubernetes Chat With Joe Beda","en-us/blog/kubernetes-chat-with-joe-beda.yml","en-us/blog/kubernetes-chat-with-joe-beda",{"_path":2503,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2504,"content":2510,"config":2515,"_id":2517,"_type":16,"title":2518,"_source":17,"_file":2519,"_stem":2520,"_extension":20},"/en-us/blog/kubernetes-kubecon-barcelona",{"title":2505,"description":2506,"ogTitle":2505,"ogDescription":2506,"noIndex":6,"ogImage":2507,"ogUrl":2508,"ogSiteName":713,"ogType":714,"canonicalUrls":2508,"schema":2509},"See you at KubeCon Barcelona!","We're excited to see you all in Barcelona! Visit us at booth S21.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664107/Blog/Hero%20Images/tanuki-adventure.png","https://about.gitlab.com/blog/kubernetes-kubecon-barcelona","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"See you at KubeCon Barcelona!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Priyanka Sharma\"}],\n        \"datePublished\": \"2019-05-17\",\n      }",{"title":2505,"description":2506,"authors":2511,"heroImage":2507,"date":2512,"body":2513,"category":14,"tags":2514},[2278],"2019-05-17","\nKubeCon is here again! I am very excited to go to Barcelona and meet (some of) the 12,000 attendees expected at the show. I’ve been part of KubeCon since the second event when there were 700 attendees. That year, we were a cozy community with about five projects, and Kubernetes was the newest game in town. Fast forward to today and I now serve on the board of the CNCF, Kubernetes is a stable technology, the foundation hosts 36 projects, and the latest of them to graduate will be Fluentd (after Kubernetes, Prometheus, CoreDNS, Envoy, and Containerd). I can’t quite reveal it yet, but there will be a very cool GitLab story intertwined with one of the projects that you will see for yourself soon :-).\n\n\u003Cscript type=\"text/javascript\" src=\"https://ssl.gstatic.com/trends_nrtr/1754_RC01/embed_loader.js\">\u003C/script> \u003Cscript type=\"text/javascript\"> trends.embed.renderExploreWidget(\"TIMESERIES\", {\"comparisonItem\":[{\"keyword\":\"kubernetes\",\"geo\":\"\",\"time\":\"today 5-y\"}],\"category\":0,\"property\":\"\"}, {\"exploreQuery\":\"date=today%205-y&q=kubernetes\",\"guestPath\":\"https://trends.google.com:443/trends/embed/\"}); \u003C/script>\n*\u003Csmall>Kubernetes growth over the past 5 years.\u003C/small>*\n\nAs some of you know, I joined GitLab after following the company and our CEO, Sid Sijbrandij, for a long time. Working at this dynamic company has been a ride of a lifetime. I am an open source person and one of the interesting things for me is how the [GitLab story](/company/history/) is similar to the Kubernetes story. GitLab started as an open source git provider because our co-founder, [Dmitriy \"DZ\" Zaphorozhets](/company/team/#dzaporozhets) didn’t like his options. Today, we have morphed into a [single application for the entire DevOps lifecycle](/stages-devops-lifecycle/). Similarly, Kubernetes comes from humble beginnings. In the words of Joe Beda, co-founder of Kubernetes, “there were a set of us that just wanted to be able to hack on some stuff and not have to go through all the process of shipping stuff to Google...it was more important for us to sort of reset the playing field between clouds. And so Kubernetes became a way for us to start doing that.”\n\nIt’s exciting to watch Kubernetes grow into the default container orchestration platform but I believe the best is yet to come: When the technology truly shifts left and every developer has access to it. That’s where GitLab comes in. With it’s deep focus on the developer workflow, the product brings efficiency, collaboration, and governance to teams sprawling the world wide web (a la GitLab itself) or small groups working out of a garage. When everything’s in the MR, everything is accessible including details on your kubernetes pods. I invite you to learn more about how we [integrate with Kubernetes](/solutions/kubernetes/).\n\n> “The only way in my opinion to make it easier for most end users to have a \"cloud-native\" experience is to provide a more end-to-end platform, a way that people can come together and they can edit code and review code and then actually do CI on that code and get that code shipped out to containers and have it be run with appropriate load balancing and observability.” — Matt Klein, Systems Engineer at Lyft\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/w0cZuG2Fcwo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n*\u003Csmall>Video directed and produced by [Aricka Flowers](/company/team/#arickaflowers).\u003C/small>*\n\n## Let's connect!\n\n[Meet us at booth S21](https://about.gitlab.com/events/kubecon/) for CI office hours, tanuki adventures, and iPad giveaways!\n\nI'd love to help any CNCF projects (and other folks!) consider [GitLab CI](/solutions/continuous-integration/). If you are interested, [DM me on Twitter](https://twitter.com/pritianka) and we can sit down and discuss.\n\n## Join us for these events\n\n### Monday, May 20\n\n#### Cloud-Native Transformation Summit Hosted by Sysdig | 9:00 am - 12:15 pm\n\nJoin Priyanka Sharma, Director of Technical Evangelism at GitLab, at this zero day KubeCon event. This event will look at how enterprise organizations are moving into production-level Kubernetes and transforming their applications and infrastructure operations into Cloud-Native technologies.\n[Learn more here](https://go.sysdig.com/cloud_native_transformation_summit_2019.html).\n\n#### Zero Trust in the Cloud Native Era at Cloud Native Security Day | 11:00 - 11:30 am\n\nPriyanka Sharma, Director of Technical Evangelism at GitLab covers zero trust in the era of cloud native. [Register here](https://go.twistlock.com/cloudnativesecurityday#agenda).\n\n#### The Future of CI/CD with Kubernetes | 2:40 - 3:20 pm\n\nJoin Dan Lorenc, Software Engineer at Google, Carlos Sanchez, Principal Software Engineer at CloudBees, and Priyanka Sharma, Director of Technical Evangelism at GitLab, and Rob Zuber, CTO at CircleCI for a discussion on the future of CI/CD with Kubernetes.[Learn more here](https://sched.co/N6FQ).\n\n#### Barcelona Free Software Meetup: Working in the Open with GitLab, Kubic with openSUSE | 7-9 pm\n\nJoin Jason Plum, a Senior Software Engineer, Distribution at GitLab, for a talk on GitLab’s open-core product. He’ll discuss contributing back to the community directly, as well as sharing insights on changing from Closed to Open.\n[RSVP here](https://www.meetup.com/Barcelona-Free-Software/events/260656266/).\n\n### Tuesday, May 21\n\n#### Tutorial: Cloud-Agnostic Serverless - Sebastien Goasguen, TriggerMesh & Priyanka Sharma, GitLab | 11:05 am - 12:30 pm\n\nIn this tutorial, we will leverage Knative, Google's Kubernetes-based open source platform to build, deploy, and manage modern serverless workloads. We will push serverless functions and apps to production on any cloud of choice and switch the provider as necessary. We will leverage GitLab and TriggerMesh technology in the tutorial and also share how developers can use other options.\nSign up for the tutorial through the KubeCon schedule [here](https://sched.co/MPgx).\n\n#### Multicloud 360 Event | 8:30 pm - Midnight\n\nJoin GitLab, Upbound, DigitalOcean, Google Cloud and CockroachDB for 360 views of Barcelona and a discussion of multicloud. [RSVP here](https://www.eventbrite.com/e/multicloud-360-tickets-60623662005) to reserve your spot.\n\n### Wednesday, May 22\n\n#### The Serverless Landscape and Event Driven Futures - Dee Kumar, Linux Foundation & Priyanka Sharma, GitLab | 2:00 -2:35 pm\n\nThere is a lot of curiosity and confusion around [serverless computing](/topics/serverless/). What is it? Who is it for? Is it a replacement for IaaS, PaaS, and containers? Does that mean the days of servers are over? The CNCF created the Serverless Working Group to explore the intersection of cloud native and serverless technology. [Learn more here](https://sched.co/MPeI).\n\n## Play #tanukiadventure\n\nJoin our #tanukiadventure! Grab your game card at our booth S21 to help guide your adventure in finding GitLab's partners. At each adventure stop, learn how they work with GitLab! Once complete, each partner will provide you with an exclusive GitLab collectible pin to celebrate our awesome partnership! The first 50 attendees to collect all 8 unique Tanuki pins will win our prized GitLab Tanuki hoodie!\n",[2107,1391,278,780,675],{"slug":2516,"featured":6,"template":679},"kubernetes-kubecon-barcelona","content:en-us:blog:kubernetes-kubecon-barcelona.yml","Kubernetes Kubecon Barcelona","en-us/blog/kubernetes-kubecon-barcelona.yml","en-us/blog/kubernetes-kubecon-barcelona",{"_path":2522,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2523,"content":2528,"config":2533,"_id":2535,"_type":16,"title":2536,"_source":17,"_file":2537,"_stem":2538,"_extension":20},"/en-us/blog/kubernetes-chat-with-kelsey-hightower",{"title":2524,"description":2525,"ogTitle":2524,"ogDescription":2525,"noIndex":6,"ogImage":2487,"ogUrl":2526,"ogSiteName":713,"ogType":714,"canonicalUrls":2526,"schema":2527},"Kubernetes and the future of cloud native: We chat with Kelsey Hightower","Our CEO sits down with Google Staff Developer Advocate Kelsey Hightower to talk fundamentals, the future of cloud native, and Kubernetes.","https://about.gitlab.com/blog/kubernetes-chat-with-kelsey-hightower","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Kubernetes and the future of cloud native: We chat with Kelsey Hightower\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-05-13\",\n      }",{"title":2524,"description":2525,"authors":2529,"heroImage":2487,"date":2530,"body":2531,"category":14,"tags":2532},[2492],"2019-05-13","\n\n[Kelsey Hightower](https://twitter.com/kelseyhightower) is a Staff Developer Advocate at Google, co-chair of KubeCon, the largest Kubernetes conference, and an avid open source technologist. Naturally, we couldn’t think of a better first subject for TechExplorers, a new blog series where we talk to the industry’s tech leaders.\n\nGitLab CEO [Sid Sijbrandij](/company/team/#sytses) sat down with Kelsey to talk about a variety of topics like cloud native, Kubernetes, infrastructure challenges, understanding new technology, and much more. One topic that came up again and again was fundamentals. Even with so many new technologies and methodologies out there – Kubernetes, [serverless](/topics/serverless/), cloud native – the basics of computing remain the same. It’s only when we understand the fundamentals and commit to building reliable code that we can make the most of these new platforms.\n\nOne of the biggest challenges Kelsey sees is the “all-or-nothing” approach. “Either I’m all serverless, or I’m all Kubernetes, or I’m all traditional infrastructure. That has never made sense in the history of computing,” he says. Ultimately, you don’t have to choose: Pick the platforms that work best for the job.\n\nGoing forward, Kelsey hopes that development continues to focus on high-level interfaces and hide the infrastructure underneath. Organizations want to have as little interaction with servers as possible. “That is what we’re trying to do. Anything more than that is noisy, and it’s kind of serving our own self-interest … We need those creative people not to be wasting time trying to build up a cloud platform before they can solve real problems.”\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/9OHNejqXOoo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nVideo directed and produced by [Aricka Flowers](/company/team/#arickaflowers)\n{: .note}\n\n## Takeaways\n\n### On early Kubernetes:\n\n>\"... When it first came out, just based on my previous experience as a system administrator, this is the thing you’re trying to build all those years. So, when I saw it, I immediately knew this thing solves my problems. So, I think I kind of attacked it as a contributor first. And someone who wanted to teach other people what I saw in it. Not sure if it was ever going to blow up or not. But it definitely had the right footprint when it came out.\"\n\n### On teaching others:\n\n>\"I usually try to explain things based on the fundamentals, and then break down the technology until we get to the bottom. So, whenever something new comes out, my guess is it’s not going to change how we do computing. That hasn’t changed in a long time ... Once you learn the three, four, five basic fundamentals, then you just look at the new technology, and you just work your way down.\"\n\n### On invisible infrastructure:\n\n>\"Forever, people have tried to build a thing where most of the organization **doesn’t think about servers**. So whether you’re using Kubernetes, or virtualization for that matter, the whole goal is that if I check in code, there should be very little interaction with infrastructure to get that deployed to customers. To me, serverless is just a reminder to us that we should focus on a high-level interface and hide the various infrastructure underneath.\"\n\n### On adopting cloud native platforms:\n\n>\"If you take your app that you wrote 20 years ago and neglect it all this time, you don’t have any of those kind of controls, and you just move that app into the cloud native type of design patterns, it’s going to be worse than what you had before … People have to understand that there’s tradeoffs. You’re going to have to _write more reliable code_ if you expect to be able to adopt these platforms.\"\n\n## On monoliths:\n\n>\"There’s nothing wrong with monoliths, honestly. People have gotten themselves in a spot where they can’t really update the code. It’s messy. The codebase is all over the place. And if you take that same mentality to functions, you’re just going to have a mess of functions that are going to be all over the place and not even know how to call them.\n\n>\"_Discipline is required no matter what the platform is._ People think platform will absolve them from discipline.\"\n",[1434,1391,780],{"slug":2534,"featured":6,"template":679},"kubernetes-chat-with-kelsey-hightower","content:en-us:blog:kubernetes-chat-with-kelsey-hightower.yml","Kubernetes Chat With Kelsey Hightower","en-us/blog/kubernetes-chat-with-kelsey-hightower.yml","en-us/blog/kubernetes-chat-with-kelsey-hightower",{"_path":2540,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2541,"content":2547,"config":2553,"_id":2555,"_type":16,"title":2556,"_source":17,"_file":2557,"_stem":2558,"_extension":20},"/en-us/blog/how-do-you-contribute",{"title":2542,"description":2543,"ogTitle":2542,"ogDescription":2543,"noIndex":6,"ogImage":2544,"ogUrl":2545,"ogSiteName":713,"ogType":714,"canonicalUrls":2545,"schema":2546},"How do you contribute?","Your contribution graph captures a moment in time like few things can, and we want to celebrate it.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679742/Blog/Hero%20Images/contribute-social-cover.png","https://about.gitlab.com/blog/how-do-you-contribute","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How do you contribute?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2019-05-07\",\n      }",{"title":2542,"description":2543,"authors":2548,"heroImage":2544,"date":2550,"body":2551,"category":14,"tags":2552},[2549],"Emily von Hoffmann","2019-05-07","\n\nContribution graphs tell the story of your year.\n\nEspecially when you’re a daily user, they have a funny way of capturing not only professional milestones, but personal ones too. Vacations, sabbaticals, and family leave are all captured by characteristic little gray squares where no work is done. Equally telling are the times when work overflows into the weekends, or when it forms those satisfyingly deep navy streaks for consecutive days with over 30 commits each.\n\n![Inner narration when I look at my contribution graph](https://about.gitlab.com/images/blogimages/contribute-social-launch/evh_contribution_graph.png){: .shadow.center.medium}\n*\u003Csmall>\u003Ccenter>Some inner narration when I look at my contribution graph\u003C/center>\u003C/small>*\n\nUsing GitLab, you don’t just have to commit code in order to get the visual feedback for all of your hard work. Actions like commenting, opening, and closing issues and merge requests are also included. Your contribution graph is as unique as your fingerprint. It captures a moment in time like few things can, and we want to celebrate it. Check out some examples from the GitLab team:\n\n#### Tackling weekend side projects 🙌\n\n![Weekend side projects](https://about.gitlab.com/images/blogimages/contribute-social-launch/brendan-activity.png){: .shadow.center.medium}\n\n\n#### Managing a team 🗣\n\n![Managing a team](https://about.gitlab.com/images/blogimages/contribute-social-launch/lee-activity.png){: .shadow.center.medium}\n\n\n#### Going on parental leave 🤗\n\n![Parental leave](https://about.gitlab.com/images/blogimages/contribute-social-launch/brittany-activity.png){: .shadow.center.medium}\n\n\n#### Producing GitLab videos 🎥\n\n![Producing GitLab videos](https://about.gitlab.com/images/blogimages/contribute-social-launch/aricka-activity.png){: .shadow.center.medium}\n\n\n#### Cultivating perfect weekends 🙏\n\n![Cultivating perfect weekends](https://about.gitlab.com/images/blogimages/contribute-social-launch/sean-activity.png){: .shadow.center.medium}\n\n\n#### Managing this blog! 📝\n\n![Managing this blog](https://about.gitlab.com/images/blogimages/contribute-social-launch/rebecca-activity.png){: .shadow.center.medium}\n\n\n#### Starting a new job 💜\n\n![Starting a new job](https://about.gitlab.com/images/blogimages/contribute-social-launch/jeff-activity.png){: .shadow.center.medium}\n\n\n#### Advancing in your role 💪\n\n![Adjusting to a new role](https://about.gitlab.com/images/blogimages/contribute-social-launch/emilie-activity.png){: .shadow.center.medium}\n\n\n#### Flexing your skills 💻\n\n![Mastering your craft](https://about.gitlab.com/images/blogimages/contribute-social-launch/taurie-activity.png){: .shadow.center.medium}\n\n\n## Everyone can #contribute\n\nAt GitLab, we believe that everyone can contribute, and that means you! Whether you build software yourself or enable others who do; whether you write code, contracts, or novels; whether you manage a team at work or in your own household, your tasks and timelines can find a home in GitLab.\n\nSo tell us about your contributions! While we’re at GitLab [Contribute](/events/gitlab-contribute/) in New Orleans, we want to hear about all the ways that you contribute. Tweet a screenshot of your activity using #contribute, and tell us about your year as represented by your GitLab profile. Tweeting with the hashtag will enter you to win a swag bag to deck you out in GitLab gear from head to toe 😍\n\nWe can't wait to hear from you! Tweet us [@gitlab](https://twitter.com/gitlab).\n",[268],{"slug":2554,"featured":6,"template":679},"how-do-you-contribute","content:en-us:blog:how-do-you-contribute.yml","How Do You Contribute","en-us/blog/how-do-you-contribute.yml","en-us/blog/how-do-you-contribute",{"_path":2560,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2561,"content":2566,"config":2571,"_id":2573,"_type":16,"title":2574,"_source":17,"_file":2575,"_stem":2576,"_extension":20},"/en-us/blog/contributor-program-update",{"title":2562,"description":2563,"ogTitle":2562,"ogDescription":2563,"noIndex":6,"ogImage":1737,"ogUrl":2564,"ogSiteName":713,"ogType":714,"canonicalUrls":2564,"schema":2565},"Updates from the GitLab contributor community","Here's what's happening with the wider contributor community.","https://about.gitlab.com/blog/contributor-program-update","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Updates from the GitLab contributor community\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2019-04-17\",\n      }",{"title":2562,"description":2563,"authors":2567,"heroImage":1737,"date":2568,"body":2569,"category":14,"tags":2570},[1840],"2019-04-17","\n\nI joined GitLab in June 2018, and it's been exciting to work with our wider community of contributors.\nOne of the first things I did when I started was to look into community metrics to get a better\nunderstanding of the community, and here are a couple of numbers I'd like to share:\n\nSince 2016, about 15 percent of merged MR for the [GitLab Community Edition](https://gitlab.com/gitlab-org/gitlab-ce)\nwere contributed by community members (see the chart below). In addition, we had over 200\nfirst-time contributors to GitLab between the 11.5 and 11.9 releases, and it's been fun seeing [people\ncelebrate their first merged MRs on Twitter](https://twitter.com/hashtag/myFirstMRmerged?src=hash).\n\n![Community contribution to CE](https://about.gitlab.com/images/blogimages/contributor-pgm-blogpost/CE_Merged_MRs_since_Jan_2016.png){: .medium.center}\n\nIt's definitely fun being part of a growing community, and I wanted to provide a quick update\non a number of items that we have been working on.\n\n## Core Team updates\n\n### Monthly calls\n\nThe [Core Team](/community/core-team/) consists of individuals who have made sustained contributions\nto GitLab and their mission is to represent the wider GitLab community.\nI started scheduling a regular call with Core Team members\nand I've been very impressed with the quality of discussions we have each month.\nCore Team members helped improve responsiveness to community contributions, Hackathons,\nand even revamped the Core Team page itself. Everyone is welcome to join the call, and the\nlogistics, notes, slides, etc. are available on the [Monthly Core Team meeting page](https://gitlab.com/gitlab-core-team/general/wikis/monthly-core-team-meeting).\nIf you want to watch recordings of previous meetings, you can check out the [Core Team meeting playlist](https://www.youtube.com/playlist?list=PLFGfElNsQthZ12EUkq3N9QlThvkf3WGnZ).\n\n![GitLab Core Team](https://about.gitlab.com/images/blogimages/contributor-pgm-blogpost/Core_Team.png){: .shadow.small.center}\n\n### New additions to the team\n\nThere have also been changes to the Core Team composition. To provide additional support,\nthere will be up to two GitLab company team members forming part of the\nCore Team. So, I'm excited to share that [Rémy Coutable](https://gitlab.com/rymai) and\n[Winnie Hellmann](https://gitlab.com/winh) are now members of the Core Team.\nWinnie was actually a Core Team member prior to joining GitLab, and Rémy has been working\nwith Core Team members for the past several years, so they're perfect additions to the team.\n\nIn addition to the two GitLab team-members, [Ben Bodenmiller](https://gitlab.com/bbodenmiller)\nand [George Tsiolis](https://gitlab.com/gtsiolis) joined the Core Team in the past several months.\nAs you will see in the next section, both Ben and George were two of the top code contributors in 2018.\n\n## Recognizing regular contributors\n\nIn addition to the Core Team members, we also have dozens of members of the wider community\nmaking regular contributions to GitLab. In order to recognize their work, I started a\n[top contributors page](/community/top-annual-contributors/index.html) and\nplan to update this each year to highlight regular contributors. Following examples from other\nopen source communities, we now have badging for three different levels of contributions.\nShortly, we will be sending out special GitLab merchandise to these contributors so they can\ncelebrate their accomplishments. My hope is that we will see an increase in the number of regular\ncontributors in the years to come. In addition to the number of contributors, I also want to improve the diversity of regular contributors – whether it's gender, geography, occupation, etc. – and will start a conversation on this topic in various forums, including the Core Team meeting. \n\n![Contributor badges](https://about.gitlab.com/images/blogimages/contributor-pgm-blogpost/contributor_badges.png){: .shadow.small.center}\n\n## \"Contribute for prize\" issues\n\nIf you participated in the [Q1 Hackathon](/blog/q1-hackathon-recap/),\nyou probably remember that we highlighted an issue in each [product stage](/handbook/product/categories/)\nto encourage people to contribute for a special hackathon prize. Following the success of this\nin the Hackathon, we created a new label `Contribute for prize` to encourage community members\nto work on priority issues on an ongoing basis. You can find more information in the [contributor success handbook page](/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows.html#supporting-the-wider-community-contributors)\nand I encourage everyone to [search for issues with the label `Contribute for prize`](https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Contribute%20for%20prize) to start working on them.\n\n## How do I get started with contributing?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n[\"Gitlab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel) on Unsplash\n{: .note}\n",[268,864,675],{"slug":2572,"featured":6,"template":679},"contributor-program-update","content:en-us:blog:contributor-program-update.yml","Contributor Program Update","en-us/blog/contributor-program-update.yml","en-us/blog/contributor-program-update",{"_path":2578,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2579,"content":2585,"config":2590,"_id":2592,"_type":16,"title":2593,"_source":17,"_file":2594,"_stem":2595,"_extension":20},"/en-us/blog/open-source-analytics",{"title":2580,"description":2581,"ogTitle":2580,"ogDescription":2581,"noIndex":6,"ogImage":2582,"ogUrl":2583,"ogSiteName":713,"ogType":714,"canonicalUrls":2583,"schema":2584},"4 Examples of the power of open source analytics","Our Data and Analytics team manager reflects on how open source and radical transparency has benefited analytics work at GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670464/Blog/Hero%20Images/gitlab-loves-open-source.jpg","https://about.gitlab.com/blog/open-source-analytics","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"4 Examples of the power of open source analytics\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Taylor Murphy\"}],\n        \"datePublished\": \"2019-04-15\",\n      }",{"title":2580,"description":2581,"authors":2586,"heroImage":2582,"date":2587,"body":2588,"category":14,"tags":2589},[2359],"2019-04-15","\nOne of the great parts of working for a company with such a strong [open source](/solutions/open-source/) ethos is that\nyou're able to apply this philosophy to other parts of the company. We on the Data Team\nhave worked hard to embody the [values of GitLab](https://handbook.gitlab.com/handbook/values/),\nparticularly collaboration and transparency.\n\nIt starts by defaulting to public for everything. Our [primary code repository](https://gitlab.com/gitlab-data/analytics/)\nis public and MIT licensed, meaning anybody can contribute or just take what they find useful.\nOur code, issues, and [documentation](/handbook/business-technology/data-team/) are public.\n\n## This radical transparency has had several positive side effects\n\n### The effect I'm most excited about is having people contribute to our codebase.\n\nWhen we were migrating to Snowflake for our data warehouse, we needed to convert our SQL code\nthat was specific to PostgreSQL to a Snowflake-compatible format.\nOne of the models in our codebase [generates a table](https://dbt.gitlabdata.com/#!/model/model.gitlab_snowflake.date_details) of dates and related metadata such as day of year, week of year, quarter, etc.\nAn external contributor, [Matthias Wirtz](https://gitlab.com/swiffer), who had been following our\nproject and the [Meltano](https://meltano.com/) project, took it upon himself to make the\nupdate and create a merge request in our project. We went back and forth a bit with code review\nand testing, but eventually [it was merged](https://gitlab.com/gitlab-data/analytics/merge_requests/476/diffs) and we now rely on this code today!\n\n### Another great benefit is that it makes conversations easier within the analytics community.\n\nA key part of our data stack is data build tool, or [dbt](https://www.getdbt.com/) for short.\nThis is a powerful open source project that makes version controlling and executing SQL code easy.\nThe company behind the project, [Fishtown Analytics](https://www.fishtownanalytics.com/),\nhosts a great community on [Slack](https://slack.getdbt.com/). I've been able to answer basic\nquestions about project structure, documentation, and testing just by linking to our codebase and\n[dbt-generated docs](https://dbt.gitlabdata.com)\ncountless times, and the feedback is always positive. We see people who are shocked that\nwe're so open but also appreciative that they can poke around a production codebase with ease.\n\n### An additional benefit that we've seen is that by putting everything out in the open we're helping to drive the industry forward.\n\nIt's one thing to say \"Here's what we're doing, but sorry you can't see the code\" versus\n\"Here's what we're doing, here's _how_ we're doing it, and what are your ideas to make it better?\"\nThe latter invites people into the conversation to build upon ideas and others' creations.\n\n### The last piece I want to highlight is the idea that the actual code that you use for analytics isn't your company's competitive advantage.\n\nYou could know exactly how we move, store, model, and analyze our data, and its utility for a\ncompetitor would primarily be to get their own analytics off the ground.\nThe real value is the data itself and the decisions people make from the results of your analyses.\nWe, of course, protect our data and our customers' data, but there's no reason why people\nshouldn't be able to see how we _use_ that data to make decisions. And, being a transparent company,\nwe're very open about the decisions we make as well.\n\nOverall, we're seeing the same transformation that software engineering underwent with the [DevOps\nmovement](/topics/devops/) happen in the analytics world, only with about a five-year lag.\nMore open source tools are being created for data teams every day, and more people are sharing\nhow they build their stacks and analyze their data. At GitLab, we're betting that our [core values](https://handbook.gitlab.com/handbook/values/)\ncan bring emergent positive benefits to every part of a company, including data teams!\nWe look forward to collaborating with you as this industry changes and grows!\n",[268,1765,675],{"slug":2591,"featured":6,"template":679},"open-source-analytics","content:en-us:blog:open-source-analytics.yml","Open Source Analytics","en-us/blog/open-source-analytics.yml","en-us/blog/open-source-analytics",{"_path":2597,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2598,"content":2603,"config":2608,"_id":2610,"_type":16,"title":2611,"_source":17,"_file":2612,"_stem":2613,"_extension":20},"/en-us/blog/marcel-amirault-contributor-post",{"title":2599,"description":2600,"ogTitle":2599,"ogDescription":2600,"noIndex":6,"ogImage":2158,"ogUrl":2601,"ogSiteName":713,"ogType":714,"canonicalUrls":2601,"schema":2602},"GitLab Code Contributor: Marcel Amirault","Recent MVP Marcel Amirault shares why he started contributing to GitLab.","https://about.gitlab.com/blog/marcel-amirault-contributor-post","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Code Contributor: Marcel Amirault\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2019-04-12\",\n      }",{"title":2599,"description":2600,"authors":2604,"heroImage":2158,"date":2605,"body":2606,"category":14,"tags":2607},[1840],"2019-04-12","\n\nI'm excited to continue the [series of GitLab contributor blog posts](/blog/tags.html#contributors)\nwith [Marcel Amirault](https://gitlab.com/Ravlen), [the MVP for the 11.9 release](/community/mvp/).\nLet's get to know more about him!\n\n### Can you tell us where you live and share anything interesting about your area?\n\nI'm originally from Halifax, in eastern Canada, but I now live in [Kagoshima, Japan](https://www.google.com/maps/place/Kagoshima,+Japan/@31.523208,130.2782569,10z/data=!3m1!4b1!4m5!3m4!1s0x353e615200e3c53d:0x9adcfdad5d5c5885!8m2!3d31.5968539!4d130.5571392) (and yes, I have seen wild tanuki!).\nKagoshima is famous for being right next to one of the world's most active volcanos, Sakurajima,\nwhich regularly dusts the city in ash. You have to keep an eye on the wind before you decide\nto put out your laundry, or else you'll have some ashy-grey clothes pretty quickly.\nIt's also known for inspiring some famous movies. Hometown hero Saigō Takamori and the\nlocal Satsuma clan were the inspirations for \"The Last Samurai,\" and Yakushima Island was\nthe inspiration for the forest in \"Princess Mononoke.\"\n\n![Picture of Sakurajima](https://about.gitlab.com/images/blogimages/Marcel-blogpost/kagoshima.png){: .shadow.small.center}\n*\u003Ccenter>\u003Csmall>Sakurajima in the distance\u003C/small>\u003C/center>*\n\n### Can you tell us what you do professionally?\n\nOriginally, I worked in IT Support, peaking as a Network Technician at a telecom company\nin eastern Canada. I loved the job, but I wanted to live abroad for a while before settling into my career.\nI decided to teach English in Japan \"for six months,\" but fell in love with the country and have\nbeen here ever since. I currently teach English as a second language to Japanese students, and\nhave taught all ages and types of students over the years. I write, proofread, and teach curricula\nfor various types of students, ranging from people preparing for their first trip abroad, to seminars\nin hospitals for medical professionals. From time to time I proofread documents brought to me,\nsuch as applications to international programs, or scientific papers being prepared for submission for peer review.\n\n![Marcel in the classroom](https://about.gitlab.com/images/blogimages/Marcel-blogpost/marcel-teaching.jpg){: .shadow.small.center}\n\n### When did you first contribute to GitLab and why did you decide to contribute?\n\nAbout a year ago, I started a Rails course to try to get back into the IT world, and needed to\nchoose a place to store my Git repo. A friend suggested GitLab, and I dove right in.\nWhile reading the documentation, I sometimes found small mistakes that the English teacher\nin me couldn't ignore, so I started submitting MRs for small things like typos or obvious grammar mistakes.\nIn fact, [my first MR](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/11848) was to correct grammar.\nFrom there, the MRs got a little bigger, and a little more involved, and it's something I enjoy doing when things are slow at work.\n\n### What was the most difficult part of contributing for you in the beginning?\n\nThere was no significant hurdle to starting, because contributing to documentation was not\nintimidating at all, and I never had to worry about complicated reviews.\nWhen I first submitted a small change to the language in a section of the UI though, I suddenly\nhad a lot of reviews and suggestions, and started to realize how a small change could have a large impact.\nUnderstanding the impact that one person could have on a major project was something I had to learn.\nThankfully, a lot of GitLab team-members offered help and explained things for me, which I really appreciated.\n\n### Which areas of GitLab have you contributed to most and how do you find issues that you want to work on?\n\nUpdating technical documentation was a natural fit for me. I enjoy learning, so I frequently\nread the GitLab documentation, but my \"English teacher eyes\" can't ignore language that can be improved.\nI take advantage of free time at work, and I'm fortunate to have free access to computers and\na flexible boss (as long as my lesson quality is maintained). As a result, I'm often able to fill\nthe gaps between lessons by working on documentation issues. When I'm struggling to stay\nawake because my kids kept me up at night and I have a gap in my schedule, working on an\ninteresting bit of documentation wakes me up as much as a strong cup of coffee!\nI usually find documentation that can be improved on my own as I read through, but I\nsometimes search for [`Accepting Merge Requests` issues for Documentation](https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Accepting%20merge%20requests&label_name[]=Documentation) if I need a new project to work on. Recently I have given myself \"challenges,\"\nlike \"Find ALL examples of a certain grammar mistake project wide, and fix them\" or\n\"Find ALL examples where CE and EE documentation have diverged accidentally, and realign them when possible.\"\n\n### What do you enjoy doing when you're not working?\n\nI like doing home improvements when I can, and really like outdoor carpentry like putting up\nfences or wooden decks. I'm a big fan of hiking and camping, but it has been hard to get out\nto camping places in the past few years as my kids are still young. We are hoping to bring them\non their second ever camping trip this spring/summer. Finally, my friends and I try to get together\nabout once every month or two for poker or board gaming. Some of my favorite games are\nSettlers of Catan, Carcassonne, Puerto Rico, Pandemic, San Juan, and Guillotine.\n\n![Marcel and his children](https://about.gitlab.com/images/blogimages/Marcel-blogpost/marcel-family.png){: .shadow.small.center}\n\n### What advice do you have for others who may be interested in contributing to GitLab?\n\nDon't be shy! If you are worried about your contribution, feel free to make your MR a [draft](https://docs.gitlab.com/ee/user/project/merge_requests/drafts.html)\n(document last updated by me! 😉), and ask for help. Everyone is super friendly and always willing to give advice!\n\n### Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn\nhow you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[268,864,675,865],{"slug":2609,"featured":6,"template":679},"marcel-amirault-contributor-post","content:en-us:blog:marcel-amirault-contributor-post.yml","Marcel Amirault Contributor Post","en-us/blog/marcel-amirault-contributor-post.yml","en-us/blog/marcel-amirault-contributor-post",{"_path":2615,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2616,"content":2622,"config":2628,"_id":2630,"_type":16,"title":2631,"_source":17,"_file":2632,"_stem":2633,"_extension":20},"/en-us/blog/five-ways-resist-service-wrapping-buyer-based-open-core",{"title":2617,"description":2618,"ogTitle":2617,"ogDescription":2618,"noIndex":6,"ogImage":2619,"ogUrl":2620,"ogSiteName":713,"ogType":714,"canonicalUrls":2620,"schema":2621},"5 Ways to resist the threat of service-wrapping with buyer-based open core","Commercial open source businesses are at risk of commoditization by hypercloud providers – here are some ways to avoid the trap.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680537/Blog/Hero%20Images/osls-buyer-based-open-source.jpg","https://about.gitlab.com/blog/five-ways-resist-service-wrapping-buyer-based-open-core","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 Ways to resist the threat of service-wrapping with buyer-based open core\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n        \"datePublished\": \"2019-04-03\",\n      }",{"title":2617,"description":2618,"authors":2623,"heroImage":2619,"date":2625,"body":2626,"category":14,"tags":2627},[2624],"Vanessa Wegner","2019-04-03","\n\nGitLab makes money as a commercial open source software (COSS) business. As you\nmight imagine, open source is at risk of becoming commoditized, just by its\ninherent characteristic of being completely … open. In today’s age of hyperclouds,\nopen source businesses are under threat of [service-wrapping via cloud\nproviders like Amazon](https://aws.amazon.com/blogs/aws/new-open-distro-for-elasticsearch/), Microsoft, and Google.\n\nTo avoid commoditization, [GitLab has tried a number of business models](/blog/monetizing-and-being-open-source/), from\ndonations to consultancy to single-tenant service, but none of them worked.\nFinally, we settled on open core. At this year’s Open Source Leadership Summit,\nour CEO [Sid Sijbrandij](/company/team/#sytses) talked about where GitLab has hedged its bet to avoid becoming obsolete.\nAs Sid describes in the presentation below, there are five key methods for resisting\ncommoditization with buyer-based open core.\n\n## Watch the presentation\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/G6ZupYzr_Zg\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Key takeaways\n\n### What is buyer-based open core?\n\nBuyer-based means that GitLab offers [four different tiers of the software](/pricing/), which offer different functionality based\non what each buyer persona needs.\n\n### How do you generate revenue with buyer-based open core?\n\nEach tier focuses on what the buyer wants – and nothing more. It is also priced\naccordingly. Those at a higher level in the organization often have more budget\nauthority – so they can spend budget on what provides value for them.\n\n### How can COSSes avoid commoditization?\n\n1. Insert proprietary functionality in a majority of your use cases.\n1. Offer many proprietary features.\n1. Offer interaction through a user interface, rather than through APIs.\n1. Cater to price-insensitive buyers.\n1. Attract users that rarely contribute to open source.\n\nLearn more about these best practices and how GitLab has implemented them by\n[watching Sid’s presentation](https://youtu.be/G6ZupYzr_Zg), or viewing his slides below:\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://docs.google.com/presentation/d/e/2PACX-1vRzKYXPPenZlKkbun3AklJP-xgrC4ga-AqBRyVxOAs2tczZ1VNNUGriYy0vF8iBccuT58rDcwateT3P/embed?start=false&loop=false&delayms=3000\" frameborder=\"0\" width=\"960\" height=\"569\" allowfullscreen=\"true\" mozallowfullscreen=\"true\" webkitallowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\nCover image by [Nastuh Abootalebi](https://unsplash.com/@sunday_digital) on\n[Unsplash](https://unsplash.com/photos/eHD8Y1Znfpk)\n{: .note}\n",[268,675,1765],{"slug":2629,"featured":6,"template":679},"five-ways-resist-service-wrapping-buyer-based-open-core","content:en-us:blog:five-ways-resist-service-wrapping-buyer-based-open-core.yml","Five Ways Resist Service Wrapping Buyer Based Open Core","en-us/blog/five-ways-resist-service-wrapping-buyer-based-open-core.yml","en-us/blog/five-ways-resist-service-wrapping-buyer-based-open-core",{"_path":2635,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2636,"content":2642,"config":2649,"_id":2651,"_type":16,"title":2652,"_source":17,"_file":2653,"_stem":2654,"_extension":20},"/en-us/blog/verizon-customer-story",{"title":2637,"description":2638,"ogTitle":2637,"ogDescription":2638,"noIndex":6,"ogImage":2639,"ogUrl":2640,"ogSiteName":713,"ogType":714,"canonicalUrls":2640,"schema":2641},"Verizon cuts datacenter rebuilds from 30 days to 8 hours","Verizon utilized microservices, automation, and GitLab to reduce datacenter rebuilds to under 8 hours.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678933/Blog/Hero%20Images/verizon_video_blog.jpg","https://about.gitlab.com/blog/verizon-customer-story","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How Verizon Connect reduced datacenter rebuilds from 30 days to under 8 hours with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kim Lock\"}],\n        \"datePublished\": \"2019-02-14\",\n      }",{"title":2643,"description":2638,"authors":2644,"heroImage":2639,"date":2646,"body":2647,"category":14,"tags":2648},"How Verizon Connect reduced datacenter rebuilds from 30 days to under 8 hours with GitLab",[2645],"Kim Lock","2019-02-14","\nIn 2016, the [Verizon Connect](https://www.verizonconnect.com/) Telematics Container Cloud Platform team was struggling with data center\nbuilds that took 30 days. Working with legacy systems that included Java-based, monolithic\napplications, they also had a variety of disparate tools including BitBucket, Jenkins, and Jira\nin use throughout their environment.\n\n### Starting from scratch to move to microservices and increase automation\n\nThe group looked to move to a [microservices architecture](/blog/strategies-microservices-architecture/) to improve deploy speed and increase\nautomation. They also wanted to overcome manual errors, disjointed processes, and\nmanual deploys. \"We were just spending too much time doing stuff manually, so we decided\nto just start fresh and write everything from scratch,\" says Mohammed Mehdi, Principal DevOps, Verizon.\n\nAs they created this new infrastructure, they kept four key components in mind: architecture,\nautomation, extensibility, and being proactive and prepared for the future. They wanted to rebuild\ntheir data centers in less than 12 hours, instead of 30 days. They had a goal of 100 percent CI/CD.\nThey wanted to remove manual deployments, especially around the server and network deployments.\nThe team also focused on avoiding vendor lock-in by seeking open source tools to help them accomplish these goals.\n\nThe team looked to improve automation by focusing on simplification, standardization, and providing end-to-end visibility.\n\"We wanted easily repeatable, with zero-touch, zero-downtime deployments, automated tracking,\" Mehdi explains.\n\n### A single solution to meet their needs\n\nThe team chose GitLab to support this infrastructure initiative because it met a number of their qualifications, including being open source and offering Windows support. The team liked that it is easy to use and the UI easy to understand.\n\n\"Some of the other features that we really loved, and we didn’t find with any other CI/CD tool, are the project management\nfeatures,\" Mehdi says. \"GitLab replaced a bunch of disparate systems for us like Jira, BitBucket, and Jenkins. GitLab\nprovided us with a one-stop solution.\"\n\nThe Verizon Connect Telematics Container Cloud Platform team is using GitLab for:\n\n- [Code review](/blog/demo-mastering-code-review-with-gitlab/)\n- [CI/CD](/solutions/continuous-integration/)\n- [Issue tracking](/pricing/feature-comparison/)\n- [Source Code Management](/solutions/source-code-management/)\n- [Audit Management](https://docs.gitlab.com/ee/administration/audit_events.html)\n- [ChatOps](https://docs.gitlab.com/ee/ci/chatops/)\n\nThe team has successfully achieved deployment flexibility and are platform agnostic. They now have\nstreamlined processes and developers can truly focus on differentiating tasks.\n\nThe team was able to reduce their complete datacenter deploy\nprocess to under eight hours because of the streamlined deploy and build processes\nthey enabled using GitLab. Learn how [Verizon Connect](https://www.verizonconnect.com/) is achieving this success by watching\nmore about their story and how they achieved their targets in [the YouTube video](https://youtu.be/zxMFaw5j6Zs) below.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/zxMFaw5j6Zs\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nThanks for giving GitLab a shot, Verizon Connect!\n\nCover image by [chuttersnap](https://unsplash.com/@chuttersnap) on [Unsplash](https://unsplash.com)\n{: .note}\n",[1475,110,1434,1583,1921],{"slug":2650,"featured":6,"template":679},"verizon-customer-story","content:en-us:blog:verizon-customer-story.yml","Verizon Customer Story","en-us/blog/verizon-customer-story.yml","en-us/blog/verizon-customer-story",{"_path":2656,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2657,"content":2663,"config":2670,"_id":2672,"_type":16,"title":2673,"_source":17,"_file":2674,"_stem":2675,"_extension":20},"/en-us/blog/donatinator-open-source-donation-platform",{"title":2658,"description":2659,"ogTitle":2658,"ogDescription":2659,"noIndex":6,"ogImage":2660,"ogUrl":2661,"ogSiteName":713,"ogType":714,"canonicalUrls":2661,"schema":2662},"The Donatinator: Simple donation solution for charities","This guest author shares his passion project: a free and open source solution for small charities and non-profits to accept donations online.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679940/Blog/Hero%20Images/donatinator-open-source.jpg","https://about.gitlab.com/blog/donatinator-open-source-donation-platform","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The Donatinator: A simple, secure way to accept donations to your charity or non-profit\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Andrew Chilton\"}],\n        \"datePublished\": \"2019-02-06\",\n      }",{"title":2664,"description":2659,"authors":2665,"heroImage":2660,"date":2667,"body":2668,"category":14,"tags":2669},"The Donatinator: A simple, secure way to accept donations to your charity or non-profit",[2666],"Andrew Chilton","2019-02-06","\n\nMany small non-profits or charity organizations all over the world find it really difficult to accept one-off donations or set up monthly subscriptions online. I know this from firsthand experience.\n\nLast year my wife came to me asking how the organization she volunteers at – a mothers’ support group – could accept donations on their website. My first thought was that the (free) hosting provider they were using would have a feature to do that, but no, not unless you pay, and for a small charity even $10 or $20 per month is too expensive.\n\nMy second thought was to investigate hosting or donation portals. Here's where the journey started.\n\n## Donation platforms offer a mixed bag\n\nAfter looking at various donation platforms, we realised that many differences exist and that you can't always have it all. Some of them:\n\n* Are only http unless you pay up front.\n* Support single donations OR subscriptions, but not both.\n* Are based around a fundraising model (to attain a target amount) but don't support ongoing payments.\n* Are US only, but since we're in New Zealand we needed something that would work here.\n* Provide an iframe payment page but not all.\n* Have a free tier but others required payment from day 1.\n* Don't have a team plan such that members of the charity committee can log in and administer the portal.\n\n## Looking for an open source solution\n\nI kept thinking to myself that there must be an open source project out there already that could do all of this for free. Small charities and non-profits don't have the ability to pay for things up front, especially when it's not part of their core mission. After a while reading, reviewing, comparing, and planning, my non-negotiable for the platform became that \"We didn't have to pay more than necessary.\"\n\nThe only fee we wouldn't be able to get around was credit card processing. Added that we would only pay a percentage fee once we receive a donation rather than up front was also a good result.\n\nBeing a coder and being unimpressed with the status quo, I started coding. Within a month [The Donatinator](http://donatinator.org/) ([demo](https://donatinator.herokuapp.com/), [code](https://gitlab.com/donatinator/)) was born.\n\n## The Donatinator\n\nShortly after launch, The Donatinator can already accept one-off or recurring donations, add and edit simple Markdown pages, and allow multiple team members to log in for administration and basic reporting.\n\nMore features are planned, but the most important thing about the project is that it should be guided by a few founding principles. These are (far from perfect, but a good start):\n\n- The software should be open source so it is free for the end user, for now and always.\n- A basic installation should run within the free tier of various hosting providers.\n- The user should only have to pay for credit card processing fees (but if we can get around this one day we will!) 😃\n\n## Why open source?\n\nAllowing anyone and everyone to use, download, install, change, contribute, and enjoy The Donatinator is paramount to enabling every organisation anywhere to accept donations and allow them to continue the great work they are doing and the help they are providing.\n\n### Why GitLab?\n\nSince we ourselves are open source, choosing a code-hosting provider that is also open source aligns with our values nicely. \u003Cplug> GitLab is the natural home of projects like us and we're very grateful of their hospitality (as well as their 2,000 CI pipeline minutes per month!). \u003C/plug>\n\nFunnily enough this also brought home the idea that it's not actually just the technology that is the interesting part of the project. GitLab's handbook has a great page on values but a very small part of that is the idea of [boring solutions](https://handbook.gitlab.com/handbook/values/#efficiency) which we're also using to guide our technology decisions, keeping things simple and lite.\n\n### A word on pragmatism\n\nEven though we'd love everything to be open source, we know we can't have everything. With that we'd like to thank the following companies that we're currently using to make The Donatinator fulfill its aim. With free plans on Heroku, Google, Glitch, Zeit, MailGun, and others, we should be able to achieve these goals for charities who may only receive a few donations each month, which can make all the difference between helping people or closing down completely due to insufficient funds. Also thanks to Stripe for having a discounted fee for registered charities to maximize each and every donation.\n\nWhich leads me to a confession ...\n\n## A high high, and a low low\n\nStarting a new project is always exciting. Tap tap, code, test, commit, one late night after another. But then the bad news came ...\n\nThe small charity all of this work was initially done for decided to use an existing donor platform. I can understand why, but rather than dwelling on it, I decided to continue working on The Donatinator anyway. I'm still convinced there is a place for it in the world and a variety of people and organisations can benefit from it, if only they knew about it.\n\n## Asking for help, contributions, and donations\n\nWithout shame I am now asking you all for help. The Donatinator is a new project and there is still lots to do, however there are three main areas in which help would be awesome and greatly appreciated!\n\n### Please contribute!\n\nFirstly, contributions of [code](https://gitlab.com/donatinator/donatinator/) and [documentation](https://gitlab.com/donatinator/docs/) are welcome and very important. Participating in the [community](https://spectrum.chat/donatinator) also helps a project thrive and we'd love to chat to you about your needs and requirements.\n\n### Please donate!\n\nSecondly, I'm looking for [patrons and sponsorship](https://donate.donatinator.org/) (yes, it's self hosted) to be able to take the project forward faster. Sustainable open source is still a panacea but I believe it can happen. I don't believe that the charities and non-profits who use The Donatinator should have to pay for the use of it but that means we need to look elsewhere to help with sustainability.\n\n### Please spread the word!\n\nAnd finally but most importantly – users! If there are no users, then there is no project.\n\nIf you know a person, a non-profit, or a charity who could use [The Donatinator](http://donatinator.org/), please get in touch with them. Many are run by non-technical volunteers and they would love to have your help in setting up online donations. Get in touch with us too, for help or if you have any questions – we'd love to hear about your progress and your feedback would be invaluable!\n\n(You could also run The Donatinator yourself for your own open source project or for your own patron portal. Hint hint! 😃)\n\nThere is lots of functionality penciled in for future Donatinator releases but there is nothing like having real users provide ideas or ask for specific features. This is a terrific opportunity to help the helpers ... so come on, let's make it happen! We can do this 😃\n\nCover image by [Steve Johnson](https://unsplash.com/photos/0sPFjdcRhko?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/coins?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[675,268,1583],{"slug":2671,"featured":6,"template":679},"donatinator-open-source-donation-platform","content:en-us:blog:donatinator-open-source-donation-platform.yml","Donatinator Open Source Donation Platform","en-us/blog/donatinator-open-source-donation-platform.yml","en-us/blog/donatinator-open-source-donation-platform",{"_path":2677,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2678,"content":2683,"config":2688,"_id":2690,"_type":16,"title":2691,"_source":17,"_file":2692,"_stem":2693,"_extension":20},"/en-us/blog/semyon-pupkov-contributor-post",{"title":2679,"description":2680,"ogTitle":2679,"ogDescription":2680,"noIndex":6,"ogImage":2158,"ogUrl":2681,"ogSiteName":713,"ogType":714,"canonicalUrls":2681,"schema":2682},"GitLab Code Contributor: Semyon Pupkov","Long-time contributor Semyon Pupkov shares why he loves contributing to GitLab.","https://about.gitlab.com/blog/semyon-pupkov-contributor-post","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Code Contributor: Semyon Pupkov\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2019-01-30\",\n      }",{"title":2679,"description":2680,"authors":2684,"heroImage":2158,"date":2685,"body":2686,"category":14,"tags":2687},[1840],"2019-01-30","\n\nFor this month's contributor post, I'm excited to introduce [Semyon Pupkov](https://gitlab.com/artofhuman), who's been a consistent contributor to GitLab since 2016. The graph below shows Semyon's merge requests (MRs) since GitLab 8.13. Let's get to know him!\n\n![Semyon's MRs](https://about.gitlab.com/images/blogimages/semyon-blogpost/semyon-mrs.png){: .small.center}\n\n### Can you tell us where you live and a little bit about your area?\n\nI live in a city called [Yekaterinburg](https://www.google.com/maps/place/Yekaterinburg,+Sverdlovsk+Oblast,+Russia/@56.8138122,60.5145089,11z) in the Ural region of Russia. I love the nature here as it's not too hot in the summer and you will find good snow in the winter for snow boarding.\n\n### When did you first contribute to GitLab and why did you decide to contribute?\n\n[My first MR](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6762) about two years ago was a pretty simple one as I removed unnecessary code from tests. I used GitLab Community Edition for my private projects and since I like open source software, I decided to look at the GitLab code base. When I found some areas for improvement mainly in tests, I decided to create my first MR.\n\n### Which areas of GitLab product have you been contributing to over the past two years?\n\nMost of my contributions have been on the backend side where I tried to improve the existing code base.\n\n### Can you tell us what you do professionally?\n\nI am a backend Ruby/Python developer and work at a company called [SKB Kontur](https://kontur.ru/eng/about).\n\n### What do you enjoy doing when you're not working?\n\nI have been a father for about six months, and I try to give as much of my free time to my daughter. I also like playing games on PlayStation 4 and my favorite game right now is FIFA 19. And of course, I like to contribute to open source projects.\n\n![Semyon's family](https://about.gitlab.com/images/blogimages/semyon-blogpost/semyon-family.JPG){: .shadow.small.center}\n\n### What can we do better to help GitLab community contributors?\n\nSometimes in issues/MRs, I find links to Zendesk tickets or Slack discussions that are private, and this can be frustrating for someone not working at GitLab. Also, it would be great if GitLab had a better setup for local development with Docker and Docker Compose. I found the branch in the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit) repository with [support for Docker Compose](https://gitlab.com/gitlab-org/gitlab-development-kit/tree/docker-compose), but it probably needs some updating. I recently submitted an [MR to help address this](https://gitlab.com/gitlab-org/gitlab-development-kit/merge_requests/592).\n\n### What advice do you have for others who may be interested in contributing to GitLab?\n\nJust don't be afraid to get started. If you find places in the code that can be improved, you should make a contribution and in most cases your code will be welcomed and accepted.\n\nContributing to GitLab also allows you to work with a strong professional team. It's a good way to improve your skills while working on a great product.\n\n### Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[268,864,675,865],{"slug":2689,"featured":6,"template":679},"semyon-pupkov-contributor-post","content:en-us:blog:semyon-pupkov-contributor-post.yml","Semyon Pupkov Contributor Post","en-us/blog/semyon-pupkov-contributor-post.yml","en-us/blog/semyon-pupkov-contributor-post",{"_path":2695,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2696,"content":2702,"config":2709,"_id":2711,"_type":16,"title":2712,"_source":17,"_file":2713,"_stem":2714,"_extension":20},"/en-us/blog/sentry-integration-blog-post",{"title":2697,"description":2698,"ogTitle":2697,"ogDescription":2698,"noIndex":6,"ogImage":2699,"ogUrl":2700,"ogSiteName":713,"ogType":714,"canonicalUrls":2700,"schema":2701},"Sentry's GitLab integration streamlines error remediation","Your code has bugs, my code has bugs, everyone’s code has bugs (probably). Let’s fix that.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679964/Blog/Hero%20Images/sentry-io-blog.jpg","https://about.gitlab.com/blog/sentry-integration-blog-post","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Streamline and shorten error remediation with Sentry’s new GitLab integration\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Eva Sasson\"}],\n        \"datePublished\": \"2019-01-25\",\n      }",{"title":2703,"description":2698,"authors":2704,"heroImage":2699,"date":2706,"body":2707,"category":14,"tags":2708},"Streamline and shorten error remediation with Sentry’s new GitLab integration",[2705],"Eva Sasson","2019-01-25","\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/KUHk1uuXWhA?rel=0\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nSentry is open source error tracking that gives visibility across your entire stack and provides the details you need to fix bugs, ASAP. Because the only thing better than visibility and details is more visibility and details, Sentry improved their [GitLab integration](https://docs.sentry.io/workflow/integrations/global-integrations/gitlab/?utm_source=GitLab&utm_medium=blog&utm_campaign=GitLab_GTM) by adding [release](https://docs.sentry.io/workflow/releases/?platform=browser&utm_source=GitLab&utm_medium=blog&utm_campaign=GitLab_GTM) and [commit](https://docs.sentry.io/workflow/releases/?platform=browser&utm_source=GitLab&utm_medium=blog&utm_campaign=GitLab_GTM#link-repository) tracking as well as [suspect commits](https://docs.sentry.io/workflow/releases/?platform=browser&utm_source=GitLab&utm_medium=blog&utm_campaign=GitLab_GTM#after-linking-a-repository).\n\n### Streamline your workflow with issue management and creation\n\nWhen you receive an alert about an error, the last thing you want to do is to jump around 20 different tools trying to find out exactly what happened and where. Developers with both Sentry and GitLab in their application lifecycle benefit from issue management and issue creation to their GitLab accounts directly in the Sentry UI, alleviating some of the hassle of back-and-forth tool toggling.\n\n![GitLab account in Sentry](https://about.gitlab.com/images/blogimages/sentry/gitlab-sentry-integration.png){: .shadow.large.center}\n\nOf course, less tool jumping results in a more streamlined triaging process and shortened time to issue resolution – something that benefits the whole team.\n\n![Creating GitLab issue](https://about.gitlab.com/images/blogimages/sentry/create-gitlab-issue.png){: .shadow.medium.center}\n\nHave a GitLab issue that wasn’t created in Sentry? No problem. Existing issues are also easily linked.\n\n![Import GitLab issue](https://about.gitlab.com/images/blogimages/sentry/import-gitlab-issue.png){: .shadow.medium.center}\n\n### Find and fix bugs faster with release and commit tracking\n\nWhy stop at streamlining the triaging process, when we can also make issue resolution more efficient? Sentry’s GitLab integration now utilizes GitLab commits to find and fix bugs faster.\n\nWith the newly added release and commit tracking, an enhanced release overview page uncovers new and resolved issues, files changed, and authors. Developers can also resolve issues via commit messages or merge requests, see suggested assignees for issues, and receive detailed deploy emails.\n\nWant a big flashing arrow that points to an error’s root cause? Sentry’s suspect commits feature exposes the commit that likely introduced an error as well as the developer who wrote the broken code.\n\n![Suspect commits feature](https://about.gitlab.com/images/blogimages/sentry/suspect-commits-feature.png){: .shadow.medium.center}\n\nKeep in mind that this feature is available for Sentry users on “Teams” plans and above.\n{: .note}\n\nCheck out [Sentry’s GitLab integration documentation](https://docs.sentry.io/workflow/integrations/global-integrations/gitlab/?utm_source=GitLab&utm_medium=blog&utm_campaign=GitLab_GTM) to get started.\n\n### What’s next?\n\nAgain, why stop there, when we can do even more? GitLab is currently working to bring Sentry into the GitLab interface. Soon, GitLab and Sentry users will see their Sentry errors listed in their GitLab projects. Read the documentation on [the integration here](https://docs.gitlab.com/ee/operations/error_tracking.html).\n\n### About the guest author\n\nEva Sasson is a Product Marketer at [Sentry.io](https://sentry.io/welcome/), an open source error-tracking tool that gives developers the contextual information they need to resolve issues quickly, and integrates with the other development tools across the stack.\n",[110,864,1434,232,675,843,2046,1583,1921],{"slug":2710,"featured":6,"template":679},"sentry-integration-blog-post","content:en-us:blog:sentry-integration-blog-post.yml","Sentry Integration Blog Post","en-us/blog/sentry-integration-blog-post.yml","en-us/blog/sentry-integration-blog-post",{"_path":2716,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2717,"content":2723,"config":2729,"_id":2731,"_type":16,"title":2732,"_source":17,"_file":2733,"_stem":2734,"_extension":20},"/en-us/blog/wag-labs-blog-post",{"title":2718,"description":2719,"ogTitle":2718,"ogDescription":2719,"noIndex":6,"ogImage":2720,"ogUrl":2721,"ogSiteName":713,"ogType":714,"canonicalUrls":2721,"schema":2722},"How Wag! cut their release process from 40 minutes to just 6","The popular dog-walking app is rolling out new features faster and with more confidence as they adopt GitLab for more of their DevOps workflows.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678923/Blog/Hero%20Images/dog-walking.jpg","https://about.gitlab.com/blog/wag-labs-blog-post","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How Wag! cut their release process from 40 minutes to just 6\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Aricka Flowers\"}],\n        \"datePublished\": \"2019-01-16\",\n      }",{"title":2718,"description":2719,"authors":2724,"heroImage":2720,"date":2726,"body":2727,"category":14,"tags":2728},[2725],"Aricka Flowers","2019-01-16","\nDo you own a dog and work outside of the home? If you do, or even just know someone who does, you know that finding a trustworthy caretaker is of the utmost importance. With dog walkers in cities and towns across the U.S., the folks at [Wag!](https://wagwalking.com/about) have proven to be a source of reliable caretakers for countless fur parents. In three years, the company has powered more than one billion walks via its app for on-demand dog walking, sitting, and boarding, that boasts of millions of users.\n\nWag! recently signed on with GitLab to make the most of their engineering hours and bring their customers new features and updates at a faster clip.\n\n### From version control, to CI, to the full pipeline\n\nHaving previously used GitLab as their main source of truth for repositories, Wag! initially planned to return to the app solely for [continuous integration (CI)](/solutions/continuous-integration/). But after giving it a whirl, they quickly expanded their strategy to include the use of other features.\n\n\"We started our GitLab project about seven or eight months ago,\" explains [Dave Bullock](https://www.linkedin.com/in/eecue), director of engineering at Wag! \"The original idea was to just use it as our CI platform. But as we built that out, we started using it for more and more tasks, and ended up using it for our full [CI/CD pipeline](/topics/ci-cd/). That includes both our application, so the CI/CD that powers the API, along with our infrastructure. We use GitLab with Terraform to test, review, save, and deploy all of our infrastructure as well as the application on two separate pipelines. Every team uses it in their application, whether it's the Android application, the web application, the API, or our infrastructure; it's all being tested, built, and deployed through GitLab.\"\n\n### Streamlining to a single application\n\nPart of GitLab's appeal stemmed from the [ability to do everything in one place](/topics/single-application/). Wag! was searching for an [integrated solution](/solutions/continuous-integration/) that would streamline their development process, and they found it in GitLab.\n\n\"We were previously using a combination of Travis and other random technologies, and we just wanted something with a little bit better interface, a little more control, and something that we owned as far as the hosting and the management,\" says Bullock. \"We really wanted to move towards a single, full-service application.\"\n\n>\"We just wanted something with a better interface, a little more control, and something that we owned as far as the hosting and the management. We really wanted to move towards a single, full-service application.\"\n\nThe impact of that choice is also being felt on the infrastructure side. Wag!'s infrastructure engineers no longer have to manually stage and test their work. They are now following the same basic workflow that is used for their app, while integrating Terraform to manage their infrastructure.\n\n\"Basically, one of our DevOps team members will make a change, cut a pull request, and it'll be reviewed by the team. If it looks good, we'll say, 'Okay, cool. Merge it into master,'\" Bullock explains. \"If it's one of the modules, we'll tag that module, update the reference to it, and then the CI pipeline will kick off. It'll test the syntax, look for any security issues, and alert a Slack channel if there are any. It'll then stage a full version of the environment and test it. So, it stages all the pieces: the database, cache, and everything else, and tests it all to make sure that it works, just like we would be testing our production website.\n\n\"If that passes, then it allows you to see what your changes are going to do before you apply them,\" he continues. \"We call it Terraform plan. So, it runs Terraform plan on each piece of our infrastructure, and it'll tell us something like, 'Hey, we see 34 changes and 2 destructions and 1 creation in this environment. Click here to review.' Then the group will review it and if it looks good, we'll apply it in production. Having that as a full pipeline is really great.\"\n\n>“Now it's so easy to deploy something and roll it back if there's an issue. It's taken the stress and the fear out of deploying into production.” – Dave Bullock, Director of Engineering\n\n### Easy learning curve\n\nSome of the Wag! engineers had working experience with GitLab, while others had not. Nonetheless, Bullock found the onboarding of his teams to be a fairly easy process due to the intuitive nature of the interface.\n\n\"I think once you kind of understand how CI works, it's basically about following things step by step,\" he says. \"Pipelines were a new concept to a lot of the team, but once you see it happening visually, it's really easy to understand what's going on, expand and add to it. It's a really useful interface. Seeing all those green dots or red dots makes it really clear what's going on.\"\n\n### Built-in security, shaving down test times and faster releases\n\nAs part of their ramp up in GitLab, the dog-walking service recently furled [automated security scanning and license management](/solutions/security-compliance/) into their workflow, with Bullock noting how \"great\" it is to have those features baked into the pipeline so that immediate action can be taken when needed.\n\nWag! currently issues three releases a day, with plans to bump that number up to eight or more. Since adopting GitLab, they have seen a massive improvement in the amount of time spent on the release process. **What previously took 40 minutes to an hour to accomplish, now takes just six minutes.**\n\n\"Traditionally, the release process was slow, fragile, and limited to only a few key release engineers who had access to 10 different systems to monitor, make changes, and log into to make updates and pull in the latest code. It was not optimal. Now it's literally a single pane of glass. A lot of it just happens automatically when you merge `develop` into `master` and tag it.\"\n\nThe release process time should improve even more once Wag! engineers switch from manually pushing parts of the release through to automating the process.\n\n\"Right now, we're still clicking through the interface and saying, 'Okay, do this, now let's monitor,'\" says Bullock. \"But I think as we become more comfortable with it, we'll go to fully automated deployments. Literally, just let it go and deploy. If we see an uptick in errors, we'll let it roll back on its own. But as it is now, it's so easy to deploy something and roll it back ourselves if there's an issue. It's taken the stress and the fear out of deploying into production.\"\n\n### Adopting DevOps\n\nWag!'s engineering team has big plans for 2019. They are currently in the process of moving their repositories from GitHub to GitLab and are planning to switch from Amazon ECS to [Kubernetes](/solutions/kubernetes/). This is all part of their roadmap to implementing DevOps.\n\n\"I think we're going to start working on the project in Q1 and it will be really awesome to have all the bells and functionality,\" Bullock says. \"We're excited about Auto DevOps and a lot of new things GitLab has coming down the pipeline. We're going to push pretty hard on that this year.\n\n\"I'm a big fan of DevOps in general, so I think the closer that you can bring the development engineers to the ops side, the better things work,\" he adds. \"I would love for every software engineer or backend engineer to take ownership of the environment that their code runs in, or at least be able to experiment with it and kind of instantly just spin up a full working environment that is the same as our production environment, which we do now, but not with Kubernetes. I think removing that friction is great.\"\n\n### Growing with GitLab\n\nGitLab's releases are a treat the folks at Wag! look forward to checking out each month. The rollout of new features, which are partly determined by user feedback, tend to correlate with the engineering needs of the growing dog-walking and boarding service.\n\n\"I think it's exciting that as we're growing and adding interesting pieces to our infrastructure and application, we're seeing GitLab grow with your monthly release cycles,\" says Bullock. \"Every month there's some new stuff that we're like, 'Oh cool, we could use that, that's perfect.' It's nice to have GitLab as a partner that's growing with us, and it's exciting to see the parallels of new features that you're launching and how it's solving our problems and optimizing things. There's all kinds of cool stuff, and every time we start using a new piece of GitLab, I feel like, 'Okay, that's great, we're really getting our money’s worth.'\"\n\nPhoto by [Andrii Podilnyk](https://unsplash.com/photos/dWSl8REfpoQ?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/dog-walk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[1475,1000,864,1434,843,2046,1583,1921],{"slug":2730,"featured":6,"template":679},"wag-labs-blog-post","content:en-us:blog:wag-labs-blog-post.yml","Wag Labs Blog Post","en-us/blog/wag-labs-blog-post.yml","en-us/blog/wag-labs-blog-post",{"_path":2736,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2737,"content":2742,"config":2747,"_id":2749,"_type":16,"title":2750,"_source":17,"_file":2751,"_stem":2752,"_extension":20},"/en-us/blog/q1-hackathon-announcement",{"title":2738,"description":2739,"ogTitle":2738,"ogDescription":2739,"noIndex":6,"ogImage":1737,"ogUrl":2740,"ogSiteName":713,"ogType":714,"canonicalUrls":2740,"schema":2741},"Get ready for the Q1'2019 GitLab Hackathon","The first Hackathon in 2019 for the GitLab community will take place on February 12-13.","https://about.gitlab.com/blog/q1-hackathon-announcement","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Get ready for the Q1'2019 GitLab Hackathon\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2019-01-14\",\n      }",{"title":2738,"description":2739,"authors":2743,"heroImage":1737,"date":2744,"body":2745,"category":14,"tags":2746},[1840],"2019-01-14","\n\nFirst of all, I want to wish a Happy New Year to everyone in the GitLab community! I'm certainly looking forward to continued collaboration with everyone in 2019. Following successful [Hackathons in 2018](/community/hackathon/past-events/), I'm excited to announce that the first Hackathon this year will take place on Feb. 12-13.\n\n## What's the deal?\n\nThis is a virtual event where community members get together to work on merge requests (MRs) and also to welcome and help new contributors. We will be adding more details on [the Hackathon landing page](/community/hackathon/), as we get closer to the event, including prizes for everyone who has MRs merged within 10 days of the conclusion of the Hackathon.\n\n## What else is taking place?\n\nWe are again planning tutorial sessions where community experts will lead presentations plus Q&A sessions on a variety of topics. As speakers get confirmed, you will see tutorial sessions added on [the Hackathon landing page](/community/hackathon/). All the tutorial sessions will be recorded and added to the [GitLab Hackathon playlist](https://www.youtube.com/playlist?list=PLFGfElNsQthapq-CyXBTVnT2yKqg1JrNh). If you missed tutorials from past Hackathons, I encourage you to check out videos from the playlist.\n\n![Hackthon playlist](https://about.gitlab.com/images/blogimages/hackathon-playlist.png){: .shadow.medium.center}\n*\u003Csmall>Tutorial videos on the Hackathon playlist\u003C/small>*\n\nFor the upcoming Hackathon, we will also be highlighting issues from different [GitLab product categories](/handbook/product/categories/) that we want to encourage community members to work on. There will be additional prizes for community members who work on these issues and have MRs merged.\n\n## Where can I find help during the Hackathon?\n\nFor communications during the Hackathon, we will again use the [GitLab Community room in Gitter](https://gitter.im/gitlabhq/community). This is a channel designed to have community-related discussions and for community members to help each other as people have questions when contributing to GitLab. This is open to everyone, so please [join the room](https://gitter.im/gitlabhq/community) if you are not part of it already.\n\n## How do I get started with contributing?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\nCover image: [\"GitLab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel)\n{: .note}\n",[268,864,675,278],{"slug":2748,"featured":6,"template":679},"q1-hackathon-announcement","content:en-us:blog:q1-hackathon-announcement.yml","Q1 Hackathon Announcement","en-us/blog/q1-hackathon-announcement.yml","en-us/blog/q1-hackathon-announcement",{"_path":2754,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2755,"content":2760,"config":2765,"_id":2767,"_type":16,"title":2768,"_source":17,"_file":2769,"_stem":2770,"_extension":20},"/en-us/blog/translating-gitlab",{"title":2756,"description":2757,"ogTitle":2756,"ogDescription":2757,"noIndex":6,"ogImage":1737,"ogUrl":2758,"ogSiteName":713,"ogType":714,"canonicalUrls":2758,"schema":2759},"Help us speak your language!","GitLab is available in many languages, but there's always more translation work to be done. Here's how you can contribute to translating GitLab.","https://about.gitlab.com/blog/translating-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Help us speak your language!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2019-01-08\",\n      }",{"title":2756,"description":2757,"authors":2761,"heroImage":1737,"date":2762,"body":2763,"category":14,"tags":2764},[1840],"2019-01-08","\nOne of the lesser-known features of GitLab is that it has been translated into many languages by community members. If you have only seen GitLab in (American) English, you can go to your [Profile page](https://gitlab.com/profile) and change your **Preferred language** to see it in another language.\n\n![Selecting preferred language](https://about.gitlab.com/images/blogimages/translation-blog/preferred_language_chinese.png){: .shadow.small.center}\n\n![GitLab in Chinese](https://about.gitlab.com/images/blogimages/translation-blog/gitlab_in_chinese.png){: .shadow.small.center}\n\nWe are proud of the work done by so many dedicated community members to help translate GitLab, but this is ongoing work, and we also have many languages that are just getting started with translation. That's where you come in!\n\n## Why translate GitLab?\n\nSome may say that GitLab is used by technical people who are already used to using a lot of different software in English, and translation is not really necessary. That may be true, but having the software available in local languages that people are more comfortable with lowers the barrier to entry not only for users, but for contributors too. Maybe it's because GitLab is an [all-remote company](/blog/the-case-for-all-remote-companies/) with [employees in nearly 50 countries](/company/team/), but GitLab team-members appreciate the benefits of localized software in local communities.\n\n## How is GitLab translated and how do I start contributing?\n\nThe translation is managed at [translate.gitlab.com](https://translate.gitlab.com/) using [Crowdin](https://crowdin.com/). First, a phrase (e.g. one that appears in the GitLab user interface or in error messages) needs to be internationalized before it can be translated. The internationalized phrases are then made available for translations on [translate.gitlab.com](https://translate.gitlab.com/). As each phrase is translated, it is added to the translation file, and will then be merged into future releases. You can find more details on how GitLab is translated in the [Translate GitLab documentation](https://docs.gitlab.com/ee/development/i18n/).\n\nAs you can see in the [translation activity stream](https://translate.gitlab.com/project/gitlab-ee/activity_stream), the majority of translations are contributed by community members. You're probably already familar with GitLab's motto, \"Everyone can contribute,\" and contributing translation is even easier than contributing code.  All you need is an account on [CrowdIn](https://crowdin.com/) plus a browser, and you are ready to translate GitLab to a language of your choice. So if you're looking for ways to contribute and know other languages, translation is a great place to get started.\n\nDuring the [GitLab Hackathon](/community/hackathon/) in September, one of our [Core Team](/community/core-team/) members [Hannes Rosenögger](https://gitlab.com/haynes) presented a session on translation where he walked through how community members can contribute. You can watch the recording:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/LJ9oSSx0qyY\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Where do we need help?\n\nAs you can see from the screenshot below, GitLab is almost fully translated into several languages, such as Chinese (both Simplifed and Traditional), French, German, Filipino, Brazilian Portuguese, Ukrainian, etc. However, many languages are in early stages, with a lot of translation left to be done and may also need [proofreaders](https://docs.gitlab.com/ee/development/i18n/proofreader.html) to help review and approve translations. You can find steps to becoming a proofreader also outlined in [the proofreader documentation](https://docs.gitlab.com/ee/development/i18n/proofreader.html#become-a-proofreader).\n\n![GitLab translation status](https://about.gitlab.com/images/blogimages/translation-blog/gitlab_translation_status.png){: .shadow.medium.center}\n\nEven if a language is fully translated today, new phrases are added all the time, so we welcome new contributors across all languages. If you have any questions as you get started on [translate.gitlab.com](https://translate.gitlab.com/), you can post questions on the [Crowdin discussions forum](https://translate.gitlab.com/project/gitlab-ee/discussions), and you are always welcome to reach me at rpaik@gitlab.com.\n\n[\"GitLab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel) on Unsplash\n{: .note}\n",[268,864,675,865],{"slug":2766,"featured":6,"template":679},"translating-gitlab","content:en-us:blog:translating-gitlab.yml","Translating Gitlab","en-us/blog/translating-gitlab.yml","en-us/blog/translating-gitlab",{"_path":2772,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2773,"content":2779,"config":2785,"_id":2787,"_type":16,"title":2788,"_source":17,"_file":2789,"_stem":2790,"_extension":20},"/en-us/blog/a-visual-prototype-of-drupal-dot-orgs-integration-with-gitlab",{"title":2774,"description":2775,"ogTitle":2774,"ogDescription":2775,"noIndex":6,"ogImage":2776,"ogUrl":2777,"ogSiteName":713,"ogType":714,"canonicalUrls":2777,"schema":2778},"A visual prototype of Drupal.org's GitLab integration","Guest author Tim Lehnen shares a visual preview of free and open source platform Drupal's upcoming integration with GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671386/Blog/Hero%20Images/drupal-cover.png","https://about.gitlab.com/blog/a-visual-prototype-of-drupal-dot-orgs-integration-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A visual prototype of Drupal.org's GitLab integration\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Lehnen\"}],\n        \"datePublished\": \"2018-12-19\",\n      }",{"title":2774,"description":2775,"authors":2780,"heroImage":2776,"date":2782,"body":2783,"category":14,"tags":2784},[2781],"Tim Lehnen","2018-12-19","\nAt [Drupal Europe](https://www.drupaleurope.org) in September, we were very pleased that project founder [Dries Buytaert](https://dri.es) highlighted a visual prototype of our upcoming integration with GitLab in his keynote. This follows our announcement that we'd be [moving to GitLab](/blog/drupal-moves-to-gitlab/) back in August.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/q06taaJPGDw?rel=0&showinfo=0\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nThis video outlines the migration phases that we discussed [in the announcement of our partnership with GitLab](https://www.drupal.org/drupalorg/blog/developer-tools-initiative-part-5-gitlab-partnership). Our migration window for Phase 1 is targeted for the first weeks of January, and we hope Phase 2 to be completed shortly in the beginning of 2019.\n\n## So what has it taken to get this integration working between September and now?\n\nPrimarily, lots of collaboration with the GitLab team. We've worked with their excellent engineering staff to resolve a number of issues that affect our integration, including:\n\n- [git merge-base web API](https://gitlab.com/gitlab-org/gitlab-ce/issues/49850)\n- [Add ability to confirm a user’s email address via \"Add email for user\" API](https://gitlab.com/gitlab-org/gitlab-ce/issues/50876)\n- [Allow configuration of the display URL for clone instructions](https://gitlab.com/gitlab-org/gitlab-ce/issues/49698)\n- [Ability to hide User's Email Address from GitLab UI](https://gitlab.com/gitlab-org/gitlab-ce/issues/24221)\n- [Allow ability for developer role to delete tags](https://gitlab.com/gitlab-org/gitlab-ce/issues/52954)\n- [Set GL_REPOSITORY in update hooks for API-initiated requests](https://gitlab.com/gitlab-org/gitaly/issues/1402)\n- [Deduplication of Git objects, reducing disk space of repository forks](https://gitlab.com/gitlab-org/gitlab-ce/issues/23029)\n\nOn the Drupal.org side:\n\n - We've built a [`versioncontrol_gitlab` module](https://www.drupal.org/project/versioncontrol_gitlab), which extends our use of the [`versioncontrol_git` module](https://www.drupal.org/project/versioncontrol_git) to orchestrate our integration.\n - We've also been cleaning up our data, to ensure there are no namespace conflicts between existing Drupal projects and users, and the reserved terms used by GitLab.\n\nWe're now in the midst of serious migration testing: testing and re-testing the process in our staging environment, putting load testing in place to stress test our integration, and doing user-validation testing to ensure that the workflows affected by this integration are working as expected.\n\nAll in all, we're thrilled with the progress, and very thankful for GitLab's close collaboration. We're excited to be moving the Drupal project to its next generation tooling soon. Once Phase 1 of our migration is complete, it'll be time for Phase 2 and our community will start seeing some tremendous improvements in efficiency and collaboration.\n\n## How can people get involved in Drupal?\n\nThe Drupal community has a comprehensive [Getting Involved Guide](https://www.drupal.org/getting-involved-guide) that can help individuals find their place in the Drupal community. There are also meetups and conferences around the world that are a great way to start your Drupal journey. In particular, [DrupalCon will be coming to Seattle from Apr. 8-12, 2019](https://events.drupal.org/seattle2019).\n\nThe Drupal project's motto has always been \"Come for the code, stay for the community\" and 17 years later, that's a sentiment we still believe in.\n\n### About the guest author\n\nTim Lehnen is the Executive Director at the [Drupal Association](https://www.drupal.org/association).\n\n_This guest post was originally published [on the Drupal blog](https://www.drupal.org/drupalorg/blog/a-visual-prototype-of-drupalorgs-integration-with-gitlab)._\n",[675,268,232],{"slug":2786,"featured":6,"template":679},"a-visual-prototype-of-drupal-dot-orgs-integration-with-gitlab","content:en-us:blog:a-visual-prototype-of-drupal-dot-orgs-integration-with-gitlab.yml","A Visual Prototype Of Drupal Dot Orgs Integration With Gitlab","en-us/blog/a-visual-prototype-of-drupal-dot-orgs-integration-with-gitlab.yml","en-us/blog/a-visual-prototype-of-drupal-dot-orgs-integration-with-gitlab",{"_path":2792,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2793,"content":2798,"config":2803,"_id":2805,"_type":16,"title":2806,"_source":17,"_file":2807,"_stem":2808,"_extension":20},"/en-us/blog/contributor-post-siemens",{"title":2794,"description":2795,"ogTitle":2794,"ogDescription":2795,"noIndex":6,"ogImage":2158,"ogUrl":2796,"ogSiteName":713,"ogType":714,"canonicalUrls":2796,"schema":2797},"GitLab Code Contributor: Alexis Reigel","Alexis Reigel shares his experience as a GitLab contributor on behalf of Siemens.","https://about.gitlab.com/blog/contributor-post-siemens","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Code Contributor: Alexis Reigel\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2018-12-18\",\n      }",{"title":2794,"description":2795,"authors":2799,"heroImage":2158,"date":2800,"body":2801,"category":14,"tags":2802},[1840],"2018-12-18","\nFor this month's blog post, we're featuring [Alexis Reigel](https://gitlab.com/koffeinfrei). Alexis was also an [MVP for GitLab 9.5 and 10.8](/community/mvp/).\n\n![Alexis Reigel](https://about.gitlab.com/images/blogimages/Alexis_Reigel.jpeg){: .shadow.small.center}\n\n### How did you get involved with contributing to GitLab?\n\nMy Siemens colleagues have been using GitLab since 2013 with [GitLab 5.2](/releases/2013/05/22/gitlab-5-dot-2-released/). The *[upstream first](https://www.redhat.com/blog/verticalindustries/why-upstream-contributions-matter-when-developing-open-source-nfv-solutions/)* principle is important at Siemens, as they don't want to maintain local patches/forks of software. I was hired to contribute features to GitLab that are needed at Siemens, and this give-and-take process between contributors and users is what is great about open source software. My first contribution was the ability to add a [custom brand header logo in emails](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9049), which I created on Feb. 7, 2017 and was merged on Feb. 22, 2017.\n\n### What was your experience with the first merged MR?\n\nThere was no controversy with my first MR, and therefore not much debate before it was merged. The review was very quick and the relevant people chimed in right from the start. For some of the later, more complicated merge requests, it was not always this straightforward. Depending on how complicated the MR is and how many people from GitLab participate, the process may take longer and generate a lot of discussions.\n\n### What advice do you have for others who may be interested in contributing to GitLab? In particular, any insights you can share with current GitLab customers who may be thinking about making code contributions?\n\nFirst, I recommend reviewing existing MRs and issues before submitting an MR. In many cases, there are already discussions and potential solutions for a certain feature or bug fix. It's also helpful to find out [who from GitLab](/company/team/) is relevant or responsible for a certain area so you can ping the right person from the start.\n\nThe initial contribution should always be a minimal solution or what GitLab calls a [\"Minimum Viable Change (MVC)\"](/handbook/product/product-principles/#the-minimal-viable-change-mvc), because the solution will often change with feedback. The initial contribution should be considered a starting point for collaboration between the contributor and GitLab team-members.\n\nIn some cases, a contributor may need to be patient with their MR, as depending on the topic and complexity it may take some time to move things forward. The people from GitLab are always very kind and friendly so the discussions are respectful.\n\n### Do you have other colleagues at Siemens who also contribute to GitLab? How do you go about planning and working on your contributions?\n\nYes, there are several colleagues who are active within the GitLab community and you will see [Siemens mentioned in MRs](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/?scope=all&utf8=%E2%9C%93&state=merged&search=siemens).\n\nMy Siemens colleagues collect issues and feature requests internally and prioritize them based on how important and urgent they are. After discussing feature requests with coworkers to make sure we have a common understanding of the intended functionality, I start to work on the issues according to their priority. I have a lot of freedom and trust from Siemens on what the solution I contribute should look like.\n\n### What do you like to do when you're not working?\n\nI work on several other free and open source projects such as [Metaflop](https://www.metaflop.com/), [Mykonote](https://github.com/panter/mykonote/blob/master/README.md), and others in my spare time. Apart from that, I like spending time with my family and friends. If there's any time left, I make and listen to music or watch a movie or two.\n\n### Anything else you want to share with the community?\n\nGitLab is a great product and is one of the friendliest and healthiest open source communities. Contributing to such a large project may seem daunting at first, but will pay off in the end. Your contribution will be appreciated by GitLab team-members as well as everyone who uses the product.\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[268,864,675,865],{"slug":2804,"featured":6,"template":679},"contributor-post-siemens","content:en-us:blog:contributor-post-siemens.yml","Contributor Post Siemens","en-us/blog/contributor-post-siemens.yml","en-us/blog/contributor-post-siemens",{"_path":2810,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2811,"content":2816,"config":2821,"_id":2823,"_type":16,"title":2824,"_source":17,"_file":2825,"_stem":2826,"_extension":20},"/en-us/blog/contributor-post-hannes",{"title":2812,"description":2813,"ogTitle":2812,"ogDescription":2813,"noIndex":6,"ogImage":2158,"ogUrl":2814,"ogSiteName":713,"ogType":714,"canonicalUrls":2814,"schema":2815},"GitLab Code Contributor: Hannes Rosenögger","Core team member Hannes Rosenögger shares his experience contributing to GitLab since 2014.","https://about.gitlab.com/blog/contributor-post-hannes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Code Contributor: Hannes Rosenögger\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2018-11-20\",\n      }",{"title":2812,"description":2813,"authors":2817,"heroImage":2158,"date":2818,"body":2819,"category":14,"tags":2820},[1840],"2018-11-20","\nFor this month's blog post, we're featuring another [Core Team](/community/core-team/) member [Hannes Rosenögger](https://gitlab.com/haynes).\n\n### When did you first contribute to GitLab?\n\nMy first [MR to close multiple issues with one commit](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/263) was back in December 2014. So that's almost four years ago!\n\n### Why and how did you decide to contribute to GitLab?\n\n I used the Community Edition privately and noticed that mentioning multiple issues in an MR only closed the first issue. Since GitLab was open source and the fix was easy, I decided to fix it myself. GitLab's open policy about everything within the company was also a huge factor.\n\n### Which area(s) of the GitLab product have you been contributing to?\n\nI guess it's been pretty random for me. Most of my contributions have been on the backend side and documentation fixes, but if I see something that I can easily fix or I need a feature for my work, I try to make a contribution. I also provide support on the #gitlab IRC channel on freenode. My IRC handle is `haynes`.\n\n### Can you tell us what you do professionally?\n\nI am a Java software developer for a public sector organization in Germany.\n\n### What do you like to do when you're not working?\n\nWhen I'm not working, I'm probably doing something for my local scout group. I enjoy working with the kids and teaching. I also like to fix things from coffee machines to cars. Basically anything that I can fix with a bit of work.\n\n\u003C!-- carousel -->\n\n\u003Cdiv id=\"carousel-example-generic-5\" class=\"carousel slide medium center\" data-ride=\"carousel\" data-interval=\"10000\">\n  \u003C!-- Indicators -->\n  \u003Col class=\"carousel-indicators\">\n    \u003Cli data-target=\"#carousel-example-generic-5\" data-slide-to=\"0\" class=\"active\">\u003C/li>\n    \u003Cli data-target=\"#carousel-example-generic-5\" data-slide-to=\"1\">\u003C/li>\n    \u003Cli data-target=\"#carousel-example-generic-5\" data-slide-to=\"2\">\u003C/li>\n  \u003C/ol>\n\n  \u003C!-- Wrapper for slides -->\n  \u003Cdiv class=\"carousel-inner\" role=\"listbox\">\n    \u003Cdiv class=\"item active\">\n          \u003Cimg src=\"/images/blogimages/Hannes-blogpost/workbench.jpg\" alt=\"Hannes on workbench\">\n    \u003C/div>\n    \u003Cdiv class=\"item\">\n      \u003Cimg src=\"/images/blogimages/Hannes-blogpost/dishwasher.jpg\" alt=\"Hannes working on his dishwasher\">\n    \u003C/div>\n    \u003Cdiv class=\"item\">\n      \u003Cimg src=\"/images/blogimages/Hannes-blogpost/washing_machine.jpg\" alt=\"Washing machine repair\">\n    \u003C/div>\n\n  \u003C/div>\n\n  \u003C!-- Controls -->\n  \u003Ca class=\"left carousel-control\" href=\"#carousel-example-generic-5\" role=\"button\" data-slide=\"prev\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-left\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M.44 10.13l8.345 8.345 2.007-2.007-6.814-6.814 6.814-6.815L8.785.832.44 9.177a.652.652 0 0 0-.202.477c0 .183.067.343.202.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Previous\u003C/span>\n  \u003C/a>\n  \u003Ca class=\"right carousel-control\" href=\"#carousel-example-generic-5\" role=\"button\" data-slide=\"next\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-right\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M10.59 10.13l-8.344 8.345L.24 16.468l6.814-6.814L.24 2.839 2.246.832l8.345 8.345a.652.652 0 0 1 .201.477.652.652 0 0 1-.201.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Next\u003C/span>\n  \u003C/a>\n\u003C/div>\n\n### What advice do you have for others who may be interested in contributing to GitLab?\n\nContributing to GitLab is easier than it looks at a first glance and you can contribute to the community in many different ways. For example, if you want to help out translating the GitLab user interface to your native language on [CrowdIn](https://translate.gitlab.com/), this does not require programming skills or any special setup on your laptop. Also when you want to contribute code, reviewers are normally quite fast in getting back to you and are more than happy to help if you have any questions.\n\nIf you are unsure how to get started or you need help, anyone should feel free to ping me on Twitter ([@hrosenoegger](https://twitter.com/hrosenoegger)) or in the #gitlab IRC channel on [freenode](http://freenode.net/).\n\n### Anything else you want to share with the community?\n\nI love the fact that GitLab actually listens to the community. Even after they make a decision to add a new, paid feature, when community members believe it makes more sense to have the feature in [GitLab Core](/pricing/#self-managed) or the free tier of [GitLab.com](/pricing/), they will actually port it back. The [Squash and Merge feature](/releases/2018/06/22/gitlab-11-0-released/#squash-and-merge-in-gitlab-core-and-gitlabcom-free) is a good example of that.\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[268,864,675,865],{"slug":2822,"featured":6,"template":679},"contributor-post-hannes","content:en-us:blog:contributor-post-hannes.yml","Contributor Post Hannes","en-us/blog/contributor-post-hannes.yml","en-us/blog/contributor-post-hannes",{"_path":2828,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2829,"content":2835,"config":2840,"_id":2842,"_type":16,"title":2843,"_source":17,"_file":2844,"_stem":2845,"_extension":20},"/en-us/blog/hiring-based-on-open-source-contributions-could-be-harmful",{"title":2830,"description":2831,"ogTitle":2830,"ogDescription":2831,"noIndex":6,"ogImage":2832,"ogUrl":2833,"ogSiteName":713,"ogType":714,"canonicalUrls":2833,"schema":2834},"We all love open source, but hiring based on contributions could be harmful","An industry expert from Indeed says it's a bad idea to make hiring decisions based on GitHub activity.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678750/Blog/Hero%20Images/man-coding.jpg","https://about.gitlab.com/blog/hiring-based-on-open-source-contributions-could-be-harmful","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"We all love open source, but hiring based on contributions could be harmful\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Aricka Flowers\"}],\n        \"datePublished\": \"2018-11-16\",\n      }",{"title":2830,"description":2831,"authors":2836,"heroImage":2832,"date":2837,"body":2838,"category":14,"tags":2839},[2725],"2018-11-16","\nThere’s been a lot of chatter about using open source contributions as a metric in the hiring process. After some intense discussions on social media, Ashe Dryden, a programmer and diversity advocate and consultant, [wrote about the ethical problems with hiring based on GitHub activity and open source contributions](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community) back in 2013, and the topic resurfaces every few months.\n\nMost recently, [@ReBeccaOrg](https://twitter.com/ReBeccaOrg/status/954081973814755328) and [@Joemccann](https://twitter.com/joemccann/status/1004798006485573632) kicked up more discussion with their respective tweets, inspiring the head of open source at job site [Indeed.com](https://www.indeed.com/about), Duane O'Brien, to take it to the next level with a conference talk.\n\n\"This talk was inspired by a discussion from earlier in the year about a startup that tried to create a ranking algorithm to identify job candidates based solely on their GitHub activity,\" he explains. \"In fact, between the time that I started putting together the talk and the first time that I gave it, the topic had blown up on Twitter again because someone else had started talking about how they don't even look at resumes anymore, they just look at GitHub profiles. People were pointing out why this is problematic.\"\n\n### 1. It creates an uneven playing field\n\nWhile hiring based on GitHub profiles is not a universal practice, Duane says it has been going on for a while. He says the practice can inadvertently create bias.\n\n\"A problem with biasing your hiring process toward people who have a history of open source work is that it is likely you're expecting that they've done it in their free time\u003Csup>(1)(2)\u003C/sup>. And the demographic that historically has the most available free time [trends towards male](https://www.unece.org/info/media/news/statistics/2016/how-much-free-time-do-we-have/doc.html),\" he says. \"Because of this, there can be an unexpected effect of filtering out people who are primary caregivers or young parents, or people who are making a career transition and have to work two jobs, those who bear disproportionate household responsibilities, and so on.\"\n\n### 2. It plays up a sometimes unattainable standard\n\nAnother concern for critics of open source contribution-focused hiring is that it can perpetuate this mantra that you have to be coding nonstop to be considered a real developer.\n\n\"There's [this perception](https://www.codementor.io/@codementorteam/how-to-get-your-first-developer-job-even-if-you-don-t-have-a-cs-degree-8b60y8ch2), especially in Silicon Valley, that [if you are not eating, breathing, and sleeping code](https://www.businessinsider.com/why-one-programmer-hates-the-popular-eat-sleep-code-repeat-t-shirt-2016-5) at work and during all your spare time and don't have a bunch of [personal side projects](https://insights.dice.com/2013/11/15/improve-chance-landing-job-personal-project/), that you don't take it seriously or are [not as desirable of a candidate](https://techbeacon.com/what-do-job-seeking-developers-need-their-github) as someone who does spend all their time on coding,\" Duane says. \"I think that places an unfair claim on people's free time, and what they should be doing with it. Especially those with families. Most people expect flexibility and wouldn’t want to work for an employer who has unrealistic expectations.\"\n\n### Open source's place in hiring\n\nOpen source participation does have a role in hiring, but it should not be the be-all and end-all for a candidate. If you’re looking for someone who has experience working within a particular open source community or project, then it makes sense to look at the open source contributions of job candidates, O’Brien said. But in most cases, there are other ways to evaluate applicants and also keep the playing field even.\n\n\"If you're looking to hire for an engineering position and you've got two engineers, one of whom has a robust history of working in open source, and one of them who doesn't have any open source footprint at all, rather than automatically interpreting one candidate as less desirable than the other, I recommend finding another way to get a look at their skills,\" Duane advised. \"You can do that by asking them for code samples, or having them do panel interviews or take-home assessment-based assignments. Some companies are also offering contract work to potential candidates as a way to try them out on the job. Honeycomb.io has done some of this.\u003Csup>(3)\u003C/sup> This ‘hiring in production’ mentality seems to be emerging as a practice.\"\n\n### Suggestions for job hunters\n\nJob seekers who have little to no open source experience should be prepared for questions about their lack of participation. Be straightforward about your constraints, be it a lack of time, interest or opportunity, and offer code samples that allow employers to view your skills in action. Duane says it is also important to interview your potential employer to make sure their expectations are in line with your wants and needs.\n\nFor those looking to get some open source experience, there are a number of ways to get involved, including, of course, [GitLab](/community/contribute/). Duane pointed to paid opportunities like [Outreachy](https://www.outreachy.org/), which offers internships to people in underrepresented groups to support them in making their first contributions into open source, as well as bug bounties.\n\nDuane recently presented his talk at All Things Open and the Seattle GNU/Linux conference. He may present the talk again at a few more events in the near future.\n\n\"Since it's a topic that seems to come up in our social sphere every few months or so, I want to encourage us to go back and look at Ashe's blog post, and the other people who've already been talking about it,\" he said. \"There are many different ways to evaluate candidates besides just looking at their GitHub data, and it’s important that look at the whole picture when we evaluate candidates.\"\n\nWhat role do you think open source contributions should play in the hiring process? Sound off on Twitter and let us know [@GitLab](https://twitter.com/gitlab) or comment below.\n\n**Footnotes**\n\n[1](http://opensourcesurvey.org/2017/#insights),\n[2](https://assets.digitalocean.com/currents-report/DigitalOcean-Currents-Q4-2017.pdf),\n3 You can see some discussion of this in this [Twitter thread](https://twitter.com/DuaneOBrien/status/963499537154310145), which refers to the [first Sentry Scouts meetup](https://sentry.io/_/events/2018-01-17-sentry-scouts-1/).\n{: .note}\n",[2023,675,268],{"slug":2841,"featured":6,"template":679},"hiring-based-on-open-source-contributions-could-be-harmful","content:en-us:blog:hiring-based-on-open-source-contributions-could-be-harmful.yml","Hiring Based On Open Source Contributions Could Be Harmful","en-us/blog/hiring-based-on-open-source-contributions-could-be-harmful.yml","en-us/blog/hiring-based-on-open-source-contributions-could-be-harmful",{"_path":2847,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2848,"content":2853,"config":2858,"_id":2860,"_type":16,"title":2861,"_source":17,"_file":2862,"_stem":2863,"_extension":20},"/en-us/blog/q4-hackathon-announcement",{"title":2849,"description":2850,"ogTitle":2849,"ogDescription":2850,"noIndex":6,"ogImage":1737,"ogUrl":2851,"ogSiteName":713,"ogType":714,"canonicalUrls":2851,"schema":2852},"Get ready for the Q4'2018 GitLab Hackathon","The Q4 Hackathon for the GitLab community will take place on November 14-15.","https://about.gitlab.com/blog/q4-hackathon-announcement","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Get ready for the Q4'2018 GitLab Hackathon\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2018-10-23\",\n      }",{"title":2849,"description":2850,"authors":2854,"heroImage":1737,"date":2855,"body":2856,"category":14,"tags":2857},[1840],"2018-10-23","\n\nFollowing the success of [our inaugural event](/blog/hackathon-recap/), the next quarterly Hackathon will take place on November 14-15. We're looking forward to another opportunity for collaboration and meeting with new community members!\n\n## What's the deal?\n\nThis is a virtual event where community members get together to work on merge requests (MRs) and also to welcome and help new contributors. We now have a new [Hackathon landing page](/community/hackathon/), where you will be able to find more details as we get closer to the event. Again, we will have an exciting prize for everyone who has MRs merged within 10 days of the Hackathon:\n\n![GitLab slippers](https://about.gitlab.com/images/blogimages/q4-hackathon-blog/Slippers.JPG){: .shadow.medium.center}\n*\u003Csmall>GitLab slippers for everyone with merged MRs\u003C/small>*\n\nThe person with the most MRs merged during the Hackathon will be able to show off their grand prize around the neighborhood or at a nearby skate park!\n\n![GitLab skateboard](https://about.gitlab.com/images/blogimages/q4-hackathon-blog/Skateboard_-_Gitlab.png){: .shadow.medium.center}\n*\u003Csmall>GitLab skateboard for the grand prize winner\u003C/small>*\n\n## What else is taking place?\n\nIn addition to hacking, we plan to invite community experts for quick presentations plus Q&A sessions on various topics such as getting started as a new contributor, [Meltano](https://gitlab.com/meltano), issue triage, etc. over the two days. These sessions will also be recorded and available on [GitLab YouTube channel](https://www.youtube.com/gitlab).  If you want to see materials/recordings from the last Hackathon, you can find them in [the Q3 Hackathon wiki page](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/gitlab-hackathon/q3-2018-hackathon/wikis/Q3-2018-Hackathon#links-to-presentations-recordings).\n\n## Where can I find help during the Hackathon?\n\nFor communications during the Hackathon, we will use the [GitLab Community room in Gitter](https://gitter.im/gitlabhq/community). This is a channel designed to have community-related discussions and for community members to help each other as people have questions while contributing to GitLab. This is open to everyone, so please [join the room](https://gitter.im/gitlabhq/community) if you are not part of it already.\n\n## How do I get started with contributing?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\nCover image: [\"Gitlab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel).\n{: .note}\n",[268,864,675,278],{"slug":2859,"featured":6,"template":679},"q4-hackathon-announcement","content:en-us:blog:q4-hackathon-announcement.yml","Q4 Hackathon Announcement","en-us/blog/q4-hackathon-announcement.yml","en-us/blog/q4-hackathon-announcement",{"_path":2865,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2866,"content":2871,"config":2876,"_id":2878,"_type":16,"title":2879,"_source":17,"_file":2880,"_stem":2881,"_extension":20},"/en-us/blog/hackathon-recap",{"title":2867,"description":2868,"ogTitle":2867,"ogDescription":2868,"noIndex":6,"ogImage":1737,"ogUrl":2869,"ogSiteName":713,"ogType":714,"canonicalUrls":2869,"schema":2870},"Recapping the first GitLab Hackathon","What we accomplished and learned from the Hackathon on September 27-28.","https://about.gitlab.com/blog/hackathon-recap","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Recapping the first GitLab Hackathon\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2018-10-09\",\n      }",{"title":2867,"description":2868,"authors":2872,"heroImage":1737,"date":2873,"body":2874,"category":14,"tags":2875},[1840],"2018-10-09","\n\nWhen we wrapped up our first Hackathon on September 28th, I was impressed both\nwith the energy from participants (including many first-time contributors) and\nwhat the GitLab community accomplished over two days.\n\n## So what did we accomplish?\n\nOne of the key goals of the event was to encourage community members to contribute\nMerge Requests (MRs), and the community delivered more than 20 MRs, with 15 of\nthem merged as of October 8th. You can see the list of MRs at the\n[Hackathon Community MRs page](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/issues/4).\nThis is pretty impressive when you consider that community members had a less than\n2-weeks notice for the event.\n\n## What else happened during the event?\n\nIn addition to hacking, we had several community experts deliver tutorial\nsessions on topics ranging from\n[GitLab Development Kit](https://www.youtube.com/watch?v=gxn-0KSfNaU),\n[documentation](https://www.youtube.com/watch?v=8GT2XOkpSi4&feature=youtu.be),\n[internationalization/translation](https://www.youtube.com/watch?v=LJ9oSSx0qyY&feature=youtu.be),\n[UX design](https://www.youtube.com/watch?v=q_nq5OCiktE&feature=youtu.be), and\n[Merge Request Coaches](https://www.youtube.com/watch?v=daCFv9tAQXw&feature=youtu.be).\nRecordings/slides from all the sessions can also be found on the [Hackathon wiki page](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/wikis/Q3%272018-hackathon).\nWe also identified a number of issues/bugs as listed on the [wiki](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/wikis/Q3%272018-hackathon#issuesbugs-found-during-the-hackathon),\nand we will certainly be following up on these.\n\n## Will there be another Hackathon event in the future?\n\nOur plan is to have a Hackathon event every quarter, and I'm excited to announce\nthat the Q4 Hackthon will take place on November 14-15. Stay tuned for further\nannouncements in another blog post and discussions on the\n[GitLab Community room in Gitter](https://gitter.im/gitlabhq/community)\nand on the [GitLab forum](https://forum.gitlab.com/). In addition,\nif you have any suggestions for topics and/or feedback on last month's event,\nplease mention them on the [GitLab Community room in Gitter](https://gitter.im/gitlabhq/community)\nto help us improve future Hackathons.\n\n## Hackathon prizes\n\nAs we announced at the Hackathon kickoff, everyone who had MRs merged will\nreceive a token of our appreciation so they can purchase GitLab merchandise at\nthe [GitLab store](https://shop.gitlab.com/). During the Hackathon period,\neight people had MRs merged and the \"grand prize\" winner with most MRs merged is\n[George Tsiolis](https://gitlab.com/gtsiolis) with seven merged MRs!\nCongratulations to everyone! I will reach out to all winners shortly.\n\n## How do I get started with contributing?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\nCover image: [\"Gitlab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel).\n{: .note}\n",[268,864,675,278],{"slug":2877,"featured":6,"template":679},"hackathon-recap","content:en-us:blog:hackathon-recap.yml","Hackathon Recap","en-us/blog/hackathon-recap.yml","en-us/blog/hackathon-recap",{"_path":2883,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2884,"content":2889,"config":2894,"_id":2896,"_type":16,"title":2897,"_source":17,"_file":2898,"_stem":2899,"_extension":20},"/en-us/blog/contributor-post-luke",{"title":2885,"description":2886,"ogTitle":2885,"ogDescription":2886,"noIndex":6,"ogImage":2158,"ogUrl":2887,"ogSiteName":713,"ogType":714,"canonicalUrls":2887,"schema":2888},"GitLab Code Contributor: Luke Picciau","New contributor Luke Picciau shares why he started contributing to GitLab.","https://about.gitlab.com/blog/contributor-post-luke","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Code Contributor: Luke Picciau\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2018-10-04\",\n      }",{"title":2885,"description":2886,"authors":2890,"heroImage":2158,"date":2891,"body":2892,"category":14,"tags":2893},[1840],"2018-10-04","\nFor this month's blog post, we're featuring a new contributor [Luke Picciau](https://gitlab.com/Qwertie), who started contributing to GitLab a few months ago.\n\n### When did you first contribute to GitLab?\nMy first contribution was in July 2018, with my MR to [add a button for regenerating 2FA codes](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20295).\n\n### Why and how did you decide to contribute to GitLab?\nI have been using GitLab pretty heavily since 2014. I decided to start contributing in order to practice developing features on a large project. Because I am very familiar with features of GitLab from the user perspective, navigating the code was easy and I was able to start adding new features quickly.\n\n### Which area(s) of the GitLab product are you interested in contributing to?\nI’d love to look into the new [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/) and see what improvements could be made, as I see this as a useful tool. Personally, I’d like to use it to write posts for my static site and see the compiled result in my browser as well.\n\n### Can you tell us what you do professionally (or academically if you're going to school)?\nI am a full stack web developer. I primarily use Rails and VueJS. Currently I am also studying for a Bachelor of Information Technology at the University of South Australia. I’m also building an open source website for fitness tracking and analytics of GPS recordings. It’s not quite ready to use yet, but I am pushing regular updates to [the repo](https://gitlab.com/pikatrack/pikatrack).\n\n### What do you like to do when you're not working or studying?\nI’ll often be helping open source projects such as mapping the local area on [Open Street Map](https://www.openstreetmap.org). I also love to go down to the mountain bike parks around Adelaide.\n\n### Can you tell us where you live and what you like about your area?\nI live in [Adelaide, South Australia](https://www.google.com/maps/place/Adelaide+SA,+Australia/@-35.0278392,134.1260638,6z/). My favorite thing about the area is living close to so many national parks and amazing mountain bike trails which give endless exploration possibilities.\n\n![Luke on his mountain bike](https://about.gitlab.com/images/blogimages/Luke_Picciau_mountain_biking_new.jpg){: .shadow.small.center}\n\n### What advice do you have for others who may be interested in contributing to GitLab?\nOne of the things I find most useful is using an IDE or text editor with “go to definition” support. This allows you to click on function and class names and be taken to the place where they are defined. This, in my opinion, is an essential feature for working on a codebase as large as GitLab, especially in a language like Ruby, where it can be difficult to work out where things have been imported from. I personally use [RubyMine](https://www.jetbrains.com/ruby/), but I have been told [Vim](https://www.vim.org/) can also be set up with good Ruby support. Another tip I have is if you get part way through making a change and get stuck on something or need advice on what should be done, commit the changes and [create a merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#doc-nav) with what you have done and any questions you have. Someone should reply to the merge request to help you get the changes finished and ready for merge.\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[268,864,675,865],{"slug":2895,"featured":6,"template":679},"contributor-post-luke","content:en-us:blog:contributor-post-luke.yml","Contributor Post Luke","en-us/blog/contributor-post-luke.yml","en-us/blog/contributor-post-luke",{"_path":2901,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2902,"content":2907,"config":2912,"_id":2914,"_type":16,"title":2915,"_source":17,"_file":2916,"_stem":2917,"_extension":20},"/en-us/blog/gitlab-hackathon",{"title":2903,"description":2904,"ogTitle":2903,"ogDescription":2904,"noIndex":6,"ogImage":1737,"ogUrl":2905,"ogSiteName":713,"ogType":714,"canonicalUrls":2905,"schema":2906},"Announcing the GitLab Hackathon","The first Hackathon event for the GitLab community will take place September 27-28.","https://about.gitlab.com/blog/gitlab-hackathon","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Announcing the GitLab Hackathon\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2018-09-17\",\n      }",{"title":2903,"description":2904,"authors":2908,"heroImage":1737,"date":2909,"body":2910,"category":14,"tags":2911},[1840],"2018-09-17","\n\nWhat makes GitLab a great community is that contributions to the GitLab product come from everyone, regardless of whether they are employed by GitLab or not. Concrete evidence of broad community contribution can be seen in the more than 2,500 merged  [“community contribution”](https://gitlab.com/groups/gitlab-org/-/merge_requests?label_name%5B%5D=Community+contribution&scope=all&sort=weight&state=merged) MRs. This community contribution not only helps to enhance the GitLab product, but also brings fresh ideas and perspectives.\n\n![Screenshot showing more than 2,500 merged community MRs](https://about.gitlab.com/images/blogimages/2018-09-13-gitlab-hackathon-inline.png){: .shadow.medium.center}\n*\u003Csmall>MRs from community members not employed by GitLab\u003C/small>*\n\n## What's the deal?\n\n In order to build momentum and to provide a forum for community members to get together, I'm excited to announce that we're holding a [GitLab Hackathon on September 27 and 28](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/wikis/Q3%272018-hackathon). This virtual event will kick off at 07:00 UTC on the 27th and the focus will be to work on issues that are [\"Accepting merge requests\"](https://gitlab.com/gitlab-org/gitlab/-/issues?label_name%5B%5D=Accepting+merge+requests&sort=weight_asc). As an incentive, anyone who has their MRs merged within a week of Hackathon period will receive a voucher for GitLab swag. We will also have a bigger prize for the person with the most MRs merged.\n\n## What else is going on?\n\nIn addition to hacking, we plan to invite community experts for quick presentations plus Q&A sessions on various topics over the two days. These sessions will also be recorded and available on [GitLab YouTube channel](https://www.youtube.com/gitlab). The Hackathon will be followed by the [Issue Bash](/community/issue-bash/) from September 29-30.\n\n## Where can I find help?\n\nFor communications during the Hackathon, we will use the new [GitLab Community room in Gitter](https://gitter.im/gitlabhq/community). We already have a [gitlabhq room](https://gitter.im/gitlabhq/gitlabhq) that’s been active with support discussions. However, we wanted to create a separate community room where contributors to GitLab can come together to have community-related discussions and to help each other as people have questions while contributing to GitLab. This is open to everyone, so please [join the room](https://gitter.im/gitlabhq/community) if you are not part of it already.\n\n## How do I get started with contributing?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\nCover image: [\"Gitlab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel).\n{: .note}\n",[268,864,675,278],{"slug":2913,"featured":6,"template":679},"gitlab-hackathon","content:en-us:blog:gitlab-hackathon.yml","Gitlab Hackathon","en-us/blog/gitlab-hackathon.yml","en-us/blog/gitlab-hackathon",{"_path":2919,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2920,"content":2925,"config":2930,"_id":2932,"_type":16,"title":2933,"_source":17,"_file":2934,"_stem":2935,"_extension":20},"/en-us/blog/contributor-post-jacopo",{"title":2921,"description":2922,"ogTitle":2921,"ogDescription":2922,"noIndex":6,"ogImage":2158,"ogUrl":2923,"ogSiteName":713,"ogType":714,"canonicalUrls":2923,"schema":2924},"GitLab Code Contributor: Jacopo Beschi","Core Team member Jacopo Beschi shares why he loves contributing to GitLab.","https://about.gitlab.com/blog/contributor-post-jacopo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Code Contributor: Jacopo Beschi\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2018-09-06\",\n      }",{"title":2921,"description":2922,"authors":2926,"heroImage":2158,"date":2927,"body":2928,"category":14,"tags":2929},[1840],"2018-09-06","\n\nThis is the second blog post [highlighting GitLab community members](/blog/contributor-post-vitaliy/)\nwho are making code contributions to GitLab. This month, we're featuring Jacopo\nBeschi, who is based in Italy and is also a member of the [Core Team](/community/core-team/).\n\n### How long have you been contributing to GitLab?\n\nI've been contributing since late 2016.\n\n### Why and how did you decide to contribute to GitLab?\n\nI was looking for an interesting open source software application mostly written\nin Ruby to contribute to. After some Googling around, I found GitLab and instantly\nfell in love with the application and this community.\n\n### Which areas of the GitLab product do you contribute to?\n\nI've contributed to multiple areas of GitLab, such as [backend](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18757),\n[frontend](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9890),\n[API](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16478),\n[Utility](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11579),\nand [Quality](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15188)\nwhich are written in Rails.\n\nI haven’t had a chance to contribute to the Golang part of GitLab, such as\n[GitLab Runner](https://docs.gitlab.com/runner/), [Gitaly](https://docs.gitlab.com/ee/administration/gitaly/),\nor [GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse).\n\n### Can you tell us what you do professionally?\n\nCurrently, I work as technical lead for [Iubenda](http://www.iubenda.com), a SaaS\nprovider focused on privacy and cookie policies.\n\n### What do you like to do when you're not working?\n\nWhen I’m not working, I enjoy training in the gym and spending time with my wife and friends.\n\n### What advice do you have for others who may be interested in contributing to GitLab?\n\nDon’t be nervous about getting started! This [Contributing to GitLab page](/community/contribute/)\nexplains all the steps you need to take in order to be a successful contributor,\nand I encourage people to start there.\n\nGitLab also has a lot of [online documentation](https://docs.gitlab.com/) that\nyou could search in order to solve most common questions that developers have.\n\n### Do you have anything else you’d like to share?\n\nContributing to GitLab not only enhances your resume but also allows you to get\nin touch with great people who can help you improve your technical knowledge.\nIn addition, your contribution to GitLab will affect the lives of thousands of\ndevelopers around the globe!\n\n## Interested in learning how you can contribute?\n\nAs Jacopo already suggested, a good place to start is the\n[Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[268,864,675,865],{"slug":2931,"featured":6,"template":679},"contributor-post-jacopo","content:en-us:blog:contributor-post-jacopo.yml","Contributor Post Jacopo","en-us/blog/contributor-post-jacopo.yml","en-us/blog/contributor-post-jacopo",{"_path":2937,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2938,"content":2944,"config":2950,"_id":2952,"_type":16,"title":2953,"_source":17,"_file":2954,"_stem":2955,"_extension":20},"/en-us/blog/contributing-to-gitlab-with-ease",{"title":2939,"description":2940,"ogTitle":2939,"ogDescription":2940,"noIndex":6,"ogImage":2941,"ogUrl":2942,"ogSiteName":713,"ogType":714,"canonicalUrls":2942,"schema":2943},"Contributing to GitLab with ease","Everyone can contribute to GitLab, so here are a few tips to make your experience easy and pleasant.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678997/Blog/Hero%20Images/mergerequestsgame.jpg","https://about.gitlab.com/blog/contributing-to-gitlab-with-ease","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Contributing to GitLab with ease\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Lin Jen-Shin\"}],\n        \"datePublished\": \"2018-08-23\",\n      }",{"title":2939,"description":2940,"authors":2945,"heroImage":2941,"date":2947,"body":2948,"category":14,"tags":2949},[2946],"Lin Jen-Shin","2018-08-23","\nAs a [Merge Request Coach](https://handbook.gitlab.com/job-families/expert/merge-request-coach/), I am happy to\nhelp community contributors feel comfortable when contributing\nto GitLab. During my time reviewing merge requests, I’ve learned a bit about\nhow it feels contributing to GitLab as a newcomer, and I’d like to share\nmy learnings with you.\n\n## Common issues in an MR (merge request)\n\nIn the past, I think styling might have been one of the most common issues.\nHowever, we’re improving our CI to run more static analysis, so these issues\nare now automatically pointed out. Today, contributors can easily see what\ndidn’t pass CI, and they can fix the issues very quickly, so this is not as\ncommon as it was in the past.\n\nThe biggest issue today might be that many contributors don’t add tests, since\ntests often require much more effort than fixing or adding something. If\nyou’re struggling with adding tests, please don’t worry. Merge request coaches\ncan tell you how to add tests when we see your contribution, and we’ll work\nthrough it together.\n\n## Best practices\n\n1. If you only remember one best practice, I hope it is to keep this\nreference handy when [contributing to GitLab](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/contributing/index.md).\nI know it’s super long, but it has all the information you need when it comes\nto making contributions to GitLab.\n\n2. Get [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit) set up\nlocally if you haven’t already. Running tests locally is the best way to\ndevelop and debug, and I highly encourage that you incorporate this into your\nworkflow.\n\n3. Don’t ignore CI. If your pipeline didn’t pass, it’s important to go back and\nidentify the problem. Troubleshooting issues is a great way to practice your\nskills and help you learn from mistakes.\n\n4. Look at the [GitLab team page](/company/team/) and pick a merge request coach to\nping if you need help. Merge request coaches guide contributors and will even\njump in to help finish an MR if a contributor can no longer work on it,\nensuring that the attribution stays with the original contributor. Our goal is\nto help everyone feel comfortable and empowered to contribute even with\nsmallest possible effort. Coaches have other responsibilities and don’t always\nproactively look for contributors who need help, so ping them if you’re stuck\nor ready for a review. If they’re not the right person to ping, they’ll pass\nyou over to the right one. We love helping community contributors, and we look\nforward to guiding and working with you.\n\n## Little-known features\n\nWe [recently welcomed](/blog/introducing-gitlab-s-integrated-development-environment/)\nWeb IDE to quickly edit multiple files on the web directly without cloning\nthe whole repository. Web IDE is useful if you just want to make some small\nchanges online. If you’d like to learn more about Web IDE, please\nhead over to our [documentation](https://docs.gitlab.com/ee/user/project/web_ide/).\n\nSince GitLab's development velocity is pretty high, sometimes conflicts can\nhappen very frequently. Did you know that you can resolve conflicts directly\nfrom the web UI? I really love this feature, because it’s very easy to resolve\nsimple conflicts, and I don’t need to launch my editor or Git to pull, merge,\nand push. With some simple clicks, I can save a lot of time for simple\nconflicts.\n\n## What everyone should know about MRs\n\nTo me, an MR is a tool to interactively develop and explore with other people.\nDon’t worry about being perfect in the first version of your MR. We learn\nthrough our mistakes and get better over time.\n\nIf you’ve made tons of contributions, we invite you to join our\n[core team](/community/core-team/) or apply for a [full-time position](/jobs/) at GitLab.\nThe MR is one of the most important ways we work together, and we’d love to\ncollaborate with you.\n\n## What to do if you’re struggling\n\nIf you’re having some trouble getting the hang of merge requests, I suggest\ntaking a look at how others work on the MRs. Following other people’s example\ncan help you understand what they did and why they did it. Reaching out to a\nmerge request coach, joining discussions, and reviewing others’ code are also\nways to help you get up to speed. I think that interacting with others is a\ngreat way to learn and improve.\n\n## We’d love your contributions!\n\nWe really enjoy collaborating with community contributors, and we look forward\nto working together. If you don't know what you can contribute, please take a\nlook at [`Accepting merge requests`](https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name[]=Accepting+merge+requests).\nWe label some issues to explicitly call out the ones that we won’t schedule\nanytime soon, but we still want it. These issues usually have very clear scopes,\nso they often just require a simple implementation. They’re nice targets if\nyou don’t know what to contribute but want to gain experience.\n\nIf you would like to see how we handle community contributions, please take a\nlook at [`Community contribution`](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?label_name[]=Community%20contribution).\nWe put this label on all community contributions, therefore you can easily\nfind all the past and current community contributions. We look forward to\nyour future contributions as well!\n\n[Cover image](https://unsplash.com/photos/vqDAUejnwKw) by\n[Victor Freitas](https://unsplash.com/@victorfreitas), licensed\nunder [CC X](https://unsplash.com/license).\n{: .note}\n",[268,864,2475,1765,675],{"slug":2951,"featured":6,"template":679},"contributing-to-gitlab-with-ease","content:en-us:blog:contributing-to-gitlab-with-ease.yml","Contributing To Gitlab With Ease","en-us/blog/contributing-to-gitlab-with-ease.yml","en-us/blog/contributing-to-gitlab-with-ease",{"_path":2957,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2958,"content":2964,"config":2970,"_id":2972,"_type":16,"title":2973,"_source":17,"_file":2974,"_stem":2975,"_extension":20},"/en-us/blog/freedesktop-org-migrates-to-gitlab",{"title":2959,"description":2960,"ogTitle":2959,"ogDescription":2960,"noIndex":6,"ogImage":2961,"ogUrl":2962,"ogSiteName":713,"ogType":714,"canonicalUrls":2962,"schema":2963},"Welcome to GitLab, freedesktop.org!","Freedesktop.org, the home of open source desktop technology development, has migrated to GitLab to improve their workflow and modernize their service.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671252/Blog/Hero%20Images/gitlab-desktop-org-cover.png","https://about.gitlab.com/blog/freedesktop-org-migrates-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Welcome to GitLab, freedesktop.org!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2018-08-20\",\n      }",{"title":2959,"description":2960,"authors":2965,"heroImage":2961,"date":2967,"body":2968,"category":14,"tags":2969},[2966],"Rebecca Dodd","2018-08-20","\nSorry to [keep banging on about it](/blog/drupal-moves-to-gitlab/), but we get pretty excited when [open source projects](/blog/welcome-gnome-to-gitlab/) tell us they’re [#movingtogitlab](/blog/movingtogitlab/). There’s always more room at our inn. So we’re very happy to welcome [freedesktop.org](https://www.freedesktop.org/wiki/) into the fold! We chatted to Daniel Stone, project administrator, about what the project does and why they’re joining us.\n\n## Q & A\n\n- [What is freedesktop.org?](#what-is-freedesktoporg)\n- [How is freedesktop.org used?](#how-is-fdo-used)\n- [What's the connection between freedesktop.org, X Window System, and Linux?](#whats-the-connection-between-fdo-x-window-system-and-linux)\n- [How many contributors work on the project?](#how-many-contributors-work-on-the-project)\n- [Why would someone use freedesktop.org instead of macOS or Microsoft Windows?](#why-would-someone-use-fdo-instead-of-macos-or-microsoft-windows)\n- [Why are you migrating to GitLab?](#why-are-you-migrating-to-gitlab)\n- [How are you anticipating the move to be beneficial?](#how-are-you-anticipating-the-move-to-be-beneficial)\n\n### What is freedesktop.org?\n\nCreated in 2000 by Havoc Pennington (a GNOME developer), freedesktop.org (or fd.o) is a [forge](https://en.wikipedia.org/wiki/Forge_(software))-type hosting site. The idea was to create a neutral collaboration space between [GNOME](/blog/welcome-gnome-to-gitlab/), [KDE](/blog/welcome-kde/), Enlightenment, and other open source desktops. Unlike integrated systems, like Windows and macOS, the open source desktop lacks a lot of shared foundations: what should you open files with, how should you manage windows, and so forth.\n\nOriginally fd.o was a home for these desktop developers to collaborate on common standards, so programs could run portably with the same functionality across different desktops. In 2004, xwin.org was formed by a group of open source graphics developers unhappy with the closed-shop state of the XFree86 project. The two projects of fd.o and xwin.org merged shortly after xwin.org’s founding, with fd.o playing host to the X.Org Foundation, which supervises and facilitates the ongoing development of the graphics stack.\n\nOver the years since, our role as a neutral home for all sorts of desktop technology development has seen us add projects such as GStreamer, LibreOffice, and PulseAudio to our diverse family. Some projects such as systemd and Flatpak originally began their development on fd.o, but moved out to other hosting platforms which better suited their needs and workflow.\n\n### How is fd.o used?\n\nMost of our projects are invisible to users: NetworkManager is probably responsible for driving your Wi-Fi under the hood, though you’re unlikely to interact with it directly. Mesa and Wayland/X.Org will provide the underlying plumbing to render your games and your whole UI, but these are mostly invisible. Your desktop probably leans heavily on the D-Bus message-passing system. Most of it is plumbing.\n\n### What's the connection between fd.o, X Window System, and Linux?\n\nAs part of the graphics stack, fd.o hosts the development of the Linux kernel’s graphics development: drivers from all vendors part of the mainstream kernel (and some which aren’t yet!) use our Git hosting, mailing lists, bug tracking, and other services to build the core kernel graphics infrastructure. All this development happens on our infrastructure, which is then fed into the core Linux kernel during its \"merge window\" every release.\n\nThe X.Org Foundation tries to enable the work of a wide body of open source graphics projects. Originally X.Org itself was just the X Window System, but over the years the code evolved out of X.Org into a number of enabling projects. These include not just alternative window systems such as Wayland, the Mesa 3D graphics library for hardware-accelerated OpenGL, OpenGL ES and Vulkan, Cairo and Pixman for software rendering, libinput for input device handling, and much more. We play host to all those projects, with the Foundation providing an accountable body for administrative work, conference organization, and so on.\n\nOther freedesktop.org projects, as said before, provide all the glue around the margins of your desktop. Providing a database of available applications and preferred MIME type handlers, network device management, inter-process communication, a PDF renderer; in general, all the things we can do well in one place, to enable people who want to write desktop environments to focus on the thing that matters to them: building the actual desktop!\n\nAs part of this, we’ve always tried to stay strenuously vendor-neutral and also project-neutral within the desktop community. Rather than \"picking winners\" or enforcing directions on external projects, we try to slowly and gently build consensus as a neutral forum.\n\n### How many contributors work on the project?\n\nHard to say! We have around 1,300 registered users who directly commit to our family of projects. Not all of them are active of course, but many developers do not have direct commit access and aren’t represented in that figure. We have around 25,000 people subscribed to our various development mailing lists.\n\n### Why would someone use fd.o instead of macOS or Microsoft Windows?\n\nMuch like GitLab, freedesktop.org is an open source, open-participation, neutral platform. Running an open source desktop through distributions such as Arch, Debian, Fedora, or Ubuntu – all of which use our enabling technology – gives the user a fully open source system. This is incredibly empowering: as a user, you have the ability to dive into any part of your system, make the changes you want to see, and participate openly in these projects to see your improvements work upstream.\n\n>As a user, you have the ability to dive into any part of your system, make the changes you want to see, and participate openly in these projects to see your improvements work upstream\n\n### Why are you migrating to GitLab?\n\nOver the years fd.o has been running, we’ve accumulated a wide variety of services: our LDAP-based account system forked back in 2004, Bugzilla for issue tracking, Mailman for mailing lists, cgit and hand-rolled Git hosting, Patchwork for pulling patches from the mailing list when they are submitted for review, Jenkins for build infrastructure, ikiwiki for project wikis, still an FTP server somewhere; the list goes on.\n\nIn terms of workflow, we simply can’t provide some of our projects the workflow they want with this infrastructure. Over the years since we begun, the norm of software development has moved from throwing patches around via email, to fully distributed version control with integrated review and issue tracking, and so on. On paper we provide those services, but integration between them involves a lot of duct tape, and this shows to the users. We saw multiple projects either leave fd.o and move to alternate hosting platforms, or just not develop on our infrastructure to begin with, because we weren’t offering anything like the same level of functionality and convenience as those services.\n\n>Over the years, the norm of software development has moved from throwing patches around via email, to fully distributed version control with integrated review and issue tracking, and so on. On paper we provide those services, but integration between them involves a lot of duct tape, and this shows to the users.\n\nOne of the issues with freedesktop.org being such a diverse family, is that there is no central driven organization behind it. The site is currently run by three volunteers, all of whom keep the site running in our spare time. Maintaining all these services – many of them forked to add now-essential features like spam prevention, as well as our own custom local work for service integration – takes a surprising amount of time, to the point where just keeping it running is about all we can do. Actual improvements are very difficult to implement in the time we have, and even when we can do them, making sure all our projects can take full advantage of them is sometimes too much for us.\n\n### How are you anticipating the move to be beneficial?\n\nFirstly, for the workflow, having linked repository management, issue tracking, code review, CI pipelines and feedback, container repositories, wikis, and websites, provides functionality we couldn’t before – or at least, we were providing a pale imitation of it. As all of this is provided in [GitLab Core](/pricing/) and backed by a single coherent permission model, we are able to open these services up to our member projects who can work with them autonomously, rather than waiting for the admins to deal with services for them.\n\nFrom an admin point of view, having a single application which takes care of all of this will drastically reduce the time we spend treading water and dealing with the impedance mismatch between the disparate services we’ve had until now. Bringing GitLab up on Kubernetes has not been without its challenges as we attempt to bring our service administration skills up into the 21st century, but already it’s shown us that we can move drastically quicker than we have been able to in the past.\n\n>From an admin point of view, having a single application which takes care of our entire workflow will drastically reduce the time we spend treading water and dealing with the impedance mismatch between the disparate services we’ve had until now\n\nIn terms of service modernization, another huge improvement is a modern approach to identity and security. Running an open community site in 2018 is not a fun place to be: not just keeping on top of security vulnerabilities, but targeted break-in attempts and spam. A lot of our previous services aren’t designed to deal with this kind of abuse. Having a single identity service on GitLab – which can link to external identity providers such as Google and GitLab.com, and make use of two-factor authentication – is a huge leap forward for us. Similarly, a coherent approach to spam which doesn’t involve spending an evening trawling through SQL tables by hand makes dealing with spam actually practical!\f\n\n### How can people get involved?\n\nSince we are an umbrella of diverse projects, there's no single answer. We keep a [list of our active projects on our website](https://www.freedesktop.org/wiki/GettingInvolved/): pick the one that's closest to your heart, check out their site and repo, and send your first MR.\n",[675,268,1583,1921],{"slug":2971,"featured":6,"template":679},"freedesktop-org-migrates-to-gitlab","content:en-us:blog:freedesktop-org-migrates-to-gitlab.yml","Freedesktop Org Migrates To Gitlab","en-us/blog/freedesktop-org-migrates-to-gitlab.yml","en-us/blog/freedesktop-org-migrates-to-gitlab",{"_path":2977,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2978,"content":2983,"config":2988,"_id":2990,"_type":16,"title":2991,"_source":17,"_file":2992,"_stem":2993,"_extension":20},"/en-us/blog/drupal-moves-to-gitlab",{"title":2979,"description":2980,"ogTitle":2979,"ogDescription":2980,"noIndex":6,"ogImage":2776,"ogUrl":2981,"ogSiteName":713,"ogType":714,"canonicalUrls":2981,"schema":2982},"Come on in! Drupal is moving to GitLab","Free and open source platform Drupal is moving to GitLab to accelerate developer velocity and attract new talent and contributors to the project.","https://about.gitlab.com/blog/drupal-moves-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Come on in! Drupal is moving to GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2018-08-16\",\n      }",{"title":2979,"description":2980,"authors":2984,"heroImage":2776,"date":2985,"body":2986,"category":14,"tags":2987},[2966],"2018-08-16","\nWe never get tired of hearing about [open source projects joining the GitLab fold](/blog/welcome-gnome-to-gitlab/). So, welcome to GitLab, [Drupal](https://www.drupal.org/)! In light of this news, we chatted to Director of Engineering for the Drupal Association, [Timothy Lehnen](https://drupal.org/u/hestenet), about the project and why they're moving to GitLab.\n\n## Q&A\n\n- [What is Drupal?](#what-is-drupal)\n- [How is Drupal used?](#how-is-drupal-used-how-does-it-help-people)\n- [How many contributors work on the project?](#how-many-contributors-work-on-the-project)\n- [Why might someone use Drupal over other content management tools?](#why-might-someone-use-drupal-over-other-content-management-tools)\n- [Why are you migrating to GitLab?](#why-are-you-migrating-to-gitlab)\n- [How do you expect this move to beneficial to Drupal?](#how-do-you-expect-this-move-to-beneficial-to-drupal)\n- [How can people get involved in the project?](#how-can-people-get-involved-in-the-project)\n\n### What is Drupal?\n\nDrupal is a platform for building ambitious digital experiences. It was one of the first open source content management systems released more than 17 years ago, and is now used to power content-driven experiences including: the web, mobile, augmented reality, in-flight entertainment, medical devices, and more. Drupal is also the leading platform for building the open web. In a time when the dangers of walled-garden content publishers are becoming more and more clear, Drupal is a powerful tool to keep control in the hands of creators.\n\n### How is Drupal used? How does it help people?\n\nDrupal powers important platforms for engagement all over the world. In the governmental space you can find Drupal powering systems like [NASA.gov](https://www.nasa.gov/), the Australian [GovCMS](https://www.govcms.gov.au/), and the European Union. In the commerce space, Drupal is used to power traditional ecommerce websites, but also the holistic point-of-sale and accounting systems of the billion dollar businesses like ZKungFu, the largest directly operated food chain in China. Drupal is also the backbone of healthcare and higher education systems across the globe. Drupal can even be found behind the scenes running internal systems for the world's largest technology companies.\n\nFinally, Drupal empowers individuals and small teams to rapidly respond to current events, pitching in to give back to their communities. For example, UC Davis just launched their [Article 26 Backpack](https://www.drupal.org/blog/building-digital-backpacks-for-syrian-refugees) program for Syrian refugees, powered by Drupal.\n\n### How many contributors work on the project?\n\nIn the past year 111,783 people have contributed to Drupal in some form on Drupal.org. Over the course of the last 17 years, many hundreds of thousands of people have contributed in some way to the Drupal project.\n\n### Why might someone use Drupal over other content management tools?\n\nDrupal is a tool for building many kinds of internet-connected applications (not just websites), and is a powerful tool whenever you want to deliver rich, meaningful experiences. Drupal's not the best choice for brochure-ware sites, but that doesn't mean it's only limited to the enterprise. In any situation where you are managing large volumes of data, personalizing content for your end-users, or need a content hub to be consumed by a variety of interfaces and end-points, Drupal is an excellent choice.\n\n>In any situation where you are managing large volumes of data, personalizing content for your end-users, or need a content hub to be consumed by a variety of interfaces and end-points, Drupal is an excellent choice\n\nEven when your needs are less ambitious, Drupal has a rich library of modules and third-party integrations that provide the building blocks for powerful platforms.\n\n### Why are you migrating to GitLab?\n\nThe Drupal project began before Git was invented. The first version [control system](/topics/version-control/what-is-centralized-version-control-system/) that the project used was CVS, before the project migrated to Git in 2012. Over the course of almost two decades the Drupal project has developed our own contribution practices and developer tools, and while many of those tools and practices are leading examples in the open source world, others have fallen behind. For example, the Drupal project still handles code contributions through a patch workflow rather than through a pull/merge request workflow that has become the standard for collaborative development.\n\nWhen we began the search for a new partner to help us modernize our developer tooling, we set the following goals:\n\n- Adopt a developer workflow that will be familiar to the millions of developers outside our community\n- Preserve those unique elements of how we collaborate that have made the Drupal project so successful:\n    - Many-to-one collaboration: that is to say, many developers collaborating on a single solution to a problem\n    - Maintainer approval workflow\n    - Picking up on longstanding issues where other collaborators left off\n    - Contribution credit\n- If possible, leverage an expert partner who will help keeping our tooling up to date as open source collaboration tools continue to evolve\n\nDuring our search, GitLab was emerging as a powerful new player in the code collaboration market, and of all the teams we spoke to, GitLab's leadership demonstrated the greatest commitment to working with us to find a solution that would work for the Drupal project. The combination of that commitment to collaboration and the powerful featureset that GitLab continues to improve at a rapid pace is what helped us make our ultimate decision.\n\n### How do you expect this move to beneficial to Drupal?\n\nMoving our code collaboration tools to GitLab will help Drupal to accelerate developer velocity, and attract new talent and contributors to the project.\n\nBy giving Drupal contributors access to a merge request workflow, inline editing tools, code review, and other features of the GitLab platform they can spend less time on the administrivia and more time building Drupal.\n\n>By giving Drupal contributors access to a merge request workflow, inline editing tools, code review, and other features of the GitLab platform they can spend less time on the administrivia and more time building Drupal\n\nSimilarly, by adopting a toolchain that is much more familiar to the up-and-coming generation of developers, we can lower the barriers to entry for new contributors to join our community. For more information about the Drupal project's journey towards selecting GitLab, check out our [blog series on Drupal.org](https://www.drupal.org/drupalorg/blog/developer-tools-initiative-part-5-gitlab-partnership).\n\n### How can people get involved in the project?\n\nThe Drupal community has a comprehensive [Getting Involved Guide](https://www.drupal.org/getting-involved-guide) that can help individuals find their place in the Drupal community. There are also meet ups and conferences around the world that are a great way to start your Drupal journey. In particular, DrupalCon will be coming to [Seattle from April 8-12 2019](https://events.drupal.org/seattle2019).\n\nThe Drupal project's motto has always been \"Come for the code, stay for the community\" and seventeen years later, that's a sentiment we still believe in.\n",[675,268],{"slug":2989,"featured":6,"template":679},"drupal-moves-to-gitlab","content:en-us:blog:drupal-moves-to-gitlab.yml","Drupal Moves To Gitlab","en-us/blog/drupal-moves-to-gitlab.yml","en-us/blog/drupal-moves-to-gitlab",{"_path":2995,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2996,"content":3001,"config":3006,"_id":3008,"_type":16,"title":3009,"_source":17,"_file":3010,"_stem":3011,"_extension":20},"/en-us/blog/join-the-gitlab-community",{"title":2997,"description":2998,"ogTitle":2997,"ogDescription":2998,"noIndex":6,"ogImage":1533,"ogUrl":2999,"ogSiteName":713,"ogType":714,"canonicalUrls":2999,"schema":3000},"Join the GitLab Code Contributor Community!","How we're working to make contributions easier and more rewarding for the GitLab community.","https://about.gitlab.com/blog/join-the-gitlab-community","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Join the GitLab Code Contributor Community!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2018-08-13\",\n      }",{"title":2997,"description":2998,"authors":3002,"heroImage":1533,"date":3003,"body":3004,"category":14,"tags":3005},[1840],"2018-08-13","\nThere are [over 2,000 code contributors to GitLab](http://contributors.gitlab.com/) today and we want to welcome more contributors to the growing community.\n\nHaving been involved in other open source projects, I know how exciting it is to collaborate in an open community and work with passionate people from different parts of the world. I recently joined GitLab to work with our community of contributors, and I wanted to share a list of activities that I’m planning to help grow the community:\n\n## 1. Streamline onboarding documentations\n\nSo that it’d be easier for people to get started. There are already some initiatives on the way, such as this [merge request from a community member](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20682).\n\n## 2. Proactively reach out to first-time contributors\n\nI want to start congratulating new contributors who successfully complete their first merge request. Stay tuned for new swag and opportunities to be paired with mentors who are experienced GitLab community members.\n\n## 3. Launch new blog post series\n\nSpeaking of experienced contributors, I’d like to highlight some of them with a new blog post series, since their experience working in the GitLab community will be helpful for new contributors. The first post features Core Team member [Vitaliy Klachkov](/blog/contributor-post-vitaliy/).\n\n## 4. Kick off Core Team meeting\n\nWe just kicked off a regular meeting with the [Core Team](/community/core-team/) to discuss topics of interest for the GitLab community. This recorded meeting will be open to anyone. The Core Team will also use [Service Desk](https://gitlab.com/gitlab-core-team/general/issues/service_desk) so that anyone in the community can view and participate in discussions.\n\nThanks for reading my blog post. Your feedback/questions are always welcome and you can reach me at rpaik@gitlab.com.\n\n## Interested in learning how you can contribute?\n\nA good place to start would be the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, and translation.\n",[268,864,675],{"slug":3007,"featured":6,"template":679},"join-the-gitlab-community","content:en-us:blog:join-the-gitlab-community.yml","Join The Gitlab Community","en-us/blog/join-the-gitlab-community.yml","en-us/blog/join-the-gitlab-community",{"_path":3013,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3014,"content":3019,"config":3024,"_id":3026,"_type":16,"title":3027,"_source":17,"_file":3028,"_stem":3029,"_extension":20},"/en-us/blog/contributor-post-vitaliy",{"title":3015,"description":3016,"ogTitle":3015,"ogDescription":3016,"noIndex":6,"ogImage":2158,"ogUrl":3017,"ogSiteName":713,"ogType":714,"canonicalUrls":3017,"schema":3018},"GitLab Code Contributor: Vitaliy Klachkov","Core Team member Vitaliy Klachkov shares how he started contributing to GitLab.","https://about.gitlab.com/blog/contributor-post-vitaliy","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Code Contributor: Vitaliy Klachkov\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n        \"datePublished\": \"2018-08-08\",\n      }",{"title":3015,"description":3016,"authors":3020,"heroImage":2158,"date":3021,"body":3022,"category":14,"tags":3023},[1840],"2018-08-08","\nWelcome to our new blog series featuring code contributors from the GitLab community! This blog will highlight the wonderful contributions made by GitLab community members and will hopefully inspire others to contribute to GitLab. For the first blog post, we are happy to welcome [Vitaliy “blackst0ne” Klachkov](https://gitlab.com/blackst0ne), who has been chosen as a [release MVP](/community/mvp/) three times!\n\n### How long have you been contributing to GitLab?\n\nI've been contributing since August 2016.\n\n### Why and how did you decide to contribute to GitLab?\n\nI read a news article about a new GitLab release and I didn’t even know what GitLab was back then. There was also a discussion on an example of a Rails-based project with a good codebase, and people suggested taking a look at GitLab.\n\nI was intrigued and decided to take a closer look at GitLab. I actually found\nroom for improvement in the codebase so I started pushing a few merge requests (MRs). I received responses within 1-2 days and I was very impressed. With some of the other communities, I’m used to waiting weeks for feedback.\n\nSo, I kept submitting more merge requests and so far, I have 227 merged MRs. I’m proud that I’m one of the top 50 contributors among 2000+ GitLab [code contributors](http://contributors.gitlab.com/) that include GitLab employees.\n\n### Which areas of the GitLab product do you contribute to?\n\nMostly it has been backend changes, but many of my MRs touched the frontend as well. I spent my time bringing popular features (e.g. [squash and merge to CE](https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html#doc-nav), [mermaid support](https://docs.gitlab.com/ee/user/markdown.html#mermaid), [switch markdown engine to CommonMark](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14835), [customizable branch name from issues](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13884), etc.), fixing technical debts (e.g. [migrate all spinach specs to rspec](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope=all&utf8=%E2%9C%93&state=all&author_username=blackst0ne&label_name%5B%5D=technical%20debt&label_name%5B%5D=Quality&search=Spinach)), upgrading [GitLab to Rails 5.0](https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=all&author_username=blackst0ne&label_name%5B%5D=rails5), and many other improvements.\n\n### Can you tell us what you do professionally?\n\nI am a full-stack web developer at [GEOPHYSTECH LLC](https://geophystech.ru/). The company is focused on seismology, earthquakes, and everything related to earthquake hazards.\n\n### What do you like to do when you're not working?\n\nI’m a big fan of sports or anything that keeps my body moving, such as running, swimming, snowboarding, table tennis, volleyball, ice-blading, football, CrossFit workout, etc.\n\nI also enjoy [chess](https://lichess.org/), reading books/articles, and UX-related things. I’ve been collaborating with GitLab’s UX team.\n\n### What advice do you have for others who may be interested in contributing to GitLab?\n\nContributing to GitLab is easy. If you want the experience of being a part of a popular open source project, you are more than welcome to join the GitLab community! You can also ping me on [Twitter](https://twitter.com/blackst0ne) if you have any questions or need any help as you get started.\n\n### Do you have anything else you’d like to share?\n\nGitLab has some nice [swag](https://shop.gitlab.com/)! I’ve gotten some great ones for my release MVPs.\n\n## Interested in learning how you can contribute?\n\nA good place to start would be the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, and translation.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[268,864,675,865],{"slug":3025,"featured":6,"template":679},"contributor-post-vitaliy","content:en-us:blog:contributor-post-vitaliy.yml","Contributor Post Vitaliy","en-us/blog/contributor-post-vitaliy.yml","en-us/blog/contributor-post-vitaliy",{"_path":3031,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3032,"content":3038,"config":3044,"_id":3046,"_type":16,"title":3047,"_source":17,"_file":3048,"_stem":3049,"_extension":20},"/en-us/blog/gitlab-ultimate-and-gold-free-for-education-and-open-source",{"title":3033,"description":3034,"ogTitle":3033,"ogDescription":3034,"noIndex":6,"ogImage":3035,"ogUrl":3036,"ogSiteName":713,"ogType":714,"canonicalUrls":3036,"schema":3037},"GitLab Ultimate and Gold now free for education and open source","Our top-tier SaaS and self-managed offerings are now free to educational institutions and open source projects. Find out how to apply.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680096/Blog/Hero%20Images/open-source-education-cover.png","https://about.gitlab.com/blog/gitlab-ultimate-and-gold-free-for-education-and-open-source","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Ultimate and Gold now free for education and open source\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2018-06-05\",\n      }",{"title":3033,"description":3034,"authors":3039,"heroImage":3035,"date":3040,"body":3041,"category":14,"tags":3042},[818],"2018-06-05","\n\n**Update 2023-02-15:** This blog has been updated to remove an outdated reference to separately purchasing paid support.\nCurrent information on GitLab's Open Source benefits can be found [here](https://about.gitlab.com/solutions/open-source/).\n{: .alert .alert-warning}\n\nIt has been a [crazy 24 hours for GitLab](/blog/movingtogitlab/). More than [2,000 people tweeted about #movingtogitlab](https://twitter.com/movingtogitlab). We imported [over 100,000 repositories](https://twitter.com/gitlab/status/1004143715844124673), and we've seen a 7x increase in orders. We went [live on Bloomberg TV](https://www.youtube.com/watch?v=o7Y-aQgr8Dk&feature=youtu.be&t=30m59s). And on top of that, Apple announced an Xcode integration with GitLab.\n\n\u003Cblockquote class=\"twitter-tweet\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">Apple just announced Xcode 10 is now integrated with GitLab making it seamless and easy for iOS developers to develop new and exciting applications with just a single application for the entire lifecycle.\u003Ca href=\"https://t.co/eQbtiY4IYm\">pic.twitter.com/eQbtiY4IYm\u003C/a>\u003C/p>— GitLab (@GitLab Chatops) \u003Ca href=\"https://twitter.com/gitlab/status/1003764673454342144?ref_src=twsrc%5Etfw\">June 4, 2018\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n![Github Imports Chart](https://about.gitlab.com/images/blogimages/github-imports-chart.png){: .medium.center}\n\nWe went live on YouTube on Sunday evening to answer your questions about #movingtogitlab and got a question from Mohammad Al-Ahdal who asked: \"What about Education Discounts or Student Dev Packs?\"\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/bKS6gJtTZes?start=3979\" frameborder=\"0\" allow=\"autoplay; encrypted-media\" allowfullscreen>\u003C/iframe>\n\nToday, we're excited to announce that GitLab Ultimate and Gold are now free for educational institutions and open source projects.\n\n1. [Educational institutions application](/solutions/education/)\n1. [Open source projects application](/solutions/open-source/)\n\n## What are GitLab Ultimate and GitLab Gold?\n\n[GitLab Ultimate and Gold](/pricing/) are our most comprehensive offerings. GitLab Ultimate is self-managed, whereas GitLab Gold is our SaaS offering hosted on GitLab.com. It includes all of the features in Core, Starter, and Premium, plus a more robust set of portfolio management and security features. For open source and educational projects, this means unlimited access to current and new features, including [Epics](https://docs.gitlab.com/ee/user/group/epics/), [Roadmap](https://docs.gitlab.com/ee/user/group/roadmap/), [Static Application Security Testing](https://docs.gitlab.com/ee/user/application_security/sast/), [Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/#doc-nav), and so much more!\n\n### Does it come with support?\n\nFree GitLab Ultimate and Gold accounts **do not** include support. Information on what's included can be found on our [open-source program page](https://about.gitlab.com/handbook/marketing/developer-relations/community-programs/opensource-program/).\n\n## Free GitLab account\n\nWhy provide a GitLab free account? We make GitLab free for education because we want students to use our most advanced features. Many universities already run GitLab. If the students use the advanced features of GitLab Ultimate and Gold they will take their experiences with these advanced features to their workplaces.\n\nWe would love to have more open source projects use GitLab. Public projects on GitLab.com already have all the features of GitLab Ultimate. And projects like [GNOME](https://www.gnome.org/news/2018/05/gnome-moves-to-gitlab-2/) and [Debian](https://salsa.debian.org/public) already run their own server with the open source version of GitLab. With today's announcement, open source projects that are comfortable running on proprietary software can use all the features GitLab has to offer, while allowing us to have a sustainable business model by charging non-open source organizations.\n\n",[675,3043],"news",{"slug":3045,"featured":6,"template":679},"gitlab-ultimate-and-gold-free-for-education-and-open-source","content:en-us:blog:gitlab-ultimate-and-gold-free-for-education-and-open-source.yml","Gitlab Ultimate And Gold Free For Education And Open Source","en-us/blog/gitlab-ultimate-and-gold-free-for-education-and-open-source.yml","en-us/blog/gitlab-ultimate-and-gold-free-for-education-and-open-source",{"_path":3051,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3052,"content":3058,"config":3063,"_id":3065,"_type":16,"title":3066,"_source":17,"_file":3067,"_stem":3068,"_extension":20},"/en-us/blog/microsoft-acquires-github",{"title":3053,"description":3054,"ogTitle":3053,"ogDescription":3054,"noIndex":6,"ogImage":3055,"ogUrl":3056,"ogSiteName":713,"ogType":714,"canonicalUrls":3056,"schema":3057},"Congratulations GitHub on the acquisition by Microsoft","The acquisition of GitHub by Microsoft is validation of the growing influence of software developers in the world.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680101/Blog/Hero%20Images/github-news-cover.png","https://about.gitlab.com/blog/microsoft-acquires-github","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Congratulations GitHub on the acquisition by Microsoft\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2018-06-03\",\n      }",{"title":3053,"description":3054,"authors":3059,"heroImage":3055,"date":3060,"body":3061,"category":14,"tags":3062},[818],"2018-06-03","\n\nCongratulations to GitHub on their [acquisition by Microsoft](https://www.bloomberg.com/news/articles/2018-06-03/microsoft-is-said-to-have-agreed-to-acquire-coding-site-github)! This is validation of the growing influence of software developers in the world, and the importance of [modern DevOps](/topics/devops/). The software community owes a lot to GitHub, and that includes the GitLab community. GitLab was first developed on GitHub and found its first contributors through it.\n\n## Code collaboration before GitHub\n\nOver the years, code collaboration has come a long way. Many developers will remember how code was often hosted on private websites, FTP servers, email, and IRC. We used to stuff a floppy disk or CD-ROM with code and mail it back and forth, or send patches to newsgroups or mailing lists in order to share and work on code together. It was a painful, error-prone time.\n\nGit, the [version control system](/topics/version-control/) used by GitHub, GitLab, and others, was first introduced in 2005. It allowed developers to work asynchronously, across the globe, on the same code. GitWeb went a step further, with its web interface for browsing a Git repository, including viewing contents of files, commit messages, and more.\n\nSourceForge offered the first glimpse of modern code collaboration by offering a central location to host and manage free, open source projects. Despite limited functionality and a cumbersome UI, SourceForge started bringing developers together in one place.\n\nEach step along the way improved the developer experience, allowed more people to contribute, and sped up the software development lifecycle.\n\n## A common place for code\n\nGitHub launched in 2008. While Git version control was a starting point for better code collaboration, GitHub made it even easier. By applying modern communication features inspired by social media sites, GitHub empowered social coding. It provided the first truly accessible UI to manage and review feature branches, and the ability to merge them with one-click “Pull Requests.” As a result, open source projects flocked to GitHub as a place to not only host code, but to grow a community as well.\n\n\u003Cdiv class=\"row\">\n\u003Cdiv class=\"col-md-6 col-sm-12\">\n\u003Cimg src=\"/images/blogimages/git-instaweb.png\" alt=\"GitWeb user interface\">\n\u003C/div>\n\u003Cdiv class=\"col-md-6 col-sm-12\">\n\u003Cimg src=\"/images/blogimages/github-ui.png\" alt=\"GitHub user interface\">\n\u003C/div>\n\u003Cdiv class=\"col-md-12 text-center\" style=\"margin-top: 5px\">\n\u003Cem>\u003Csmall>GitHub’s UI made it easier to manage and review feature branches compared to its predecessor, GitWeb.\u003C/small>\u003C/em>\n\u003C/div>\n\u003C/div>\n\n## What does the Microsoft acquisition mean for the industry?\n\nThe growing influence of software developers cannot be overstated. Developers are the [new kingmakers](https://thenewkingmakers.com/) and their influence within organizations is growing along with their value.\n\nGitHub has earned mindshare within the developer community, and Microsoft’s acquisition is certainly an attempt to garner and cultivate that mindshare. However, the long-term strategic implication seems to be that Microsoft wants to use GitHub as a means to drive Azure adoption.\n\nDeveloper tools have a high capacity for driving cloud usage. Once you have your application code hosted, the natural next step is to need a place to deploy it. Today, Microsoft fosters cloud adoption by tightly coupling Azure, its cloud service, together with Microsoft Visual Studio Team Services (VSTS), its set of development tools. Microsoft will likely integrate GitHub into VSTS in order to take advantage of the strong tie with Azure.\n\n> *“The way developers produce, deliver and maintain code has changed significantly in the last ten years and we applaud GitHub for being a driving force supporting the vast independent developer community through this evolution. This acquisition affirms the global importance of software developers and their influence in the enterprise. Microsoft likely acquired GitHub so it could more closely integrate it with Microsoft Visual Studio Team Services (VSTS) and ultimately help drive compute usage for Azure.” - [Sid Sijbrandij](/company/team/#sytses), GitLab CEO*\n\n## How does this relate to GitLab?\n\nWe applaud GitHub on its accomplishments and congratulate Microsoft on its acquisition. While we admire what's been done, our strategy differs in two key areas. First, instead of integrating multiple tools together, we believe a [single application](/handbook/product/single-application/), built from the ground up to support the entire DevOps lifecycle, is a better experience leading to a faster cycle time. Second, it’s important to us that the [core of our product always remain open source](/blog/gitlab-is-open-core-github-is-closed-source/) itself as well. Being “open core” means everyone can build the tools together. Having it all in a single application means everyone can use the same tool to collaborate together. We see the next evolution of software development as a world where everyone can contribute.\n",[675,3043,699],{"slug":3064,"featured":6,"template":679},"microsoft-acquires-github","content:en-us:blog:microsoft-acquires-github.yml","Microsoft Acquires Github","en-us/blog/microsoft-acquires-github.yml","en-us/blog/microsoft-acquires-github",{"_path":3070,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3071,"content":3076,"config":3081,"_id":3083,"_type":16,"title":3084,"_source":17,"_file":3085,"_stem":3086,"_extension":20},"/en-us/blog/welcome-gnome-to-gitlab",{"title":3072,"description":3073,"ogTitle":3072,"ogDescription":3073,"noIndex":6,"ogImage":1797,"ogUrl":3074,"ogSiteName":713,"ogType":714,"canonicalUrls":3074,"schema":3075},"GNOME, welcome to GitLab!","We’re excited to welcome free software project GNOME to the GitLab community.","https://about.gitlab.com/blog/welcome-gnome-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GNOME, welcome to GitLab!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2018-05-31\",\n      }",{"title":3072,"description":3073,"authors":3077,"heroImage":1797,"date":3078,"body":3079,"category":14,"tags":3080},[2966],"2018-05-31","\n\nGNOME, one of the most recognized, respected projects in the open source world, [has moved to GitLab](https://www.gnome.org/news/2018/05/gnome-moves-to-gitlab-2/) to manage their more than 400 software projects and nearly 900 annual contributors. We couldn’t be happier to welcome the GNOME community! The migration is great news for both our communities, and we hope it’s just the beginning of a long and productive partnership.\n\n[_Want to hear how it's going for GNOME now? We caught up with the project in September 2020_](/blog/gnome-follow-up/).\n{: .alert .alert-info .text-center}\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/v6GTrbfe9xk\" frameborder=\"0\" allow=\"autoplay; encrypted-media\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n\n## A catalyst for change\n\nLast year we were approached by developers of [Debian](/blog/automated-debian-package-build-with-gitlab-ci/) to consider dropping our Contributor License Agreement (CLA) in favor of the Developer’s Certificate of Origin (DCO). In November [we announced that we’d be switching to a DCO](/blog/gitlab-switches-to-dco-license/), and we’re happy that this change has been welcomed by the GNOME community too:\n\n>\"We applaud GitLab for dropping their CLA in favor of a more OSS-friendly approach. Open source communities are born from a sea of contributions that come together and transform into projects. This gesture affirmed GitLab's willingness to protect the individual, their creative process, and most importantly, keeps intellectual property in the hands of the creator.\" - Carlos Soriano, Board Director at GNOME\n\n## About GNOME\n\nGNOME software is used by millions of people worldwide, and is one of the largest and oldest free software projects. It’s best known for its desktop, which is a key part of the most popular GNU/Linux distributions, including Ubuntu, Debian, SUSE, and Fedora. However, the project also has a long history of producing critical pieces of software infrastructure: common parts of countless open source systems that are often taken for granted. Many essential, ubiquitous technologies began their life in the GNOME project, and have gone on to become the essential ingredients for a diverse range of products, communities, and companies. These include Mono, FOSS C# implementation used by Xamarin, a core team of Microsoft; and Inotify, Linux kernel file monitoring.\n\n“Throughout its history, the GNOME project has been the training ground for software engineers and contributors who have gone on to play important roles elsewhere,” says Nuritzi Sanchez, president of GNOME’s board of directors and core member of the engagement team. “With a focus on quality engineering, design-driven development, and system-level plumbing, GNOME serves as an excellent environment for new contributors, and GNOME alumni hold positions at Google, Apple, Microsoft, Red Hat, innovative startups, and beyond.”\n\nGNOME's software is found in televisions, e-book readers, in-vehicle infotainment systems, medical devices, and much more. The project continues to produce new, innovative technologies which are transforming the Linux ecosystem. Recent innovations include Flatpak and the accompanying app store, Flathub, which enables applications to run on any Linux-based operating system.\n\n## So, why GitLab?\n\nBefore migrating, GNOME used a broad range of tools to fulfil a number of specific purposes – from [CGit for hosting to Bugzilla for bug tracking](https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/ExistingState) – but the number of tools made the onboarding experience for new contributors cumbersome and confusing. They started looking for a single tool to meet more of their needs to make this process easier and to improve their own workflows.\n\n“We did an [extensive analysis](https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure) of multiple tools as we considered a solution that would fit all the requirements of an organization as big as GNOME,” says Nuritzi. “We had a set of hard requirements, with the most important one being that it must be free software, ideally not only in license but also in spirit.”\n\nYou can check out [their analysis](https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure) for a full account of the decision-making process.\n\n## What does the move mean for GNOME?\n\nGNOME was looking for a way to make it easier for newcomers to contribute, and they got it.\n\n“With a modern and familiar interface with well-designed tools, using GitLab makes the GNOME community more approachable – especially to a new generation of newcomers that is used to products that are modern-looking and easy to use,” says Nuritzi. They’ve also noticed that by using a single tool and having everyone under the same roof (as it were!), there’s more opportunity for teams to work together and cross-pollinate, resulting in a more engaged and collaborative community.\n\n### Better together\n\nApart from an easier workflow for newcomers and improved collaboration and cohesion between teams, GNOME has picked up on an unexpected benefit: the return of old projects and an influx of new ones. The ease of creating personal projects in GitLab has fostered better proximity between GNOME’s community of developers and [projects](https://gitlab.gnome.org/explore/groups), even if they aren’t part of the official GNOME project. “This allows those projects to be closer to our community of developers and products, and helps us increase our reach,” says Nuritzi. “We’re also very pleased to see that some major Linux distributions have begun to move part of their operations to groups in GNOME’s GitLab. This has allowed more collaboration between GNOME and these distributions, and is a great step forward in helping to create a tighter-knit broader community.”\n\nThis improved closeness and reach is what we’re really excited about – when it comes to open source communities using GitLab, the more the merrier we say! It’s our hope that the boost in collaboration and networking GNOME has experienced will extend to our own community, as well as those of other open source projects moving to GitLab.\n\n## How to contribute\n\nIn keeping with our own vision of “everyone can contribute,” GNOME has opportunities for contributors from all backgrounds. “If you like marketing and community management, we have the engagement team, if you’re into doing translations and documentation, we have the teams for that. If you like designing software, we have the design team. And if you want to contribute code, there are many projects with maintainers who welcome newcomers and can help answer the questions they may have,” says Nuritzi. “Each team has its own resources and workflows, but we all belong to the larger GNOME community with a common culture based on free software and open collaboration.” Visit [gnome.com/get-involved](https://www.gnome.org/get-involved/) to get started.\n",[675,3043,268],{"slug":3082,"featured":6,"template":679},"welcome-gnome-to-gitlab","content:en-us:blog:welcome-gnome-to-gitlab.yml","Welcome Gnome To Gitlab","en-us/blog/welcome-gnome-to-gitlab.yml","en-us/blog/welcome-gnome-to-gitlab",{"_path":3088,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3089,"content":3094,"config":3101,"_id":3103,"_type":16,"title":3104,"_source":17,"_file":3105,"_stem":3106,"_extension":20},"/en-us/blog/git-not-just-for-developers",{"title":3090,"description":3091,"ogTitle":3090,"ogDescription":3091,"noIndex":6,"ogImage":2582,"ogUrl":3092,"ogSiteName":713,"ogType":714,"canonicalUrls":3092,"schema":3093},"Git: Not just for developers","How one company helps video editors, developers, and project managers to collaborate on interactive video, by leveraging the power of open source.","https://about.gitlab.com/blog/git-not-just-for-developers","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git: Not just for developers\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Opher Vishnia\"},{\"@type\":\"Person\",\"name\":\"Roy Taragan\"}],\n        \"datePublished\": \"2018-05-24\",\n      }",{"title":3090,"description":3091,"authors":3095,"heroImage":2582,"date":3098,"body":3099,"category":14,"tags":3100},[3096,3097],"Opher Vishnia","Roy Taragan","2018-05-24","\nIn this post I’d like to tell you about how, at [Eko](https://helloeko.com/), we’re using GitLab CE to allow professionals from different disciplines, such as video editors, designers, and software engineers, to collaborate on creating and publishing Interactive Video projects using the Eko platform.\n\nEko is a unique company. I know practically every company says that about itself, but for us that’s doubly true in that both our platform as well as our users, and our users of users, take part and actively contribute to creative, experimental ideas and technology. At the core of what we do is an exciting new medium called Interactive Video, which enhances storytelling by bridging the gap between the creator and the viewer. The projects themselves are somewhere between a TV show and a video game. These embody a range of creativity - from the [official music video for Bob Dylan’s “Like a Rolling Stone,”](https://helloeko.com/mindblown/beats-and-rhymes?publisherID=gitlab) through choose-your-own-adventure style comedies and high-caliber movie studio productions like #WarGames.\n\n[![Bob Dylan's Like a Rolling Stone video](https://about.gitlab.com/images/blogimages/eko_mind_blown.png)](https://helloeko.com/mindblown/beats-and-rhymes?publisherID=gitlab)\n\nOur development body creates all the technology for both viewing and authoring these experiences, which are created by small indies as well as big studios and production houses. At the end of the day though, all of these projects, regardless of whether they’re playing on desktop, mobile, or the Xbox, are built with web technologies and run in a browser. Each project is served as a web app, consisting of HTML, JavaScript and CSS files, as well as its video, audio and image assets.\n\nTo create these projects, Eko offers a web-based, drag-and-drop interface called Eko Studio. This software provides project creators with an easy interface for uploading and assembling video, connecting the different videos to each other, creating GUI to define the underlying creativity and finally publishing the finished product.\n\n![Eko Studio](https://about.gitlab.com/images/blogimages/eko-guest-post/eko-studio.png)\n\nIn cases where extra logic and functionality is required, such that isn’t yet covered by the set of features in Eko Studio, we offer the Eko SDK, which enables developers to extend the Studio’s functionality by writing their own custom JS and CSS code.\n\nThe interesting thing about the creation process of our Interactive Video projects is because of their scope and multi-disciplinary nature, different people with different roles all work on the same project at the same time. For example, a video editor might upload a new scene, a project manager would change the SEO copy and a developer might implement new GUI or functionality. One of the challenges we faced at Eko is that all of this needs to be synchronised and shared by all. The experience needs to be fluid and cohesive for all types of users, regardless of their role.\n\n![Eko Studio commits](https://about.gitlab.com/images/blogimages/eko-guest-post/eko-studio-commits.png)\n\n## Using open source to enable collaboration\n\nSo what type of software allows for multiple people to work on the same project without stepping on each other’s toes? Git, of course! With that in mind we set out to find how can we use Git as a backend that could serve our creators, developers and non-developers alike.\n\nIn Eko Studio, users can activate the feature that allows extending a project with code. Behind the scenes, the studio then employs GitLab’s API to create a new repository, generates all the code reflecting the current state of the project, and pushes it as the *initial commit*. From this point forward, each time a preview or published version of the project is generated, the process will begin by first pulling the latest version of the code from the repo. Using GitLab’s webhook for push events combined with Firebase, any time a commit is pushed to the repository, the user in Eko Studio is notified and the UI is updated accordingly. The user in Eko Studio can see all the commits (also fetched using the GitLab API) listed as versions, and can revert to an earlier version.\n\n>The less tech-savvy users aren’t even fully aware that by editing the project or adding content they are in fact publishing commits in the project repo\n\nThe cool thing here though, is that the Eko Studio itself acts as a Git client behind the scenes. The less tech-savvy users aren’t even fully aware that by editing the project or adding content they are in fact publishing commits in the project repo. The studio interface makes this completely transparent for them. Changes to the project made in Eko Studio are translated into Git commits in the project repo. Over on the dev side though, the software engineers use the Git interface itself using their favorite code editor and Git client.\n\n![Eko Studio code panel](https://about.gitlab.com/images/blogimages/eko-guest-post/eko-studio-code-panel.png)\n\nThe fact that GitLab is open source enabled us to custom tailor a solution for our users with minimal changes, leveraging APIs and webhooks to connect our own infrastructure. The readily available AMI meant that we can easily spool up our own GitLab CE instances without a complicated setup process. While our use case is very specific, the fact we’ve been able to use GitLab CE with minimal effort to implement our platform and tools for creating Interactive Video definitely highlights the flexibility and capabilities of GitLab!\n",[699,864,675],{"slug":3102,"featured":6,"template":679},"git-not-just-for-developers","content:en-us:blog:git-not-just-for-developers.yml","Git Not Just For Developers","en-us/blog/git-not-just-for-developers.yml","en-us/blog/git-not-just-for-developers",{"_path":3108,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3109,"content":3114,"config":3120,"_id":3122,"_type":16,"title":3123,"_source":17,"_file":3124,"_stem":3125,"_extension":20},"/en-us/blog/contribute-to-open-source-land-jobs",{"title":3110,"description":3111,"ogTitle":3110,"ogDescription":3111,"noIndex":6,"ogImage":1425,"ogUrl":3112,"ogSiteName":713,"ogType":714,"canonicalUrls":3112,"schema":3113},"How contributing to open source can help you land your first job","Six compelling reasons why, warm fuzzy feelings aside, contributing to open source is good for your career.","https://about.gitlab.com/blog/contribute-to-open-source-land-jobs","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How contributing to open source can help you land your first job\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ariel Camus\"}],\n        \"datePublished\": \"2018-04-06\",\n      }",{"title":3110,"description":3111,"authors":3115,"heroImage":1425,"date":3117,"body":3118,"category":14,"tags":3119},[3116],"Ariel Camus","2018-04-06","\n\nContributing to open source can significantly boost your chances of getting a job. And even\nthough this is true for all developers, regardless of their level of experience, it's especially\nimportant for entry-level ones.\n\nLet me make this perfectly clear: **contributing to open source is the most effective job-seeking\n hack you can take advantage of right now**.\n\nEven better, by contributing to open source you won't only improve your chances\nof getting a job, but you will also give back to the community, meet amazing and talented\npeople, and feel incredibly accomplished when your first contribution gets accepted.\n\nAt [Microverse](https://www.microverse.org/), the company I founded, we train remote software developers from all around\n the world, and we ask them to contribute to open source, starting from their first day in the program.\n\n**Here are six reasons why contributing to open source will help you too.**\n\n## Reason 1: Work as part of a (distributed) team\n\nWhen looking for a job, experience counts. However, experience limited to coding and the\nlanguage syntax is not enough. You need to know how to work as part of a team,\ncollaborating with others to build large and complex applications.\n\n**How do you get that kind of collaborative and at-scale experience if you can't get a job first?**\nThe answer is open source.\n\nLarge, open source projects are almost always built by a large team. Sometimes the people in\nthose teams even work for large organizations (e.g. GitLab, React/Facebook, etc.). By\nbecoming a contributor you get the chance to **work with those exceptional teams without\nhaving to be hired by those companies**.\n\nYou will sharpen your written communication skills, understand how to pick and negotiate\nthings to work on, perfect your Git Flow/[GitLab Flow](https://docs.gitlab.com/ee/topics/gitlab_flow.html), and many other things that are as\nvaluable as understanding the language syntax.\n\n## Reason 2: Work in a complex and large application\n\nIf you join a company, you will most likely work on an existing application. And, probably, it\nwill be a large and complex one. As a coding student you rarely have the chance to do that,\nbut when you join an open source project, that's exactly the scenario that you will face.\n\nYou will first need to **set up your local development environment** following the contributing\nguidelines provided by the project. You will then start by **refactoring existing code** to correct\ntypos and fix small bugs, the same way you would at a regular job! Finally, you will start\nunderstanding how all the **pieces** of a large application fit together, how it was **architected**,\nand where the code for each **functionality** lives.\n\nThese are not things you could experience working on small learning projects, but you need\nthis kind of experience if you want to land a job.\n\n## Reason 3: Get a lot of good feedback\n\nEvery time you pick an open source issue to work on, you will start by forking the project\nand creating a feature branch. You will write tests and code until you are happy with your\nsolution, and then submit a merge request to the original code.\n\nHowever, this is just the first step in the process. One of the main developers at the project\nwill review your merge request and will tell you if it's ready to be merged. Most likely it won't.\n But that's fine, because **she will also provide feedback about what you need to fix before\n your code can be merged**.\n\nCan you imagine getting this kind of direct feedback from a seasoned developer at GitLab or\nFacebook? Think about it… they really want your help, but they also need to keep the quality\nof the code at a high level. They will help you, and you will end up learning a lot in the process.\n\n## Reason 4: Build an online reputation\n\nGetting experience working as part of a team and contributing to large and complex applications\nis really important, but it won't help you land a job unless companies can find you and want to interview you.\n\nContributing to open source will help you with that too. After quickly reading your resume,\nemployers will want to find you online, and they will want to see your code. **GitLab and\nGitHub profiles are the new resumes**.\n\nIf employers can see that you are an active member of large open source projects, that will\ntell them something else that is very important: software is not just what you do for a living,\nbut it's also your passion and hence what you do in your free time.\n\nWhat do employers currently find when they search your name on Google? Open source will\nmake you look great!\n\n## Reason 5: Network with the community\n\nOpen source projects often have large organizations behind them who are constantly hiring\nnew developers. Wouldn't it be great for those organizations if they could hire people who\nlove their product? What if their new hires knew the product so well already that they could\nbe productive contributors from the moment they join the company?\n\nWell, that's exactly the value you offer as an active member of an open source community.\n**You know the product, you know the code, and the people behind the project know you.\nChances are that you will eventually be offered to work for them**. In fact, almost\na third of the first 40 engineers that GitLab hired were contributors to its codebase first.\n\n## Reason 6: Stay motivated\n\nLast, but not least, we all know the single and most important advice to be successful at anything\nis perseverance. However, staying motivated and focused while learning to code and applying\nfor jobs is not easy. There are a lot of things to learn, a lot of different paths to take, and many\nrejections on the path to landing your first job.\n\nJoining an open source project will give you the real-world encouragement and a community\n to support you throughout the journey.\n\nAre you convinced that contributing to open source is the best thing you can do right now to\nhelp you on your way to landing your first job? I'm pretty sure you are. Go ahead and [start now](/community/contribute/)!\n\n### About the guest author\n\n[Ariel Camus](https://twitter.com/arielcamus) is the founder of [Microverse](https://www.microverse.org/),\na company finding the world's untapped talent and training it to become remote software developers. Ariel was previously the co-founder and CEO\nof TouristEye, a travel startup that he grew to a million users and sold to Lonely Planet in 2013.\n\nCover photo by [Maik Jonietz](https://unsplash.com/@der_maik_?utm_source=medium&utm_medium=referral) on [Unsplash](https://unsplash.com?utm_source=medium&utm_medium=referral)\n{: .note}\n",[268,2023,675],{"slug":3121,"featured":6,"template":679},"contribute-to-open-source-land-jobs","content:en-us:blog:contribute-to-open-source-land-jobs.yml","Contribute To Open Source Land Jobs","en-us/blog/contribute-to-open-source-land-jobs.yml","en-us/blog/contribute-to-open-source-land-jobs",{"_path":3127,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3128,"content":3133,"config":3139,"_id":3141,"_type":16,"title":3142,"_source":17,"_file":3143,"_stem":3144,"_extension":20},"/en-us/blog/an-agile-approach-to-documentation-and-structure",{"title":3129,"description":3130,"ogTitle":3129,"ogDescription":3130,"noIndex":6,"ogImage":2582,"ogUrl":3131,"ogSiteName":713,"ogType":714,"canonicalUrls":3131,"schema":3132},"An Agile approach to documentation and structure","Combining flexibility and structure: why we decided to use GitLab.com for all UnscrewMe documentation and code to keep an overview, always find the relevant information quickly, and easily track progress.","https://about.gitlab.com/blog/an-agile-approach-to-documentation-and-structure","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"An Agile approach to documentation and structure\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Goetz Buerkle\"}],\n        \"datePublished\": \"2017-12-13\",\n      }",{"title":3129,"description":3130,"authors":3134,"heroImage":2582,"date":3136,"body":3137,"category":14,"tags":3138},[3135],"Goetz Buerkle","2017-12-13","\n\nWith an idea and a name, I was ready to start working more seriously on\n[UnscrewMe](http://unscrewme.co.uk/), a simple wine tasting scheduler app. Well, almost ready – to avoid ending up with a\nmess of files and folders and stuff scattered across different devices, and\ncertainly never where I need them, my next objective was to set up a central\nlocation where I could store and organize everything flexibly.\n\n\u003C!-- more -->\n\n## GitLab – selecting simple tools\n\nI wanted to keep the overhead low and the management of the documents simple,\nyet extensible enough to cover everything I would need to get started, including\nsimple lists, longer notes, logo drafts, and also more structured technical\nconcepts and even invoices.\n\nBeing a [Certified Scrum Product Owner](https://www.scrumalliance.org/certifications/practitioners/cspo-certification) and using a [GitLab](/) instance at work, I decided to take advantage of the free private repositories and use GitLab.com for UnscrewMe. This combines the simplicity of “just” storing everything in files and folders, with the advantage of being able to use Markdown for more advanced formatting, including sub headings, nested lists and images. And all information can easily be accessed on any device, either via Git directly or the GitLab.com web interface, which also renders Markdown files nicely.\n\nIn addition, project management features of GitLab like [issues](https://docs.gitlab.com/ee/user/project/issues/), [milestones](https://docs.gitlab.com/ee/user/project/milestones/) and\n[Issue Boards](/stages-devops-lifecycle/issueboard/) would provide a useful, flexible and lightweight framework to\ntrack my progress. By defining project phases and grouping all open tasks in\nvarious ways, I could get a quick overview of what I would need to do next,\nbefore I could actually launch my Minimum Viable Product (MVP).\nUsing the full power of GitLab.com, I created a “[Group](https://docs.gitlab.com/ee/user/group/index.html)” and three separate\nrepositories: one for all the general documentation, one for the actual web\napplication, and a third for the pre-launch website.\n\n## Defining a flexible structure\n\nYou could of course call my folder structure flawed, as it is not always entirely\nclear where new content or document should go, but so far it works fine for me.\nI started with a high-level view and specified six broad areas:\n* ideas – for anything largely creative\n* concepts – for more detailed specifications and drafts\n* business – for business plans and similar documents focused on the business in general\n* roadmap – to define the main steps without immediately looking at all the details\n* design – basically, everything that is not text\n* finance – for invoices, contracts, etc.\n\nThese six folders give me enough structure and flexibility to get started,\nwithout having to think too hard about what should go where.\nA couple of years ago, I started prepending most files I create with dates,\nlike “2017–08–31\". I find that adding dates are a useful primary sorting\ncriteria when trying to get a quick overview, so I stuck with this approach for\nmy new project as well, even though it might not be the perfect match for all files.\n\n## Google Keep – enabling quick, low-barrier content generation\n\nWith a system mainly based on text files, I could use any editor. As I started\nusing [Google Keep](https://www.google.com/keep/) for personal notes a few\nmonths ago, I knew that it was flexible and reliable enough for my needs.\n\nI do have a subscription for a very stripped-down text editor, but I must admit,\nthat I don’t like the barely existing interface too much, and started using\nGoogle Keep for many tasks instead. The big benefit of Google Keep, above the\nother web services I used to rely on for writing, is the support of writing\nnotes offline. While these days you mostly have 4G, 3G or wifi anyway, even on\nholiday, I did find myself sometimes at events or in places without connectivity.\nAnd then, being able to write something offline, that would automatically be\nsynchronized as soon as I would be online again, proved rather useful.\n\nThe only obvious drawback for me now is, that Google Keep does not support\nMarkdown for structure and formatting. But as Markdown markup is pretty minimal\nand easy to read, this hasn’t been much of a limitation.\n\nThe notes editor is simple and fast – I do not really need anything more\nadvanced or complicated. What I do value though it the possibility to add labels,\njust a different name for tags, and colors to notes. That way I can easily\ngroup my project notes together and even find the ones I am looking for quickly\nin my main view.\n\n## Visual Studio Code – lightweight editing with Markdown preview and Git support\n\nTo get my basic notes from Google Keep into GitLab, I used [Visual Studio Code](https://code.visualstudio.com/).\nIt is a simple editor with many useful plugins, making editing and checking\nMarkdown documents very convenient and supporting Git out of the box, which was\npretty much all I needed.\n\nOften, my Google Keep notes require just a little bit of cleanup, before they\nare ready to be committed to the Git repository.\nAs I use GitLab milestones and issues to structure all the work, I could also\ntake advantage of this when adding documents to the Git repository and making\nchanges. So I also reference the relevant issues in my commit messages using\n[GitLab Flavored Markdown](https://docs.gitlab.com/ee/user/markdown.html#gitlab-flavored-markdown-gfm) syntax.\n\nNext on my todo list was to [create a simple pre-launch website](https://medium.com/unscrewme/claiming-the-name-257b59d979b)\nto announce the new service, even before it was built. I did read a few times\nthat building a pre-launch website before starting to work on the application\ncode can help to gauge if there even is enough interest for the product. In my\ncase, I was not too concerned about this aspect, since first and foremost, I\nwanted to use my service, therefore by definition it would be worth the effort.\n\n*(I began writing this overview at [Pantry Marylebone](https://www.pantrymarylebone.com/)\nand finished it there too, a few days later. I wrote the final paragraphs there\nafter having had three wines at [108 Brasserie](http://108brasserie.com/) before:\na beautiful and well-balanced 2016 Picpoul de Pinet from Domaine Felines Jourdan\nin Languedoc in France, a surprisingly light and smooth 2016 Montepulciano\nd’Abruzzo from Il Faggio in Italy and a somewhat harsh and slightly disappointing\n2016 Beaujolais Vieilles Vignes par Vincent Fontaine from Domaine de la Rocailler, in France.)*\n\n## About the Guest Author\n\nGoetz Buerkle is currently working to launch UnscrewMe. There are so many wine\ntastings happening in London every day – UnscrewMe wants to help Londoners spend\nless time searching for wine events and more time tasting interesting wines\ninstead. [Keep up with the project](http://unscrewme.co.uk/).\n\n\n*[An Agile approach to documentation and structure](https://medium.com/unscrewme/an-agile-approach-to-documentation-and-structure-5fe4a14a6f2f) was originally published on Medium.*\n",[2107,675,1583],{"slug":3140,"featured":6,"template":679},"an-agile-approach-to-documentation-and-structure","content:en-us:blog:an-agile-approach-to-documentation-and-structure.yml","An Agile Approach To Documentation And Structure","en-us/blog/an-agile-approach-to-documentation-and-structure.yml","en-us/blog/an-agile-approach-to-documentation-and-structure",{"_path":3146,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3147,"content":3153,"config":3160,"_id":3162,"_type":16,"title":3163,"_source":17,"_file":3164,"_stem":3165,"_extension":20},"/en-us/blog/collaborative-course-environment-gitlab-grav",{"title":3148,"description":3149,"ogTitle":3148,"ogDescription":3149,"noIndex":6,"ogImage":3150,"ogUrl":3151,"ogSiteName":713,"ogType":714,"canonicalUrls":3151,"schema":3152},"Creating open course environments with GitLab and Grav CMS","Guest author Paul Hibbitts shares how he combines GitLab with the flat-file CMS Grav to provide an open, collaborative and flexible environment that partners with his institution's LMS.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678561/Blog/Hero%20Images/open-course-environment.jpg","https://about.gitlab.com/blog/collaborative-course-environment-gitlab-grav","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Enabling an open and collaborative course environment with GitLab and the Grav CMS\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Paul Hibbitts\"}],\n        \"datePublished\": \"2017-10-12\",\n      }",{"title":3154,"description":3149,"authors":3155,"heroImage":3150,"date":3157,"body":3158,"category":14,"tags":3159},"Enabling an open and collaborative course environment with GitLab and the Grav CMS",[3156],"Paul Hibbitts","2017-10-12","\n\nTech-savvy educators! Do you want to:\n\n- Share your course materials more openly?\n- Support collaborative editing by students and fellow educators?\n- Deliver a better multi-device experience of your course materials?\n- Be able to update your online course materials in as little as 30 seconds?\n- And, in general, move beyond the constraints of your current Learning Management System?\n\n\u003C!-- more -->\n\nIf this sounds like you, then the combination of an institutionally hosted instance of [GitLab]() and a modern flat-file (no database) Content Management System such as [Grav](https://getgrav.org/) might be your answer!\n\nAs an educator and software interaction designer, I am always striving to deliver a better experience for my students, both in person and online. In the past several years this has led me to ‘flipping’ the Learning Management System, where I use an alternative platform instead of the LMS as the primary online environment. Many instructors (including myself) have taken this approach in the past using a traditional platform such as WordPress, but I found significant new benefits from partnering the LMS with a more modern platform that was built to take full advantage of the open and collaborative ecosystem (i.e. Git, GitLab, GitHub, etc.) we now have.\n\nWith the above approach, direct links are provided to any appropriate LMS elements and sensitive student data remains in the LMS. Common elements across multiple courses, like calendars, assignments, discussion forums, and grades are still stored in the LMS for single-point access by students. While perhaps not suited for university-wide adoption, this is a very viable and productive approach for individual instructors and their students while we wait for more open and adaptable institutional-level tools to become available.\n\n\u003Cimg src=\"/images/blogimages/gitlab-grav-open-course1.png\" alt=\"Open and Collaborative Flipped LMS Approach Using GitLab and the Grav CMS\" style=\"width: 500px;\"/>{: .shadow}\n\n*\u003Csmall>Open and Collaborative ‘Flipped’ LMS Approach Using GitLab and the Grav CMS\u003C/small>*\n\nFortunately, my university ([Simon Fraser University](http://www.sfu.ca/), or SFU, in Burnaby, BC, Canada) also provides an institutionally hosted instance of GitLab which not only gives me an ideal workspace for my online course materials, but also supports single sign-on so my students can easily contribute to these materials as well. By combining GitLab with the modern flat-file CMS Grav, my institution's LMS and a small collection of other open source web apps, I’ve been able to reach more of my desired teaching goals (such as providing an anytime, anywhere performance support tool with real-time chat) for my own courses than by using the LMS as the primary online space. In addition, I’ve made the resulting software open source to also help other instructors reach their own goals – more about this project at the end of this article!\n\n## Why open source software?\n\nThe advantages of using open source software in the field of education are well documented elsewhere (see [Open Source Software in Education](http://er.educause.edu/articles/2008/5/open-source-software-in-education)), but from my own viewpoint, the things I value most are: having more control over the software I use, the online communities often found with open software projects, public communication with the team developing the software, and the wide range of ways I can contribute to projects. I’ve also been keenly following several other open source, institutional-level learning ecosystem efforts, such as [ELMSLN](https://www.elmsln.org/) (a platform for building and sustaining innovation in course technologies) and [TSUGI](https://www.tsugi.org/) (a framework for building learning tools).\n\n## Why GitLab?\n\nGitLab meets several key criteria for its use in a learning ecosystem. First, it is open source software itself and secondly, it is possible to install an instance of GitLab on your own server. For universities and colleges this enhances the benefits of being open source in the first place as single sign-on and the storage of sensitive student data remains in the sole control of the institution.\n\nUsing GitLab in combination with the [GitHub Desktop application](https://desktop.github.com/) I can also very quickly update my online course sites from my desktop, while at the same time being able to then edit course site materials with any code editor I like. Most importantly, students feel like active course participants when they see they are welcome to suggest changes to the course site, or even just to make corrections to course materials. Everything is of course version controlled, which means as a repository administrator I can easily see each and every change before approving them. For changes not immediately approved I can then start a discussion via GitLab with the author of the proposed change to work out any needed further changes, etc. GitLab brings an industrial-strength software and document collaboration tool into the reach of my fellow university colleagues and students.\n\n## Why Grav CMS?\n\nWhile looking for an open source platform to support a learning ecosystem I evaluated multiple options, including self-hosting (for full administrative control) WordPress, Concrete5, Moodle and others. I then came across a number of apps under the category of ‘flat-file CMS,’ meaning that content was stored in files instead of a database. I could see that content as files would be a perfect partner for using a web-based Git service (such as GitLab, [GitHub](https://www.github.com/), [GitBook](https://www.gitbook.com/), etc.) to share and collaboratively edit content. With such a partnership, CMS content can be automatically backed up in a straightforward manner, while also tracking all revisions along the way. Digging deeper, I discovered the open source flat-file CMS Grav (by the team behind [RocketTheme](http://www.rockettheme.com/)) used Markdown – the native format for Web-based Git services such as GitLab – for content. Markdown is also an excellent system-independent format to support the ‘5Rs’ of Open Education Resources (Retain, Reuse, Revise, Remix, and Redistribute).\n\n\u003Cimg src=\"/images/blogimages/gitlab-grav-open-course2.png\" alt=\"Editing Markdown content in the Grav CMS Admin Panel\" style=\"width: 500px;\"/>{: .shadow}\n\n*\u003Csmall>Editing Markdown content in the Grav CMS Admin Panel\u003C/small>*\n\nGrav uses many existing modern standards and open source components, such as the very user-friendly [Twig language](https://twig.symfony.com/) (courtesy of Symfony) instead of pure PHP for theme templating. Grav also supports modular and custom content types, and was designed from the ground-up to be both fast and extensible. In addition, with the creation of the open source Git Sync plugin (by [Trilby Media](https://trilby.media/)) it is now easier than ever to do two-way syncing of Grav content between a production server, Git repository and an optional local development instance. It is even  possible to sync theme files, which determine the actual functionality and presentation of a site, so  educators (or perhaps their tech-savvy students) can directly help other educators needing assistance in additional customization of their Grav sites.\n\nIt should be noted that Grav is not a static site generator, but rather a file-based CMS which supports not only dynamic content but also an online Admin Panel.\n\n## CMPT-363 Open Course Hub\n\nFor my SFU course CMPT-363 User Interface Design this Fall, I will not only be using GitLab and Grav (hosted on the educationally focused [Reclaim Hosting](https://reclaimhosting.com/)), but also a number of other web apps (also mostly open source) to provide a learning ecosystem to my students. Since Grav itself is open and extensible, I can easily add in Javascript elements for a Livechat (which my students have told me they love) thanks to [Rocket.Chat](https://rocket.chat/), responsive Markdown-based slide embeds thanks to the commercial [Swipe.to](https://www.swipe.to/home) web app, and links to an anonymous course feedback form thanks to [Sandstorm.IO](https://sandstorm.io/) and [Quick Survey](https://github.com/simonv3/quick-survey). To address both various other teaching goals (the LMS actually does some things quite reasonably) and student data privacy concerns, I still use the institutional LMS [Canvas](https://www.canvaslms.com/) by Instructure to support a wide range of course elements such as quizzes, assignment submissions, discussion forums, and gradebook. You can see this multi-device friendly Course Hub in action at [paulhibbitts.net/cmpt-363-173/](http://paulhibbitts.net/cmpt-363-173/).\n\n\u003Cimg src=\"/images/blogimages/gitlab-grav-open-course3.png\" alt=\"CMPT-363 Open Course Hub Learning Ecosystem\" style=\"width: 500px;\"/>{: .shadow}\n\n*\u003Csmall>CMPT-363 Open Course Hub Learning Ecosystem\u003C/small>*\n\n## The Open Course Hub Project\n\nBased on the [very positive student feedback](https://storify.com/paulhibbitts/flipped-lms) and my own experiences with the 2015 CMPT-363 Course Hub, I decided to release an open source version of a pre-packaged Course Hub with Git Sync the following year (called a Skeleton in Grav-speak, which is a ready-to-run package that includes Grav and all needed theme and example content files). While this package can be installed in [less than a minute](https://www.youtube.com/watch?v=8yyE-LaAa8Y) and fully configured in [under five minutes](https://www.youtube.com/watch?v=jnBig4aGfFg) it is intended for fellow tech-savvy educators to use and further customize as they see fit.\n\n\u003Cimg src=\"/images/blogimages/gitlab-grav-open-course4.png\" alt=\"CMPT-363 Open Course Hub Web Page\" style=\"width: 500px;\"/>{: .shadow}\n\n*\u003Csmall>CMPT-363 Open Course Hub Web Page\u003C/small>*\n\nWhat are the exact skills currently expected? In general, you should be comfortable with accessing files on a website server, understand folder hierarchies, be familiar with Markdown (here is a [10-minute Markdown tutorial](https://designedbywaldo.com/en/tools/markdown-tutorial)), and have a working knowledge of using GitLab or GitHub. Being able to use [GitHub Desktop](https://desktop.github.com/) and a desktop code editor like [Atom.io](https://atom.io/) or [Adobe Brackets](http://brackets.io/) will also bring the ability to store a copy of your Grav site content on your local desktop and then selectively edit and push changes back to the Git repository for deployment to your live Grav Course Hub site. Step-by-step install and configuration instructions for the Grav Course Hub are available at [learn.hibbittsdesign.org/coursehub](http://learn.hibbittsdesign.org/coursehub).\n\nThis is also my way to give back to the open source community in general, which has been so helpful in the development of my own original CMPT-363 Course Hub. Using Grav and the Git Sync plugin I’ve released several additional Open Education Resources (OER) projects, including the Open Publishing Space, and all of these are available at [learn.hibbittsdesign.org](http://learn.hibbittsdesign.org/).\n\nQuestions or comments about using GitLab as an open and collaborative backbone to your learning ecosystem? Please feel free to contact me via email ([paul@hibbittsdesign.org](mailto:paul@hibbittsdesign.org)) or Twitter [@hibbittsdesign](https://twitter.com/hibbittsdesign). You can also read more about my learning ecosystem explorations at [hibbittsdesign.org/blog](http://www.hibbittsdesign.org/blog/).\n\n*Special thanks to the folks at GitLab for the kind offer to provide this guest blog post, and everyone from the Grav community and my Twitter network who provided helpful feedback and comments on the draft versions of this post!*\n\n### About the guest author\n\nPaul Hibbitts has been an interaction design practitioner and educator for over 20 years, and has recently ventured into the world of open source software development thanks to the amazing Grav CMS.\n\n\n[Cover image](https://unsplash.com/photos/Y94yKEyNjVw) by [chuttersnap](https://unsplash.com/@chuttersnap) on unsplash\n{: .note}\n",[675,864],{"slug":3161,"featured":6,"template":679},"collaborative-course-environment-gitlab-grav","content:en-us:blog:collaborative-course-environment-gitlab-grav.yml","Collaborative Course Environment Gitlab Grav","en-us/blog/collaborative-course-environment-gitlab-grav.yml","en-us/blog/collaborative-course-environment-gitlab-grav",{"_path":3167,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3168,"content":3174,"config":3179,"_id":3181,"_type":16,"title":3182,"_source":17,"_file":3183,"_stem":3184,"_extension":20},"/en-us/blog/gitlab-fan-profile",{"title":3169,"description":3170,"ogTitle":3169,"ogDescription":3170,"noIndex":6,"ogImage":3171,"ogUrl":3172,"ogSiteName":713,"ogType":714,"canonicalUrls":3172,"schema":3173},"Today is GitLab Fan Day","Join us in celebrating our most mysterious evangelist, GitLab Fan.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671316/Blog/Hero%20Images/gitlab-fan-day.png","https://about.gitlab.com/blog/gitlab-fan-profile","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Today is GitLab Fan Day\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2017-09-07\",\n      }",{"title":3169,"description":3170,"authors":3175,"heroImage":3171,"date":3176,"body":3177,"category":14,"tags":3178},[2966],"2017-09-07","\n\nToday we're celebrating [GitLab Fan](https://gitlabfan.com/) and the great work they do to evangelize GitLab 🎉 Read on to learn more about the mysterious figure behind the Fan, and take a look around [our site](/) and see if you can spot any of their illustrations. Also, don't forget to visit us on Twitter to take part in our giveaway – you could get your hands on some awesome, custom GitLab Fan swag.  \n\n\u003C!-- more -->\n\nAt GitLab we're passionate about building a platform where everyone can contribute, and GitLab Fan is a great example of the work our community does, from creating [custom stickers for Telegram and Slack](https://gitlabfan.com/gitlab-stickers-for-telegram-and-slack-16639b2c126) to sharing [tutorials](https://gitlabfan.com/setting-up-your-own-fully-functional-gitlab-https-registry-ci-runners-79901ac617c0) and [takeaways from our culture](https://gitlabfan.com/7-examples-of-extreme-transparency-of-gitlab-e257796c9ef4).\n\nWhile GF's identity remains a mystery (Honest! If they're a GitLab team-member, they're undercover 🕵️), we did get a chance to ask them some questions:\n\n### What inspired you to launch GitLabFan.com?\n\nI used to work with GitLab a lot and I liked it, so I had a lot of thoughts I wanted to share with people.\n\n### Do you use GitLab for work or personal projects (or both)?\n\nMostly personal projects these days.\n\n### What kind of work do you do?\n\nI teach junior developers. By the way, I've started to work on [a course about GitLab CI](https://www.indiegogo.com/projects/learn-continuous-integration-with-gitlab-ci#/) ;)\n\n### Do you work for GitLab? (We have to ask!)\n\nNo, I don't :)\n\n### Have you ever thought about applying to work for GitLab?\n\nYup, I actually did that. But it was not a very serious intention, I did that for fun. Twice :)\n\n### If you could change or improve anything about GitLab, what would it be and why?\n\nI would love to see a built-in chat solution, in the same way that GitLab has built-in CI. That will save some time when you set up a new project, and I am also sure there would be some nice synergistic effects.\n\n**Thanks, GitLab Fan, for everything you do.**\n\n*We're giving away some specially designed GitLab Fan swag over on [Twitter](https://twitter.com/gitlab) – head there now to join in!*\n",[268,675],{"slug":3180,"featured":6,"template":679},"gitlab-fan-profile","content:en-us:blog:gitlab-fan-profile.yml","Gitlab Fan Profile","en-us/blog/gitlab-fan-profile.yml","en-us/blog/gitlab-fan-profile",{"_path":3186,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3187,"content":3193,"config":3199,"_id":3201,"_type":16,"title":3202,"_source":17,"_file":3203,"_stem":3204,"_extension":20},"/en-us/blog/gitlab-and-reproducibility",{"title":3188,"description":3189,"ogTitle":3188,"ogDescription":3189,"noIndex":6,"ogImage":3190,"ogUrl":3191,"ogSiteName":713,"ogType":714,"canonicalUrls":3191,"schema":3192},"How GitLab can help in research reproducibility","NYU reproducibility librarian Vicky Steeves shares why GitLab is her choice for ongoing collaborative research, and how it can help overcome challenges with sharing code in academia.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749672928/Blog/Hero%20Images/gitlab-and-reproducibility.jpg","https://about.gitlab.com/blog/gitlab-and-reproducibility","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab can help in research reproducibility\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vicky Steeves\"}],\n        \"datePublished\": \"2017-08-25\",\n      }",{"title":3188,"description":3189,"authors":3194,"heroImage":3190,"date":3196,"body":3197,"category":14,"tags":3198},[3195],"Vicky Steeves","2017-08-25","\nGitLab is a great platform for active, ongoing, collaborative research. It enables folks to work together easily and share that work in the open. This is especially poignant given the problems in sharing code in academia, across time and people.\n\n\u003C!-- more -->\n\n![phd-code-comic](https://phdcomics.com/comics/archive/phd031214s.gif)\n\nIt's no surprise that GitLab, a platform for collaborative coding and Git repository hosting, has features for reproducibility that researchers can leverage for their own and their communities’ benefit.\n\n### What exactly is reproducibility?\n\nReproducibility is a core component in a variety of work, from software engineering to research. For software engineers, the ability to reproduce errors or functionality is key to development. For researchers, reproducibility is about independent verification of results/methods, to build on top of previous work, and to increase the impact, visibility, and quality of research. Y’know. That Sir Isaac Newton quote in every reproducibility presentation ever: \"If I have seen further, it is by standing on the shoulders of giants.\"\n\nLike all things, reproducibility exists on a spectrum. I like Stodden et al’s definitions from the [2013 ICERM report](http://stodden.net/icerm_report.pdf), so I’ll use those:\n\n| ICERM Report Definitions | Potential Real-World Examples |\n|:-----------------------------------------------------------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------|\n| Reviewable Research: Sufficient detail for peer review and assessment                            | The code and data are openly available |\n| Replicable Research: Tools are available to duplicate the author’s results using their data    | The tools (software) used in the analysis are freely available for others to confirm results                                   |\n| Confirmable Research: Main conclusions can be attained independently without author’s software | Others can reach the conclusion using similar tools, not necessarily the same as the author, or on a different operating system |\n| Auditable Research: Process and tools archived such that it can be defended later if necessary   | The tools, environment, data, and code are put into a preservation-ready format                                                |\n| Open/Reproducible Research: Auditable research made openly available                           | Everything above is made available in a repository for others to examine and use                                               |\n\nThe last bullet there is the goal – open and reproducible research. Releasing code and data are key to open research, but not necessarily enough for reproducibility. This is where the concept of computational reproducibility becomes important, where whole environments are captured. You could also look at it this way:\n\n![reproducibility-pyramid](https://osf.io/8rx9y/download)\n\n### How can GitLab help?\n\nThere are a few solutions out there, including containers (such as Docker or Singularity) for active research, and [o2r](http://o2r.info/) and [ReproZip](https://reprozip.org) for capturing and reproducing completed research. For this post, I’m going to focus on active research and containers.\n\nI like GitLab for research reproducibility because it makes working together simple, and seamless. There’s no hacking together 100 different third-party services. GitLab has hosting, LFS, and integrated Continuous Integration for free, for both public and private repositories! Everything is integrated in a single GitLab repository which, if made publicly available, can enable secondary users to reproduce results in a more streamlined fashion. You can also keep these private to a group – you control the visibility of everything in one repository in one place, as opposed to updating permissions across multiple services.\n\nThere are a few key features that set GitLab apart when it comes to containers and reproducibility. The first is that GitLab doesn’t use a third-party service for continuous integration. It’s shipped with CI runners which can use Docker images from GitLab’s registry. Basically, you can use the Docker Container Registry, a secure, private Docker registry, to choose a container that GitLab CI uses to run each job in a separate and isolated container.\n\n![gitlab-ci-repro](https://about.gitlab.com/images/ci/arch-1.jpg)\n\nIf you don’t feel like using the GitLab registry, you can also use images from DockerHub or a custom Docker container you’re already using locally. These can be integrated with GitLab CI, and if made public, any secondary users can use it as well!\n\n### Let's look at an example\n\nThis process is set up in a single file, a `.gitlab-ci.yml`. Another feature that makes my life easier – GitLab can syntax-check the CI config files! The `.gitlab-ci.yml` file describes the pipelines and stages, each of which has a different function and can have its own tags, produce its own artifacts, and reuse artifacts from other stages. These stages can also run in parallel if needed. Here’s an example of what a basic config file looks like with R:\n\n```\nimage: jangorecki/r-base-dev\ntest:\n  script:\n    - R CMD build . --no-build-vignettes --no-manual\n    - PKG_FILE_NAME=$(ls -1t *.tar.gz | head -n 1)\n    - R CMD check \"${PKG_FILE_NAME}\" --no-build-vignettes --no-manual --as-cran\n```\n\nAnd here’s an example of building a website using the GitLab and the static site generator, Nikola:\n\n```\nimage: registry.gitlab.com/paddy-hack/nikola:7.8.7\ntest:\n  script:\n  - nikola build\n  except:\n  - master\n\npages:\n  script:\n    - nikola build\n  artifacts:\n    paths:\n    - public\n  only:\n  - master\n```\n\nIt’s also worth noting that you can use different containers per step in your workflow, if you outline it in your .gitlab-ci.yml. If your data collection script runs in one environment but your analysis script needs another, that’s perfectly fine using GitLab, and others have the information to reproduce it easily! Another feature that puts GitLab apart is that a build of one project can trigger a build of another – AKA, multi-project pipelines. For those of you working with big data, you can automatically spin up and down VMs to make sure your builds get processed immediately with GitLab’s CI as well.\n\nHere are some other great resources and examples of using GitLab to make research more reproducible:\n\n+ [Gitlab-CI for R packages](https://gitlab.com/jangorecki/r.gitlab.ci)\n+ [Blog Post explaining GitLab + reproducibility - Jon Zelner](http://www.jonzelner.net/statistics/make/docker/reproducibility/2016/05/31/reproducibility-pt-1/)\n+ [GitLab repo accompanying blog post - Jon Zelner](https://gitlab.com/jzelner/reproducible-stan)\n+ [Continuous Integration with Gitlab - Tony Wildish](https://www.nersc.gov/assets/Uploads/2017-02-06-Gitlab-CI.pdf)\n\nBeyond reproducibility, there are a lot of features that make GitLab an ideal place for me to work and organize my research. I’d urge folks to look at the [feature list](/pricing/feature-comparison/) and see how they can get started!\n\n## About the Guest Author\n\nVicky Steeves is the Librarian for Research Data Management and Reproducibility at New York University, a dual appointment between the Division of Libraries and Center for Data Science. In this role, she works supporting researchers in creating well-managed, high quality, and reproducible research through facilitating use of tools such as ReproZip. Her research centers on integrating reproducible practices into the research workflow, advocating openness in all facets of scholarship, and building/contributing to open infrastructure.\n\n“[research](https://www.flickr.com/photos/alovesdc/3464555556/)” by [a loves dc](https://www.flickr.com/photos/alovesdc/) is licensed under [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/legalcode)\n{: .note}\n",[675,864,1583],{"slug":3200,"featured":6,"template":679},"gitlab-and-reproducibility","content:en-us:blog:gitlab-and-reproducibility.yml","Gitlab And Reproducibility","en-us/blog/gitlab-and-reproducibility.yml","en-us/blog/gitlab-and-reproducibility",{"_path":3206,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3207,"content":3213,"config":3219,"_id":3221,"_type":16,"title":3222,"_source":17,"_file":3223,"_stem":3224,"_extension":20},"/en-us/blog/pick-your-brain-interview-jake-stein",{"title":3208,"description":3209,"ogTitle":3208,"ogDescription":3209,"noIndex":6,"ogImage":3210,"ogUrl":3211,"ogSiteName":713,"ogType":714,"canonicalUrls":3211,"schema":3212},"Open source lessons learned: My interview with GitLab’s CEO","Stitch CEO and co-founder Jake Stein sits down for a pick your brain meeting with GitLab CEO Sid Sijbrandij.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680388/Blog/Hero%20Images/pyb-jake-stein.jpg","https://about.gitlab.com/blog/pick-your-brain-interview-jake-stein","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Open source lessons learned: My interview with GitLab’s CEO\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jake Stein\"}],\n        \"datePublished\": \"2017-08-18\",\n      }",{"title":3208,"description":3209,"authors":3214,"heroImage":3210,"date":3216,"body":3217,"category":14,"tags":3218},[3215],"Jake Stein","2017-08-18","\n_GitLab CEO Sid Sijbrandij occasionally sits down for a \"[pick your brain](/handbook/eba/ceo-scheduling/#pick-your-brain-meetings)\"\nmeeting with people seeking advice on open source, remote work, or discussion of other things related to GitLab._\n\nWhen we launched Singer, our [open source ETL project](https://www.singer.io/) at [Stitch](https://www.stitchdata.com/), I was looking for advice on the best strategies to make it successful. August Capital is an investor in both Stitch and GitLab, and they were kind enough to introduce me to Sid Sijbrandij, CEO of GitLab. Sid was very generous with his time, and he shared some of his lessons learned about open source.  \n\n\u003C!-- more -->\n\n## GitLab’s unique approach\n\nAs I explained Stitch to Sid, he asked a few follow up questions, and then shared information about a plan to build up the GitLab analytics stack. I didn’t set up the call intending to sell, but before it was over, he had added us to the publicly accessible page listing the tools that their team plans to evaluate. Their transparency is very impressive, and it eliminates the friction that can slow down a traditional company.\n\n## Open source adoption\n\nVirtually all of GitLab’s paying customers have come from their open source user base. While GitLab has a large sales team, they are primarily focused on converting users to the paid products rather than getting new GitLab users.  \n\nOver 100,000 organizations use GitLab, and their product and engineering teams are responsible for growing that number. One of most important drivers of that growth has been improving the first run experience and time to value.  \n\nWe already had plans to improve the Singer user experience, but Sid encouraged me to take it a step further. The most common use case for Singer, and ETL in general, is pulling data into a database and then visualizing the data. He recommended that we bundle Singer with a PostgreSQL database and an open source visualization tool like Metabase into a easy-to-use package, potentially in a Docker container, which will allow users to get to their end goal much faster.\n\nThis was a really interesting idea that had not occurred to our team before. It motivated us to start thinking more holistically about the goals of our open source users, and I’m confident that this will help us grow adoption of Singer.  \n\n## Open source business model\n\nGitLab started as a free, open source tool and later introduced an enterprise edition and the free SaaS version of GitLab.com. Several years later, in April of 2017, they introduced paid tiers on GitLab.com.\n\nWe’ve taken a very different path with Stitch. We launched with a freemium SaaS service, and subsequently added an enterprise edition of the SaaS product and the free, open source Singer project.  \n\nI thought that the differences in GitLab’s path might have been due to a philosophical decision about business model sequence, but it was much more practical. GitLab started as an open source project, and a business was created around it only after the project had significant traction. In the early days of the business, on-premises was where all of the usage was, so that’s where they started to charge. The original SaaS product was free so it could get traction and build a network effect. As the SaaS product got better, and as the cost of hosting the ever-growing number of SaaS users increased, they launched paid tiers.  \n\nWhile Stitch and GitLab had very different beginnings, our business models have evolved in a similar direction. It was great to get the benefit of the lessons that Sid has learned as we chart our own course.  \n\n## About the Guest Author\n\nJake Stein is the co-founder and CEO of Stitch. Prior to Stitch, Stein was co-founder and COO at RJMetrics, a business intelligence software company that was acquired by Magento in 2016. Before founding RJMetrics, Jake worked at Insight Venture Partners, a software-focused venture capital and private equity firm. He graduated from the Wharton School at the University of Pennsylvania with high honors and concentrations in Finance and Entrepreneurship.\n",[1391,675],{"slug":3220,"featured":6,"template":679},"pick-your-brain-interview-jake-stein","content:en-us:blog:pick-your-brain-interview-jake-stein.yml","Pick Your Brain Interview Jake Stein","en-us/blog/pick-your-brain-interview-jake-stein.yml","en-us/blog/pick-your-brain-interview-jake-stein",{"_path":3226,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3227,"content":3233,"config":3239,"_id":3241,"_type":16,"title":3242,"_source":17,"_file":3243,"_stem":3244,"_extension":20},"/en-us/blog/how-startups-build-it-infrastructure",{"title":3228,"description":3229,"ogTitle":3228,"ogDescription":3229,"noIndex":6,"ogImage":3230,"ogUrl":3231,"ogSiteName":713,"ogType":714,"canonicalUrls":3231,"schema":3232},"A way for startups to build a solid IT infrastructure","Seven free software solutions to cover your most important use cases.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679216/Blog/Hero%20Images/startups-it-infrastructure.jpg","https://about.gitlab.com/blog/how-startups-build-it-infrastructure","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A way for startups to build a solid IT infrastructure\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"plapadoo\"}],\n        \"datePublished\": \"2017-08-07\",\n      }",{"title":3228,"description":3229,"authors":3234,"heroImage":3230,"date":3236,"body":3237,"category":14,"tags":3238},[3235],"plapadoo","2017-08-07","\n\n *plapadoo is a software startup from Hannover, Germany, providing tailored, high-quality software engineering to their clients. They fill us in on how they chose solutions for their IT infrastructure, including communication, backups, [CI/CD](/topics/ci-cd/) and more.*\n\n\u003C!-- more -->\n\nWe recently founded [our company](https://plapadoo.de/) and so one of the first things to do was to get our infrastructure up and running. As a software startup, our technical infrastructure is the heart of our company. It influences our productivity, has impact on our costs and offers a great chance to set us apart from the competition. Having a good infrastructure is also key to saving us money and increasing development speed.\n\nWhen planning the setup of our infrastructure, we kept two things in mind: First, we wanted to have open source software running wherever possible, and second, we wanted to use strong encryption for both communication and data storage. Also, we prefer lightweight software with few dependencies. Below, you find a small list of important use cases and which software we use to cover them:\n\n- [Chat](#chat) ([Matrix](https://matrix.org/)/[Riot](https://about.riot.im/) web app + Android app)\n- [Email](#email) (self-hosted [Dovecot](https://www.dovecot.org/) + [Postfix](http://www.postfix.org/) + [Sieve](http://sieve.info/) + [SpamAssasin](http://spamassassin.apache.org/))\n- [Calendar and Contacts](#calendar-and-contacts) ([Radicale](http://radicale.org/))\n- [Voice Conferencing](#voice-conferencing) ([uMurmur](http://umurmur.net/)/[Mumble](https://wiki.mumble.info/))\n- [Synchronization of files across multiple devices](#data-storage) ([Syncthing](https://syncthing.net/))\n- [Git and Continuous Integration](#build-and-continuous-integration) ([GitLab](/stages-devops-lifecycle/) & [GitLab CI](/solutions/continuous-integration/))\n- [Backup and Traceability](#backup-and-traceability) ([borgmatic](https://github.com/witten/borgmatic) & [etckeeper](http://etckeeper.branchable.com/))\nBesides this, we have other services (like VPN or HTTP servers) running which are not that special and as such, are not covered on this article.\n\n## Base setup\n\nIt all starts with choosing the platform to run your software on. We decided to use [Arch Linux](https://www.archlinux.org/) as the operating system for our server. Our main reasons for choosing Arch Linux were its active community, good documentation, highly up-to-date repositories with current versions of important software, good support for disk encryption, and finally, the fact that Arch Linux has a rolling update scheme instead of a release-based one. This last point is especially important to us, since we do not want to go through the pain of upgrading our operating system from one version to the next every other year -  which usually causes lots of trouble. Furthermore, release-based distributions tend to have outdated software in their repositories. Instead, we prefer to keep our system always up to date and enjoy the latest version of any software any time.\n\nMost of our software is installed using Arch Linux’ package manager. However, in some cases [Docker](https://docker.com/) is also a good idea to use for running software. This is especially the case when software introduces dependencies you don’t want on your host system or if you are in doubt about the security of a software. Since Docker provides a certain level of isolation, security breaches don’t have as bad consequences as they have when you are running the vulnerable software directly on your host system. However, it should be kept in mind that there is the risk of a so-called container breakout. This basically means that your host system can be subject to an attack even if the vulnerable software is running inside a Docker container. Other reasons for using Docker can be wanting to try something out without messing up your host system or maybe software is simply not available for your Linux distribution. Of course, there are many other advantages to containerization, but we won’t be covering those today.\n\n## Communication\n\nCommunication, and using appropriate communication channels has been central to us since the very beginning. We wanted a means of communicating that was secure, fast, reliable, and easily accessible from any device. This applies to chat, email, contacts and calendar entries.\n\n### Chat\n\nFor chatting, we needed a solution which supported the concept of a “room” or “channel,” so as to keep discussions clear and separated from each other. We found Matrix/Synapse and Riot to be a perfect solution. While we also tried alternatives, such as Rocket.Chat and Mattermost, we liked Riot/Matrix the most because of its native Android app, its active development, and an open API.\n\nWe are using the Matrix API to run custom chat bots. These bots have become quite an important factor in our company, since they massively increase transparency and information distribution among the team. For example, we have bots to inform us about new commits being pushed to our GitLab server, new calendar entries being created in our shared calendar, successful or failed builds and so on. We will cover these bots in detail in an upcoming article.\n\n### Email\n\nSince we want to have complete control over the data belonging to our core business, we use a private mail server. It is indeed challenging to set up securely, but we still decided to go with it because of how important secure and private communication is to us. We had to read a lot of documentation before we could set it up, most importantly to prevent a security hole in the system. Not doing that would possibly mean ending up on a spammer blacklist, since someone could be abusing our mail server, or an attacker gaining access to our mail. It is a lot of work, but we definitely recommend taking the time to understand every step of the process and avoid any mistakes. On the client side, we seek to encrypt our emails using PGP whenever possible.\n\n### Calendar and contacts\n\nIn order to have a shared calendar as well as a shared address book, we are running Radicale, which is a lightweight CalDAV and CardDAV server. Although it is not easy to configure, it comes with support for Git and just quietly does its job in the background. We have never experienced any problems with this software so far and like it for its reliability. For Android and iOS, there are CalDAV and CardDAV adapters available to synchronize everything with your phone.\n\n### Voice Conferencing\n\nFor voice conferencing, it was very important to us to have a trustworthy open source solution in place. Proprietary solutions always come at the risk of backdoors being shipped along with them. We decided to give Mumble a try. Mumble is an open source voice client that requires a central server to handle all the traffic. The official server implementation is called Murmur. When installing Murmur, we learned that it pulls in a giant bunch of dependencies.\n\nAmong those dependencies are things such as X11 which most people don’t want on their servers. The problem with such dependencies is that they introduce potential attack surfaces as well as costing time, money, and other resources to maintain and update them. So you normally want as few dependencies as possible. This alone would make it a bad fit for us, but we still decided to give it a try. One option would have been to run Murmur inside a Docker container where the mentioned dependencies wouldn’t bother us too much. While we were configuring Murmur, we had to choose a server password. As always, we generated a long, strong password with about 60 random characters (including special characters). As we started the server and tried to connect a client, we were completely shocked. Murmur let clients in without requiring a password.\n\nWe found out that Murmur seems to have a problem with long passwords and then just ignores them. So if you configure Murmur with the goal of strong security, you get no security at all. Needless to say that we immediately uninstalled Murmur and all of the crazy dependencies it introduced.\nWhile looking for alternatives, we soon discovered uMurmur which is an alternative Mumble server implementation aiming at embedded systems. It comes with few dependencies and generally seems to be well implemented. We installed it, did not experience any issues with long passwords and have been using it ever since without any problem. The communication is encrypted using a TLS certificate.\n\n## Data storage\n\n![box files](https://about.gitlab.com/images/blogimages/startups-it-infrastructure-body.jpg){: .shadow}\n\nAnother important aspect within a company besides communication is the need to store and distribute documents among its different stakeholders.\nWhen sharing data, most programmers will normally use Git. However, Git is not to best choice for sharing binary data such as documents, photos, videos, etc., because one usually doesn’t need to keep different versions of these files. A common approach is to use ownCloud/NextCloud for data sharing, but since we really don’t like PHP, we precluded these two applications.\n\nInstead, we discovered Syncthing. Once you understand the concept of Syncthing, it is easy to set up, extremely easy to use and it just works out of the box. Syncthing can be described as a software which synchronizes data across several nodes. We have one Syncthing instance running on our server that acts as a kind of master node, although a master is not explicitly needed -  Syncthing is completely decentralized. We also run Syncthing on our desktops and phones. Each Syncthing node has a unique ID, which has to be added using the web interface of the master node in order to share data with them. For the local node, the unique ID of the master node has to be added accordingly. Using this concept of a master node, we don’t have to wire all our devices to each other -  it is enough to just wire each device to the master node.\n\nAfter that, you can select which folders should be shared using Syncthing. Syncthing will then automatically upload any new data you put into these folders to the remote node. Data added by other users is downloaded to the clients on the fly, and deletions of files, changes, etc. are also applied locally. For Android, there is a native Syncthing app available which does exactly the same. By using Syncthing, all our devices always have the latest version of the data stored inside the Syncthing shares on the master node.\n\n## Build and continuous integration\n\nFor Git and continuous integration, we use GitLab, which already comes with integrated CI features. Although GitLab is quite resource-hungry, it provides lots of very nice features such as an integrated issue tracker and the “snippets” area -  where you can paste code snippets and share them. GitLab is well documented and has an open API. It features webhooks that you can use to trigger HTTP requests whenever commits are pushed, CI pipelines start, and so on. We use that to generate notifications in matrix rooms corresponding to the Git repositories. So, for example, if someone pushes a commit to project “foo,” we get a notification in a Matrix room “room about foo,” which is linked to this project.\n\n>GitLab provides lots of very nice features such as an integrated issue tracker and the “snippets” area -  where you can paste code snippets and share them\n\nWe are using the official GitLab Docker image, which already includes [Prometheus](https://prometheus.io/) for monitoring. We are accessing this Prometheus instance from our host system and plot its data in a dedicated [Grafana](https://grafana.com/) dashboard. This way, we can monitor our GitLab server internals with very little effort.\n\nFor building a project using GitLab CI, you need a so-called “gitlab-runner” that acts as a build agent. There are also official Docker images available for those runners, but we have created our own Docker base image, which has some basic tools we constantly need. We use our custom base image to build individual runners for each project on top of it. This way, we have runners tailored exactly to the needs of our projects. Since the Docker socket is mapped into our runners, we can even build and deploy Docker images from within them.\n\nWe like the fact that the build jobs are defined through a “.gitlab-ci.yml” file that is versioned with each project. This way, you can track changes to the build process and always have a running build - even if you checkout an old version of a project.\n\n## Backup and traceability\n\nBacking up your data is very important. Especially nowadays with the widespread use of SSDs, when fatal disk failure is likely to happen. Other reasons for data loss may be accidental deletion or attacks. We are using [BorgBackup](https://borgbackup.readthedocs.io/) together with borgmatic, which is a nice, simple, incremental, and highly automatable backup solution. You can easily specify files to exclude from the backup, and also select how many daily, weekly, monthly and yearly backups you want Borg to keep. By setting up a Cron job or systemd timer, you can fully automate the backup process. We create backups every night and store them on an NFS storage, which is only mounted when the backup process is running. This way, we avoid the backup to be deleted by an accidental `rm -rf /` or some other mishap. Borg encrypts the backups and supports compression to keep your backups safe and small. We like to keep track of any changes we make to the system, especially those to configuration files.\n\nFor Linux, there is a useful little tool called etckeeper, which turns your `/etc` directory into a Git repository. It also adds hooks to your package manager to automatically commit any configuration changes being performed during system updates. Using etckeeper, every configuration change corresponds to a Git commit, with an author, a timestamp and a message. This provides for much more transparency, especially when more than one person administrates a server. Also, the way Git works, accidental changes are detected and bad configurations can be easily reverted.\n\n## Summary\n\nWe explained that we, at plapadoo, prefer lightweight (in terms of dependencies), focused software over bloated solutions and favor open source software. Our custom chat bot gives us a high level of transparency and awareness, and also improves our productivity, since we always know what’s going on, even if working remotely. Lastly, we explained which software solutions we have chosen for which use cases and why.\n\nIf you liked this article, please help us reach more readers by sharing it. If you have any questions, thoughts or recommendations on the topic, feel free to comment. Which software solutions did you choose for your startup?\n\n_This post was originally published on [Medium](https://medium.com/plapadoo/a-way-for-startups-to-build-a-solid-it-infrastructure-a48b222fbff6/)._\n\n[CERN reception, Meyrin, Switzerland](https://unsplash.com/@samuelzeller?photo=JuFcQxgCXwA) by [Samuel Zeller](https://unsplash.com/@samuelzeller) on Unsplash.\n{: .note}\n",[675,2025,1583],{"slug":3240,"featured":6,"template":679},"how-startups-build-it-infrastructure","content:en-us:blog:how-startups-build-it-infrastructure.yml","How Startups Build It Infrastructure","en-us/blog/how-startups-build-it-infrastructure.yml","en-us/blog/how-startups-build-it-infrastructure",{"_path":3246,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3247,"content":3253,"config":3259,"_id":3261,"_type":16,"title":3262,"_source":17,"_file":3263,"_stem":3264,"_extension":20},"/en-us/blog/docker-my-precious",{"title":3248,"description":3249,"ogTitle":3248,"ogDescription":3249,"noIndex":6,"ogImage":3250,"ogUrl":3251,"ogSiteName":713,"ogType":714,"canonicalUrls":3251,"schema":3252},"Continuous integration: From Jenkins to GitLab using Docker","We're migrating all of our working tools to open source ones, and moving to GitLab has made all the difference.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667509/Blog/Hero%20Images/continuous-integration-from-jenkins-to-gitlab-using-docker.jpg","https://about.gitlab.com/blog/docker-my-precious","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Continuous integration: From Jenkins to GitLab using Docker\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Abdulkader Benchi\"}],\n        \"datePublished\": \"2017-07-27\",\n      }",{"title":3248,"description":3249,"authors":3254,"heroImage":3250,"date":3256,"body":3257,"category":14,"tags":3258},[3255],"Abdulkader Benchi","2017-07-27","\n\n Here at [Linagora](https://linagora.com/), we are migrating all our working tools to open source ones. Yes, we are an open source company with open source lovers.\n\n\u003C!-- more -->\n\nAmong these different tools were the [Atlassian](https://www.atlassian.com/) development tools. We decided to switch to GitLab and it started making all the difference. Indeed, GitLab includes Git repository management, issue tracking, code review, an IDE, activity streams, wikis, and more. It's worth mentioning that GitLab has built-in [Continuous Integration (CI) and Continuous Deployment (CD)](/topics/ci-cd/) to test, build, and deploy our code. We can easily monitor the progress of our tests and build pipelines. What we love about the CI provided by GitLab is the fact that it supports Docker. Indeed, GitLab allows us to use custom [Docker](https://www.docker.com/) images, spin up services as part of testing, build new Docker images, even run on [Kubernetes](https://kubernetes.io/).\n\nIf you are a Docker lover and you want to see how to transform [Jenkins](https://jenkins.io/) CI to GitLab CI using Docker, then you are in the right place.\n\n### Jenkins job\n\nLet’s have a look at our Jenkins Job.\n\n```\nMONGOPORT=23500\nBASEDIR=`pwd`\n\n# Update tools\n(cd repo && composer update)\n\n# Run code style checker\n./repo/vendor/bin/phpcs -p --standard=repo/vendor/sabre/dav/tests/phpcs/ruleset.xml --report-checkstyle=checkstyle.xml repo/lib/\n\n# Cleanup\nrm -rf mongodb\nrm -f mongo.pid\nrm -f mongo.log\nmkdir -p mongodb\n\n\n# Start temporary mongo server\nmongod --dbpath mongodb \\\n       --port $MONGOPORT \\\n       --pidfilepath $BASEDIR/mongo.pid \\\n       --logpath mongo.log \\\n        --fork\n\nsleep 2\n\n# Configure\ncat \u003C\u003CEOF > repo/config.json\n{\n  \"webserver\": {\n    \"baseUri\": \"/\",\n    \"allowOrigin\": \"*\"\n  },\n  \"database\": {\n    \"esn\": {\n      \"connectionString\" : \"mongodb://localhost:$MONGOPORT/\",\n      \"db\": \"esn\",\n      \"connectionOptions\": {\n        \"w\": 1,\n        \"fsync\": true,\n        \"connectTimeoutMS\": 10000\n      }\n    },\n    \"sabre\": {\n      \"connectionString\" : \"mongodb://localhost:$MONGOPORT/\",\n      \"db\": \"sabredav\",\n      \"connectionOptions\": {\n        \"w\": 1,\n        \"fsync\": true,\n        \"connectTimeoutMS\": 10000\n      }\n    }\n  },\n  \"esn\": {\n    \"apiRoot\": \"http://localhost:8080/api\"\n  }\n}\nEOF\n\n# Run unit tests\n(cd repo/tests && ../vendor/bin/phpunit \\\n    --coverage-clover=$BASEDIR/clover.xml \\\n    --log-junit=$BASEDIR/junit.xml \\\n    .)\n\n# Clean up\nkill `cat mongo.pid`\n```\n\nI know, it is horrible to read this configuration, but you know we have to configure everything from A to Z in Jenkins. I can confirm that this job is one of the simplest jobs we have, because it depends on only one external service, “MongoDB.” We passed almost half of this job configuring this external service, starting it, cleaning it and killing it. Whereas, our main job is only about 10 lines. Furthermore, we suppose that on the Jenkins machine, we already have installed PHP, all PHP plugins and composer. So if we change the machine we have to reconfigure the new machine before starting using it. Docker… help please.\n\n![Docker help us](https://about.gitlab.com/images/blogimages/sos-docker.jpg){: .shadow}\u003Cbr>\n\n### GitLab job\n\nBefore starting, it's worth mentioning that good documentation about this part is presented [here](https://docs.gitlab.com/ee/ci/docker/using_docker_images.html). If you got it right, all GitLab’s CI configuration is to be done in a file called .gitlab-ci.yml. I will start presenting the final result before discussing the details:\n\n```\nimage: linagora/php-deps-composer:5.6.30\n\nservices:\n  - mongo:3.2\n\nstages:\n  - build\n  - deploy_dev\n\nbuild:\n  stage: build\n  script:\n    - composer up\n    - cp config.tests.json config.json\n    - ./vendor/bin/phpcs -p --standard=vendor/sabre/dav/tests/phpcs/ruleset.xml --report-checkstyle=checkstyle.xml lib/\n    - cd tests\n    - ../vendor/bin/phpunit --coverage-clover=${CI_PROJECT_DIR}/clover.xml --log-junit=${CI_PROJECT_DIR}/junit.xml .\n\ndeploy_dev:\n  stage: deploy_dev\n  only:\n    - master\n  script:\n    - cd /srv/sabre.dev\n    - git fetch --all\n    - git checkout ${CI_COMMIT_SHA}\n    - composer up\n```\n\n### Migration procedure\n\nWe start defining the image of which of GitLab’s Docker executors will run to perform the CI tasks. This is done by using the image keyword (line 1). This is a custom image we build to provide all the dependencies we need for our CI tasks. Here is the corresponding Dockerfile:\n\n```\nFROM php:5.6.30\n\nMAINTAINER Linagora Folks \u003Clgs-openpaas-dev@linagora.com>\n\nRUN apt-get update \\\n    apt-get -y install unzip git php5-curl php5-dev php-amqplib \\\n    docker-php-ext-install bcmath \\\n    pecl install mongo \\\n    docker-php-ext-enable mongo \\\n    curl https://getcomposer.org/installer | php \\\n    mv composer.phar /usr/local/bin/composer.phar \\\n    ln -s /usr/local/bin/composer.phar /usr/local/bin/composer\n```\n\nAs I mentioned before, our CI requires an external MongoDB service. But this time, Docker is here to do the magic. It helps us with configuring, starting and killing the service correctly. All what we have to do is to declare mongo as a service (line 4), et voilà!\n\nNow we have set up our environment, we can leverage script tag to test our code (lines 13–17) and deploy it (lines 24–27). It is worth noting that config.test.json contains all the configuration we have had in Jenkins (Lines 28–56 from Jenkins configuration).\n\n#### Running the GitLab job locally\n\nWe can easily test our GitLab builds locally using [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/blob/master/docs/commands/README.md). Here is the procedure:\n\n* Install it locally, either using a package repository or directly from here. If you do not want to install the GitLab Runner locally, you can always leverage Docker to do so. Have a look [here](https://gitlab.com/gitlab-org/gitlab-runner/issues/312).\n* Run the build: gitlab-runner exec docker {my-job}. Whereas, my-job is the name of the job defined in .gitlab-ci.yml. In our case, it is called build.\n\n#### Wrap up\n\nAs you can see, our CI job becomes easier to read thanks to GitLab and Docker. Along the same lines, we do not need to configure our machine to run tests anymore. Docker has got our back. In my opinion, the most important advantage of using Docker to run tests is to guarantee that our tests are always being run in the same conditions each time. These tests are totally isolated (and also independent) from the machine on which they run.\n\nThis post originally appeared on _[Medium](https://medium.com/linagora-engineering/docker-my-precious-6efbce900dcb)_.\n\n### About the Guest Author\n\nAbdulkader Benchi is the Javascript team leader at [Linagora](https://linagora.com/careers).\n",[675,1000],{"slug":3260,"featured":6,"template":679},"docker-my-precious","content:en-us:blog:docker-my-precious.yml","Docker My Precious","en-us/blog/docker-my-precious.yml","en-us/blog/docker-my-precious",{"_path":3266,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3267,"content":3273,"config":3278,"_id":3280,"_type":16,"title":3281,"_source":17,"_file":3282,"_stem":3283,"_extension":20},"/en-us/blog/gitlab-top-30-highest-velocity-open-source",{"title":3268,"description":3269,"ogTitle":3268,"ogDescription":3269,"noIndex":6,"ogImage":3270,"ogUrl":3271,"ogSiteName":713,"ogType":714,"canonicalUrls":3271,"schema":3272},"We're one of the 30 Highest Velocity Open Source Projects","With a magical combination of number of commits, authors, issues and merge requests, we're in great company with other open source projects with momentum.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671330/Blog/Hero%20Images/highest-velocity-open-source-projects.jpg","https://about.gitlab.com/blog/gitlab-top-30-highest-velocity-open-source","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"We're one of the 30 Highest Velocity Open Source Projects\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2017-07-06\",\n      }",{"title":3268,"description":3269,"authors":3274,"heroImage":3270,"date":3275,"body":3276,"category":14,"tags":3277},[2966],"2017-07-06","\n\nIn June the Cloud Native Computing Foundation released its chart of the [top open source projects with the highest developer velocity](https://www.cncf.io/blog/30-highest-velocity-open-source-projects/), and we're proud to be included – in good company!\n\n\u003C!-- more -->\n\nMeasuring commits, authors, issues and merge or pull requests, the chart places GitLab in the top right quadrant with eight others including [Kubernetes](https://docs.gitlab.com/ee/user/project/clusters/index.html) and [Elasticsearch](https://docs.gitlab.com/ee/integration/elasticsearch.html).\n\n![CNCF highest velocity open source projects chart](https://about.gitlab.com/images/blogimages/CNCF-highest-velocity-open-source-chart.png){: .shadow}\n\n## Open Source at Heart\n\nWhile ['open core'](/blog/gitlab-is-open-core-github-is-closed-source/) might be a more accurate description of GitLab, as we ship both an [open source version](/pricing/feature-comparison/) and [closed source version](/pricing/), we adopt an open source approach to both, with a publicly viewable issue tracker and license that allows modifications once you purchase a license.\n\nWe already know that there are good reasons [why you should choose to work with open source projects](/blog/why-choose-open-source/), and we're grateful to our over [1700 contributors](http://contributors.gitlab.com/contributors) who have helped to shape GitLab – not just the product, but the company too. I work in the Marketing team and am always surprised and pleased when a member of our community pops up in an issue in the [Marketing project](https://gitlab.com/gitlab-com/marketing/issues) to offer some input or share an idea. It's a great reminder that [everyone can contribute](/community/contribute/), and those contributions go far beyond development.\n\nSo, thank you!\n\n## Keep Those Contributions Coming\n\nIf you're new to GitLab, [this will help](/blog/heres-how-new-programmers-can-learn-by-contributing-to-gitlab/), otherwise, as always, feel free to [open or comment on an issue](https://gitlab.com/gitlab-org/gitlab-ce/issues). See [all the ways you can contribute here](/community/contribute/).\n\n[Cover image](https://unsplash.com/search/jaws-haiku-pauwela-united-states?photo=sW8psg40WXY) by [Anton Repponen](https://unsplash.com/@repponen) on Unsplash\n{: .note}\n",[675,3043],{"slug":3279,"featured":6,"template":679},"gitlab-top-30-highest-velocity-open-source","content:en-us:blog:gitlab-top-30-highest-velocity-open-source.yml","Gitlab Top 30 Highest Velocity Open Source","en-us/blog/gitlab-top-30-highest-velocity-open-source.yml","en-us/blog/gitlab-top-30-highest-velocity-open-source",{"_path":3285,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3286,"content":3292,"config":3297,"_id":3299,"_type":16,"title":3300,"_source":17,"_file":3301,"_stem":3302,"_extension":20},"/en-us/blog/why-choose-open-source",{"title":3287,"description":3288,"ogTitle":3287,"ogDescription":3288,"noIndex":6,"ogImage":3289,"ogUrl":3290,"ogSiteName":713,"ogType":714,"canonicalUrls":3290,"schema":3291},"Why more companies are adopting open source technology","The results are in – our 2016 Global Developer Survey revealed that open source tools are most preferred by developers the world over. Why?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671390/Blog/Hero%20Images/developers-choose-open-source.jpg","https://about.gitlab.com/blog/why-choose-open-source","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why more companies are adopting open source technology\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2017-03-03\",\n      }",{"title":3287,"description":3288,"authors":3293,"heroImage":3289,"date":3294,"body":3295,"category":14,"tags":3296},[2966],"2017-03-03","\n98 percent of developers use open source tools – even when they’re not supposed to! Here’s why.\n\n\u003C!-- more -->\n\nOur [Global Developer Report](https://page.gitlab.com/2016-developer-survey_2016-developer-survey.html) explores how developers’ methods are changing, and how businesses can adapt to get the best out of their development teams. More than half of our respondents identified as developer or engineer, giving us insight into what matters to developers, how they work and what tools they choose. To see what our research revealed, you can [download the full report](https://page.gitlab.com/2016-developer-survey_2016-developer-survey.html) to learn more about what today’s developers want.\n\n## Why open source is preferred\n\nNearly three-quarters of our survey respondents said that they chose to work with GitLab because it’s open source. So why is [open source](/solutions/open-source/) so popular?\n\n### Software evolves faster\n\nWith roots in the open source community, software is able to evolve quickly, with bugs detected and fixed rapidly by members of that community. This reduces the time spent waiting for fixes to be rolled out – a good case for why the majority of our survey respondents say that more than half of the tools they use are open source.\n\n![How much open source is used](https://about.gitlab.com/images/blogimages/open-source-tools-graph.png){: .shadow}\u003Cbr>\n\n### You know what you’re getting\n\nOpen source software is also considered more trustworthy: with source code open and available to inspect, developers can see for themselves exactly what it does. They can verify whether or not it's secure and introduce fixes and improvements if necessary.\n\n### You can adapt it yourself\n\nIf developers want to adapt a feature or add something that will make their jobs easier, they have the freedom to do so without relying on the software vendor to make the change. Open source also makes it easier to integrate different software products to suit the needs of the business.\n\n## Developers overwhelmingly choose open source\n\nSenior leadership only selects tools for their teams less than 20 percent of the time, and 11 percent of developers still choose to use their own open source tools, despite what their managers say. This poses a risk to companies insisting on closed source solutions for their developer teams: it compromises your ‘single source of truth’, risks team happiness and cohesion, and wastes resources spent on unused tools.\n\n![Who chooses development tools](https://about.gitlab.com/images/blogimages/who-in-org-decides-tools-graph.png){: .shadow}\u003Cbr>\n\nThe message is clear: when developers have the freedom to choose their tools (and sometimes even when they don’t!), they choose open source – maybe it’s time your company did too.\n\nImage: “[brooklyn sign](https://www.flickr.com/photos/petemccarthy/6866996865)” by [Peter McCarthy](https://www.flickr.com/photos/petemccarthy/) is licensed under [CC BY-ND 2.0](https://creativecommons.org/licenses/by-nd/2.0/)\n{: .note}\n",[675],{"slug":3298,"featured":6,"template":679},"why-choose-open-source","content:en-us:blog:why-choose-open-source.yml","Why Choose Open Source","en-us/blog/why-choose-open-source.yml","en-us/blog/why-choose-open-source",{"_path":3304,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3305,"content":3311,"config":3316,"_id":3318,"_type":16,"title":3319,"_source":17,"_file":3320,"_stem":3321,"_extension":20},"/en-us/blog/codepen-welcome-to-gitlab",{"title":3306,"description":3307,"ogTitle":3306,"ogDescription":3307,"noIndex":6,"ogImage":3308,"ogUrl":3309,"ogSiteName":713,"ogType":714,"canonicalUrls":3309,"schema":3310},"CodePen, welcome to GitLab!","Yes, it's worth it - CodePen has moved to GitLab!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666619/Blog/Hero%20Images/codepen-welcome-to-gitlab-cover.png","https://about.gitlab.com/blog/codepen-welcome-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"CodePen, welcome to GitLab!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Marcia Ramos\"}],\n        \"datePublished\": \"2017-01-27\",\n      }",{"title":3306,"description":3307,"authors":3312,"heroImage":3308,"date":3314,"body":3315,"category":14},[3313],"Marcia Ramos","2017-01-27","\nWe were so glad to hear that [CodePen] switched to GitLab!\n\nRead through the ins and outs of their move! 😃\n\n\u003C!-- more -->\n\n----\n\nI'm a big fan of CodePen. Their product is awesome: it's\nintuitive, beautiful, works like a charm, and it's really easy to use.\nTheir community's work is evolving – we could spend hours playing around\nwith pens like this, [created][pen] by [Jase Smith]:\n\n\u003Cp data-height=\"300\" data-theme-id=\"23203\" data-slug-hash=\"dNVaae\" data-default-tab=\"js,result\" data-user=\"virtuacreative\" data-embed-version=\"2\" data-pen-title=\"Spock! Paper Scissors\" class=\"codepen\">See the Pen \u003Ca href=\"http://codepen.io/virtuacreative/pen/dNVaae/\">Spock! Paper Scissors\u003C/a> by Virtua Creative (\u003Ca href=\"http://codepen.io/virtuacreative\">@virtuacreative\u003C/a>) on \u003Ca href=\"http://codepen.io\">CodePen\u003C/a>.\u003C/p>\n\u003Cscript async src=\"https://production-assets.codepen.io/assets/embed/ei.js\">\u003C/script>\n\nWhen I heard that they had switched to GitLab, I was thrilled! Yaaay!\n \u003Ci class=\"fas fa-codepen\" aria-hidden=\"true\">\u003C/i>\n **CodePen, welcome to GitLab!**\n \u003Ci class=\"fab fa-gitlab\" aria-hidden=\"true\">\u003C/i>\n\nThey're very cool folks, and their [team][team] is making such an\nawesome product! They're also [remote only](https://www.remoteonly.org/), like us.\n\nListen to their podcast [Codepen Radio - 114 - GitLab](https://blog.codepen.io/2017/01/24/114-gitlab/), which details why they moved and how it\nwent. If you'd rather read, we've included some of the highlights below.\n\n## Highlights\n\n{::options parse_block_html=\"true\" /}\n\n\u003Cdiv class=\"panel panel-gitlab-orange\">\n### \u003Ci class=\"fas fa-cog fa-fw\" aria-hidden=\"true\">\u003C/i> Control\n{: .panel-heading}\n\u003Cdiv class=\"panel-body\">\n5:18. The first thing they talked about is \"control\".\n\n7:45. They can't rely on a third-party service to deploy\ntheir code. Whenever there's downtime, there's nothing they can do about it. With a self-managed GitLab instance,\nthey have the ability to exercise control over their server and everything else.\n\u003C/div>\n\u003C/div>\n\n\u003Cdiv class=\"panel panel-gitlab-purple\">\n### \u003Ci class=\"fas fa-lock fa-fw\" aria-hidden=\"true\">\u003C/i> Security\n{: .panel-heading}\n\u003Cdiv class=\"panel-body\">\n10:00. Because it's self-managed, they feel much more protected from hacker attacks and system breaches.\nThey have their own private network space in which they run GitLab.\n\n> 12.35. _We have control, we have code in our own network, we have higher security._\n\u003C/div>\n\u003C/div>\n\n\u003Cdiv class=\"panel panel-gitlab-orange\">\n### \u003Ci class=\"fas fa-code fa-fw\" aria-hidden=\"true\">\u003C/i> Open source & Cost\n{: .panel-heading}\n\u003Cdiv class=\"panel-body\">\n> 13:00. _The open source version of GitLab [[CE]] is 100% free. You can install it on your own server._\n\nThey decided to go for [GitLab EE Starter][ee] for having certain great features available only on EE, such as [Multiple Issue Boards][boards], and [fast-forward merge](https://docs.gitlab.com/ee/user/project/merge_requests/methods/index.html).\n\n> 14:26. _[GitLab EE] is not terribly expensive, and we're also supporting open source development._\n\u003C/div>\n\u003C/div>\n\n\u003Cdiv class=\"panel panel-gitlab-purple\">\n### \u003Ci class=\"fas fa-sync-alt fa-fw\" aria-hidden=\"true\">\u003C/i> Continuous Integration and Continuous Deployment\n{: .panel-heading}\n\u003Cdiv class=\"panel-body\">\n15:40. Finally, they don't need to rely on third-party services to apply Continuous Integration to test and\ndeploy their code. [GitLab CI][ci] does this job, and it's built-in in GitLab.\n\n> 16:34. _Because this [CI] runs internally, and because we have access to our own VPC and resources inside of it, like Docker stuff, and AWS EFS stuff, we can actually take a step further and not just test our stuff, but grab it and deploy it._\n\n> 16:58. _In our case, [GitLab] give you tools to make [Continuous Integration, Continuous Testing and Continuous Deployment][ci-cd] really, really simple. And that, to me, is the biggest sell of them all. That's simply not available on GitHub._\n\nThey also enjoy not having to deploy from the command line, as it was impossible to track.\n\n17:15. They love our [Pipelines][pipes], where the entire team can see what's going on and who's doing what. The steps are visible.\n\n> 17:27. _It's very clear, in GitLab, whether a build on staging has actually been pushed to production. So, if I'm going to deploy something to production, I can very easily see who has moved that into master since the last production deploy._\n\nThey also love the [rollback] button: no pain, all gain. Now it's easy to roll back changes.\n\n> 19:18. _I feel more comfortable, for sure._\n\u003C/div>\n\u003C/div>\n\n\u003Cdiv class=\"panel panel-gitlab-orange\">\n### \u003Ci class=\"far fa-heart fa-fw\" aria-hidden=\"true\">\u003C/i> Their impression\n{: .panel-heading}\n\u003Cdiv class=\"panel-body\">\n23:20. Overall, GitLab brought them speed, security and agility.\n\n> 23:37. _Whatever we want to do, we can do, and we're not bound by someone else's Continuous Deployment setup._\n\u003C/div>\n\u003C/div>\n\n\u003Cdiv class=\"panel panel-gitlab-purple\">\n### \u003Ci class=\"fas fa-chain fa-fw\" aria-hidden=\"true\">\u003C/i> Project Management: everything in one place\n{: .panel-heading}\n\u003Cdiv class=\"panel-body\">\n> 24:56. _We were using Trello boards to organize our tasks, but very recently we've decided to move our project's specific tasks into GitLab [[Issue Boards]]. And that's because Trello is really good, in my opinion, for idea generation and quickly getting up cards for a lot of ideas you have. But the fact that the cards are so easy to add, at any point anywhere, kind of hurt us when we were trying to plan dev-work for a project, because we had duplicate cards, and the cards weren't tied to any specific pull request or issue in the codebase. So, it's kind of wish-washy having project planning over in Trello. (...) We've decided to switch to GitLab for actionable tasks related to getting up a project finished within CodePen._\n\n26:40. They appreciate having the [Issue Boards], [Todos], and [Time Tracking][tt] in one single platform, tied together with their code.\n\n> 28:07. _Let's start looking at all of the things that are required to go into a feature and all, and assign them priorities, and people, and milestones, and time estimates, and stuff, and it feels like a really grown-up management of a thing, and it's pretty interesting!_\n\n29:10. They mentioned how cool it is to perform a [slash command][slash]\nto add how long it's going to take to complete the implementation of a feature, right from an issue comment.\n\n> 29:50. _We are, as a group, sick of not having an understanding of how long it's going to take to complete a feature or whatever. If we use [[Time Tracking][tt]], we'll know, or we'll be a lot closer to it! And further, we're going to be more accurate on what those time estimates are going to be, and we can plan around that, and not feel so wishy-washy about these big important things that we're doing. So we get that! That comes in the GitLab package as well, so it's kind of like we replaced GitHub, Codeship and Trello with one open source tool! This feels kind of cool!_\n\u003C/div>\n\u003C/div>\n\n\u003Cdiv class=\"panel panel-gitlab-orange\">\n### \u003Ci class=\"fas fa-heartbeat fa-fw\" aria-hidden=\"true\">\u003C/i> The transition\n{: .panel-heading}\n\u003Cdiv class=\"panel-body\">\n30.45. They feel they made a mistake by not using the importer tool to import their projects: they simply pushed to GitLab like a separate remote. By doing so, they left some issues and wikis behind and had to transfer them manually.\n\n> 31:24. _This is biggest warning I have for everyone: read the [documentation][docs]!_\n\nWith [GitLab Importer][importer], you can just import your projects from GitHub directly\nfrom the UI, which means pushing a button.\n\n> 31:45. _It's just a button, essentially. You just have to give access to your GitHub account via keys, and once you've done that, GitLab will actually pull in all of your repos, and say \"Which ones do you want to import?\" and you just go \"import\", \"import\", \"import\"..._\n\u003C/div>\n\u003C/div>\n\n\u003Cdiv class=\"panel panel-gitlab-purple\">\n### \u003Ci class=\"fas fa-check-square-o fa-fw\" aria-hidden=\"true\">\u003C/i> Bottom Line\n{: .panel-heading}\n\u003Cdiv class=\"panel-body\">\nThere's one thing they are missing: squash-merge. Good news for y'all: we have something like that [coming][squash] soon!\n\nAt 33:44 they also mention burndown charts, and there is [an issue][burndown] for that with a lot of traction.\n\n> 34:03. _My final feeling about GitLab is it's incredibly impressive work. Like, holy crap, this is really good software! High five team!_ 🙌\n\n\u003C/div>\n\u003C/div>\n\n## GitLab Version\n\nCodePen is using [GitLab EE Starter][ee], self-managed on AWS together with all their\nstructure.\n\n----\n\nCover image: screenshot of [About CodePen][about].\n{:.note}\n\n\u003C!-- identifiers -->\n\n[about]: http://codepen.io/about/\n[boards]: /stages-devops-lifecycle/issueboard/#step-6\n[burndown]: https://gitlab.com/gitlab-org/gitlab-ee/issues/91\n[ce]: /stages-devops-lifecycle/ \"GitLab Community Edition\"\n[ci-cd]: /blog/continuous-integration-delivery-and-deployment-with-gitlab/\n[ci]: /solutions/continuous-integration/ [Codepen]: https://codepen.io/\n[docs]: https://docs.gitlab.com/\n[ee]: /pricing/ \"GitLab Enterprise Edition\"\n[ff]: https://docs.gitlab.com/ee/user/project/merge_requests/methods/index.html\n[importer]: https://docs.gitlab.com/ee/user/project/import/github.html\n[Issue Boards]: /stages-devops-lifecycle/issueboard/\n[jase smith]: https://codepen.io/jasesmith/\n[pen]: https://codepen.io/jasesmith/pen/GqaVrx\n[pipes]: https://docs.gitlab.com/ee/ci/pipelines/index.html\n[remote-only]: /company/culture/all-remote/\n[rollback]: https://docs.gitlab.com/ee/ci/environments/index.html#viewing-the-deployment-history-of-an-environment\n[slash]: https://docs.gitlab.com/ee/user/project/quick_actions.html\n[squash]: https://gitlab.com/gitlab-org/gitlab-ee/issues/150\n[team]: https://codepen.io/about/\n[todos]: https://docs.gitlab.com/ee/user/todos.html\n[tt]: https://docs.gitlab.com/ee/user/project/time_tracking.html\n\n\u003Cstyle>\nh3 {\n  margin-top: 0 !important;\n  margin-bottom: 0 !important;\n  font-size: 20px !important;\n}\n.shadow {\n  box-shadow: 0 4px 18px 0 rgba(0, 0, 0, 0.1), 0 6px 20px 0 rgba(0, 0, 0, 0.09);\n  margin-bottom: 20px;\n  margin-top: 20px; }\n}\n\u003C/style>\n",{"slug":3317,"featured":6,"template":679},"codepen-welcome-to-gitlab","content:en-us:blog:codepen-welcome-to-gitlab.yml","Codepen Welcome To Gitlab","en-us/blog/codepen-welcome-to-gitlab.yml","en-us/blog/codepen-welcome-to-gitlab",{"_path":3323,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3324,"content":3329,"config":3333,"_id":3335,"_type":16,"title":3336,"_source":17,"_file":3337,"_stem":3338,"_extension":20},"/en-us/blog/heres-how-new-programmers-can-learn-by-contributing-to-gitlab",{"title":3325,"description":3326,"ogTitle":3325,"ogDescription":3326,"noIndex":6,"ogImage":1151,"ogUrl":3327,"ogSiteName":713,"ogType":714,"canonicalUrls":3327,"schema":3328},"Here's how new programmers can learn by contributing to GitLab","Everyone starts somewhere.","https://about.gitlab.com/blog/heres-how-new-programmers-can-learn-by-contributing-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Here's how new programmers can learn by contributing to GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2016-12-07\",\n      }",{"title":3325,"description":3326,"authors":3330,"heroImage":1151,"date":3331,"body":3332,"category":14},[818],"2016-12-07","Hello, relative newcomers. There’s room for you to contribute, too. You can start by finding other programmers, making a plan before you code, documenting properly, and poking around on GitLab so you're never ever learning in a vacuum. Teaching yourself is hard, so here are a few tips.\n\n\u003C!--more-->\n\n## Find other programmers near you.\n\nSoftware development is not something you can learn by yourself. You have to incorporate other perspectives, and bounce ideas off of people. Go to meet-ups, conferences and any events that will facilitate meeting with other developers. Try to work on projects with other developers, because most of your professional work will involve you and others collaborating on a project - it is very difficult to design and maintain complex software on your own! This can also help you avoid developing bad habits in the first place - it's much more difficult to un-learn them down the road. Even making small contributions to GitLab will help you get involved and practice communicating with others working on the same project.\n\n## Plan before you start coding.\n\nThis is an important part of software development that lots of new programmers tend to ignore. Often they want to start writing code as soon as possible, but skipping the planning stage has a negative effect in the long term. You’ll likely end up with an unmaintainable code base and a poorly designed application. You need to embrace the \"boring parts\" of software development. These help remind you to start small by mastering the basics before you try to build the next Facebook. [_The Pragmatic Programmer_](https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/) by Andrew Hunt and David Thomas is an excellent resource. GitLab's issue board is a useful tool for thinking through potential challenges and creating detailed checklists.\n\n## Follow conventions and standards.\n\nThere are some generally accepted coding conventions and standards you will come across when you start out. The advantage of following these norms is that most of them were created or developed by really smart people who discovered ways of making it easier to develop and maintain software. This will save you from falling into most mistakes others have found solutions to. That’s why it is really important to try and contribute to open source projects; they tend to expose you to these standards. GitLab has a [contribution guide]( https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md) to help you get started.  \n\n## Document properly.\n\nThis might seem trivial, but it is actually one of the most difficult aspects of software development. There is a recurring joke of how naming things can be really difficult. It is important to document properly to ensure others can understand your code and make it possible for you to return to your program after some time away from it without pulling your hair out. Young programmers tend to focus more on making their code run, ignoring their code readability. To avoid other people rewriting your code, ensure you document it properly, comment on your code and use proper naming conventions. This blog [article](http://blog.codinghorror.com/coding-for-violent-psychopaths/) illustrates how important it is to document and follow best practices: “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” Especially since your work on GitLab will likely be public, you should assume that at some point in the future, someone will look through your code and perhaps even borrow from it.   \n\nAlmost anyone can learn how to code, but it takes tremendous effort to learn how to build complex software that can be maintained for years. It will be great if more experienced developers reading this article give feedback or add to the points given above in the comment section.  \n\n_If you have some Ruby/JavaScript experience and you’re looking for a place to get started, check out our [Contribution Guide]( https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md) and the “[Accepting merge requests]( https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#i-want-to-contribute)” label._\n\n_Tweet [@GitLab](https://twitter.com/gitlab) and check out our [job openings](/jobs/)._\n",{"slug":3334,"featured":6,"template":679},"heres-how-new-programmers-can-learn-by-contributing-to-gitlab","content:en-us:blog:heres-how-new-programmers-can-learn-by-contributing-to-gitlab.yml","Heres How New Programmers Can Learn By Contributing To Gitlab","en-us/blog/heres-how-new-programmers-can-learn-by-contributing-to-gitlab.yml","en-us/blog/heres-how-new-programmers-can-learn-by-contributing-to-gitlab",{"_path":3340,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3341,"content":3347,"config":3351,"_id":3353,"_type":16,"title":3354,"_source":17,"_file":3355,"_stem":3356,"_extension":20},"/en-us/blog/why-vaadin-chose-gitlab",{"title":3342,"description":3343,"ogTitle":3342,"ogDescription":3343,"noIndex":6,"ogImage":3344,"ogUrl":3345,"ogSiteName":713,"ogType":714,"canonicalUrls":3345,"schema":3346},"Customer Story: Why Vaadin chose GitLab","Vaadin needed a new solution after their multiple platforms began costing too much time and frustration.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670710/Blog/Hero%20Images/why-vaadin-chose-gitlab-cover.png","https://about.gitlab.com/blog/why-vaadin-chose-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Customer Story: Why Vaadin chose GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2016-12-05\",\n      }",{"title":3342,"description":3343,"authors":3348,"heroImage":3344,"date":3349,"body":3350,"category":14},[2549],"2016-12-05","\n\n_[Vaadin](https://vaadin.com) is an open source UI product development company that builds components and tools for developers to create beautiful web applications. The company has more than 170 employees, based in Finland, Helsinki, Berlin, and San Jose. Today more than 150,000 developers are active users of Vaadin._\n\n\u003C!-- more -->\n\nVaadin wanted a tool to centralize their internal projects, while maintaining the commitment to simple UI/UX that they prioritize in their own product. Although they had developed a workflow using [Gitolite](http://gitolite.com/gitolite/index.html), [Trac](https://trac.edgewall.org/), and several other platforms, the administrative overhead began costing developers and admins valuable time. After following GitLab since its earliest iterations, Vaadin’s IT manager, Mikael Vappula, decided that GitLab was the right platform for them. We sat down with Mikael to learn more.\n\nHere are some tips from Mikael's experience:\n* Centralizing projects reduces the overhead of both IT admins and developers.\n* Issue trackers and code review make a potent combination, especially when you can easily cross-link relevant issues and MRs.\n* Make the best tools available to your team, but let them decide what to use.\n\n**What were you using for your previous VCS?**\n{: .alert .alert-info}\n\nBefore GitLab, we used Gitolite for git repository management, Trac for issue tracking, and a variety of other platforms. We had a range of tools with separate instances provisioned for specific purposes within each project.\n\n**What were the challenges with it? Was there a specific moment when you knew it was time to try something else?**\n{: .alert .alert-info}\n\nAs the team grew, the administrative overhead grew with it. For me, the work of tracking which repos individual projects were in, or who had access to what, was starting to burden the team. The development team had problems finding relevant projects, linking to the right issue tracker, and managing the needed credentials. They lost valuable time searching for the right version control system and the correct set of credentials for it.\n\nAs the IT Manager, I had to set up new repos and credentials for the growing number of projects, tools, and employees. In doing so, I noticed that our tooling was leading developers to use their time inefficiently and become frustrated. Like most companies, our engineering teams play a critical role in the success of our business, and we couldn’t afford the loss of developers’ time. It was clear the team needed one platform where they could pull everything together under a single entry point.\n\n**Once you decided on us, how did you find the migration process?**\n{: .alert .alert-info}\n\nThe prospect of a migration is intimidating, but [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab) made the installation and migration process easy, and we began using it quickly. I ran the setup procedure to get the new system provisioned on a new virtual machine in Vaadin's on-premise servers. I was impressed by the Omnibus distribution, and once I set up the basic settings, it was pretty much self-service. The only thing we had to pay a little more attention to was how to integrate GitLab into our authentication system (powered by CAS).\n\nI've also been impressed in terms of maintenance and updates. Rather than a multitude of servers and configuration files, the only resources needed for the 200 internal projects that Vaadin runs using GitLab are just one server and one configuration file. You know there’s always that software where you try to postpone updates, but with GitLab it’s pretty safe to take the latest version. We’ve done the updates 20 times now.\n\n**How have developers on your team responded to the switch? How did you announce the change?**\n{: .alert .alert-info}\n\nWe really emphasize open-mindedness and choice, so I couldn’t mandate a tool switch. I've heard from team members who appreciate that our culture allows people to choose their own hardware and discuss challenges openly. So after I set up GitLab I wrote a post to all of our employees. I tried to just explain what GitLab is, what different people should use it for, and generally how GitLab as a tool fits with our culture. I was pleased to see that after they heard GitLab was available to them, people generally adopted it quickly.\n\n**Can you share any details about how using GitLab has improved your team's performance or general experience?**\n{: .alert .alert-info}\n\nIt made a big difference for us to have a central point for software projects that we could manage by ourselves and have all the tooling in one place. I think using GitLab has also led to improvements in our workflow and collaboration. Using cross-linking, you can link to issues and merges, the mark-up system is great, and you can select a project’s activity to see all the members in one place. Integration, workflow, and communication have all been vastly improved.\n\n\n_If your team uses GitLab and is interested in sharing your story, please fill out this [form](https://docs.google.com/a/gitlab.com/forms/d/1K8ZTS1QvSSPos6mVh1ol8ZyagInYctX3fb9eglzeK70/edit) and we’ll get in touch!_\n\n_Tweet us [@GitLab](https://twitter.com/gitlab), and check out our [job openings](/jobs/)_\n\n_Follow [@Vaadin](https://twitter.com/vaadin?lang=en) on Twitter_\n",{"slug":3352,"featured":6,"template":679},"why-vaadin-chose-gitlab","content:en-us:blog:why-vaadin-chose-gitlab.yml","Why Vaadin Chose Gitlab","en-us/blog/why-vaadin-chose-gitlab.yml","en-us/blog/why-vaadin-chose-gitlab",{"_path":3358,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3359,"content":3365,"config":3369,"_id":3371,"_type":16,"title":3372,"_source":17,"_file":3373,"_stem":3374,"_extension":20},"/en-us/blog/how-to-build-a-strong-dev-community",{"title":3360,"description":3361,"ogTitle":3360,"ogDescription":3361,"noIndex":6,"ogImage":3362,"ogUrl":3363,"ogSiteName":713,"ogType":714,"canonicalUrls":3363,"schema":3364},"How to build a strong developer community","Our developer advocate Amanda Folson shares some community building tips with Jasmine Anteunis, co-founder of startup Recast.ai","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670726/Blog/Hero%20Images/how-to-build-a-strong-developer-community.jpg","https://about.gitlab.com/blog/how-to-build-a-strong-dev-community","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to build a strong developer community\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2016-11-23\",\n      }",{"title":3360,"description":3361,"authors":3366,"heroImage":3362,"date":3367,"body":3368,"category":14},[2549],"2016-11-23","\nAfter meeting at Web Summit 2016, GitLab developer advocate [Amanda Folson](https://twitter.com/AmbassadorAwsum) sat down with Jasmine Anteunis of [Recast.ai](https://recast.ai/) to chat about how GitLab approaches community-building, including a deep dive on developer advocacy.\n\n\u003C!--more-->\n\nSome key takeaways include:\n\n* Public speaking is only one facet of [dev advocacy](/handbook/marketing/developer-relations/developer-evangelism/); nurturing communities is the most important thing.\n* It’s important that dev advocates aren’t just additional sales people. They should seek to be genuinely helpful for developers’ education and experience.\n* For people who happily use a competitor’s product, dev advocates should have a ready value proposition for whomever they’re speaking with (e.g. developer or manager).\n* It’s tough to put metrics to events, but you can develop “fuzzy metrics” like event attendees or traffic to certain site pages over time.\n\n**Jasmine: What exactly do developer advocates do?**\n{: .alert .alert-info}\n\n**Amanda:** It really depends on your product. The universal thing is finding out where the developers actually are, which is harder than it sounds sometimes. They may be hanging out in specific communities – we found out we have a lot of people in the JavaScript community, we’re starting to see more people in the PHP community, and we get a lot of attention in the [devops space](/topics/devops/) as well. I generally call ours the ‘spray and pray’ approach since developer relations is relatively new here. I’ll submit talks to a bunch of events, we’ll sponsor a few things, just to kind of see where we fit in and the kind of feedback we get. Public speaking is the most discussed facet of dev advocacy, but it’s only one of many. I spend a lot of time responding to people on Twitter – people ask me things or hit me up for stickers and our tanuki t-shirts.\n\nOnce you find developers, you want to work on nurturing those communities in any way you can, so we also do a lot of developer education stuff. I’m working with people in the PHP community to help solve their problems, but not necessarily in a way that means GitLab is the answer. I just gave a talk about scheduling on-call rotations to help prevent burnout, which has nothing to do with GitLab directly, but it provides a window to talk about things that are affecting developers.\n\n**Jasmine: So how does developer relations interact with the sales process?**\n{: .alert .alert-info}\n\n**Amanda:** I don’t ever want to approach developers like I’m selling something to them. The focus instead is to educate them and add value on something else, because it helps build a good relationship. Developers don’t really respond well to traditional marketing and sales. My job is really developer happiness. That means that I’m rarely selling them on GitLab itself, I’m finding something else that might meet their needs, so I need to have an understanding of that competitive analysis and be willing to speak frankly with them about it. The product marketing and content teams do a lot of things to take care of the buzz and lead generation. That works pretty well, because it’s not coming from a developer but developers still pay attention to it. And at events, if I’m talking to someone who starts asking pre-sales questions, I find a sales team member and bring them over.\n\n**Jasmine: How do you talk to people in the community who already use a competitor of yours, especially if they seem happy with that competitor?**\n{: .alert .alert-info}\n\n**Amanda:** We have value propositions that we give to explain why it’s better to use GitLab; this really depends on exactly whom you’re speaking with. If we’re talking to a manager then we talk to them about pricing and how GitLab might help their team perform better. We have a whole series of tools with messaging framed around each specific use case.\n\nFor developers, we talk about how we can help solve their problems. So, for example, GitHub has this issue where you kind of piece together your own experience. If you want to do testing, you have to bring in a secondary service like Jenkins or CircleCI or something. Or if you want to do issue tracking, previously they didn’t have any sort of issue board, and people had to bring in something like Trello. Because you had to go to all these secondary services to make GitHub work for you, our value proposition there is, “You don’t have to do that with GitLab.” We have all that stuff included; you need private repositories, great, GitLab.com is fine for you even if you want to run your unit tests and things like that.\n\n**Jasmine: If I talk to my CEO and have to make a plan for the next month for how to attract developers and keep them happy, how do I measure which actions are really impactful? For instance, how do I prove that networking with a few people at an event is worth the time spent?**\n{: .alert .alert-info}\n\n**Amanda:** That’s actually the million dollar question in developer relations, because it’s really hard to attach dollars to individual actions. You can do a lot with what we call “fuzzy metrics” because you’re not going to figure out the ROI of something like chatting with people at an event, but you can get a better sense of how you’re doing overall. For example, we look at the number of people who attend an event or your talk at a bigger event. That’s a fuzzy metric but it tells you something about your reputation in a community. For example, if you’re at a 3,000 person event, and only two people show up to your talk, then maybe you need to work on building up your reputation in that community. But, if 500 people at that 3,000 person event show up for your talk, then you’re doing pretty well. Similarly, if you spent $5,000 sending people and setting up a booth, but you land a $250,000 account, that was a great event for you.\n\nI like to put links to content in various places in my slides, and you can see how many people actually visit and click through. So for example, we had 50 people attend this talk and 70 people clicked this link, that means people probably shared it. We look a lot on social media as well – if we see a lot of unhappy people then we work on that; if we see a lot of happy people then that’s great feedback too. We also look at traffic over time to different things, like the forums or even different parts of the website. You might create a landing page for developers or some developer education topic, and you want to see that trend upward over time of course.\n\n**Jasmine: We are a small team, and our developers are also our support team and developer relations team. How does it work when support, developers, and dev relations are separate teams?**\n{: .alert .alert-info}\n\n**Amanda:**  There are a few ways this can work. Our support team now primarily takes care of our enterprise customers. They became too busy to respond to questions on social media, and our developer advocates also had a hard time managing questions from the broader community because we travel all the time for events. I have a personal policy of not having my head down in my laptop constantly at events, because I want to be free to talk to people while I’m there.\n\nSo we created a [community advocacy team](/handbook/marketing/developer-relations/developer-evangelism/). They do a lot of community management things like responding to people on the forum and on social media. The [interview process](/handbook/hiring/#sts=Interviewing) for that is very similar to the process for support; they need to have experience with Ruby, they need to be pretty technical, we like them to have some development experience. It has been a learning experience, but that’s how we tackled it.\n\n**Jasmine: If you had to choose, would you say it’s more important to devote resources to online engagement or to attending and sponsoring “real” events?**\n{: .alert .alert-info}\n\n**Amanda:**  The best approach is to do both, because one way is enterprise focused and the other is more grassroots focused. Enterprise includes large companies that might be willing to give you a lot of money, so you definitely want to be paying attention to them. The grassroots-focused events might be language specific, like PHP conferences and meetup groups. The enterprise group tends to respond more to the blog, press releases, and traditional marketing and sales stuff. Grassroots community members, on the other hand, appreciate the much more technical content; we’ve done a lot of posts on “Here’s how you use GitLab CI utility to run your tests and deploy your code.” The technical audience really responds to stuff like that, they also really like when someone is paying attention to them on the forum and online. If you had to pick one, you can get to both of those groups online. Ideally you would do both though, because it helps people to put a face to the name.\n\n**Jasmine: How do you recognize users who are influencers in your community? How do you identify them and make sure to keep them happy?**\n{: .alert .alert-info}\n\n**Amanda:**  We’re working on making this a bigger part of our strategy in 2017, but right now we recognize people who contribute a lot. Contributions come in various forms, but we have a [Hall of Fame](/community/mvp/) where we list the MVP from each release, along with people who contribute the most per month, for example. We actually tend to hire a lot of people who end up on that list, I think all of the top 20 now work at GitLab. We also pay attention to people who help out on the forum a lot, and people who don’t work for us but respond to questions on Stack Overflow and Twitter. We like rewarding people who boost the signal a little bit, we try to say thanks or send them swag, or we invite them to our Summit meeting. There’s no threshold for number of contributions, because it also depends on the nature of the contribution.\n\nUltimately we’ll create a group of ambassadors who want to talk about GitLab, at local meetup groups for example. We’re trying to create a system for sending them materials to help them get started. We’d like them to become developer advocates of a sort, in a way putting myself out of a job. We’re not paying them, they’re just doing it because they’re really passionate about the technology, which adds a bit of authenticity because they really care about what we’re doing.\n\n**Jasmine: What’s one last big tip you might give me?**\n{: .alert .alert-info}\n\n**Amanda:** Keep tabs on what’s going on in the broader tech community - I look at Hacker News a lot, and Reddit and Twitter as well. Definitely keep track of what people are talking about; this helps you strike up conversations at events and gives you a little bit of developer cred as well. If you’re a developer at all, then keep those skills sharp. Over the past three years I stopped really shipping code and I feel like it’s been detrimental. One of my goals for 2017 is to write more code so I can stay in the weeds in conversations. You’ll get lots of language-specific questions across the whole spectrum, so ideally you’ll be somewhat familiar with Ruby, JavaScript, golang, and PHP, and at least be willing to go look for the answers when you get questions. That’s where it helps to have a great network of people – I know people in the community who I can poke when I don’t know the answer to something and ask for help. So keep those skills up and look out for the next trend in technology; that way you can be ready to predict where developers are headed next.\n\n_Recast.AI is a french artificial intelligence startup focusing on conversational interfaces. Built on a strong language processing technology, Recast.AI allows developers to easily create their own bots through a collaborative platform and API._\n\n_Follow [Recast.ai](https://twitter.com/recastai) on Twitter._\n\n_Tweet [@GitLab](https://twitter.com/gitlab) and check out our [job openings](/jobs/)._\n",{"slug":3370,"featured":6,"template":679},"how-to-build-a-strong-dev-community","content:en-us:blog:how-to-build-a-strong-dev-community.yml","How To Build A Strong Dev Community","en-us/blog/how-to-build-a-strong-dev-community.yml","en-us/blog/how-to-build-a-strong-dev-community",{"_path":3376,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3377,"content":3383,"config":3388,"_id":3390,"_type":16,"title":3391,"_source":17,"_file":3392,"_stem":3393,"_extension":20},"/en-us/blog/gitpitch-slideshow-presentations-for-developers-on-gitlab",{"title":3378,"description":3379,"ogTitle":3378,"ogDescription":3379,"noIndex":6,"ogImage":3380,"ogUrl":3381,"ogSiteName":713,"ogType":714,"canonicalUrls":3381,"schema":3382},"GitPitch Slideshow Presentations for Developers on GitLab","Learn how PITCHME.md can help you present your ideas and code to any audience.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684126/Blog/Hero%20Images/cover.png","https://about.gitlab.com/blog/gitpitch-slideshow-presentations-for-developers-on-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitPitch Slideshow Presentations for Developers on GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David Russell\"}],\n        \"datePublished\": \"2016-10-03\",\n      }",{"title":3378,"description":3379,"authors":3384,"heroImage":3380,"date":3386,"body":3387,"category":14},[3385],"David Russell","2016-10-03","\n\nToday I would like to introduce [GitPitch](https://gitpitch.com), a slideshow presentation service for developers on [GitLab]().\nGitPitch supports building, sharing, and presenting online and offline slideshow presentations. Presentations powered entirely by Markdown and Git.\n\n\u003C!-- more -->\n\nAs developers and advocates, we often need to communicate with diverse audiences about our code.\nWe find ourselves needing to present everything from designs and best practices, to code snippets and complete frameworks.\nOur audiences include colleagues, clients, customers, end-users, and sometimes meetups and conferences.\n\nWith GitPitch, we no longer need to turn to external toolsets like Keynote or Powerpoint to prepare for these kinds of presentations.\nIn fact, now the only tools we need are the tools we live in, our preferred code editor and a GitLab repo.\nAnd with these tools we can quickly create compelling, responsive, online and offline slideshow presentations.\n\n![Slideshow-Master](https://about.gitlab.com/images/blogimages/gitpitch-slideshow-presentations-for-developers-on-gitlab/slideshow-master.jpg){: .shadow}\n\n## How GitPitch Works\n\nAs GitLab users, we are already familiar with the convention of adding a **README.md** to our projects.\nGitPitch introduces a new convention for GitLab users, called **PITCHME.md**.\n\nAs soon as we add a **PITCHME.md** markdown file to the root directory of our GitLab.com project, GitPitch instantly creates an online slideshow presentation based on the content in that file.\nThat slideshow presentation is then automatically made available at its public URL:\n\n```\nhttps://gitpitch.com/user/project/branch?grs=gitlab\n```\n\nHere `user` and `project` matches our GitLab.com user and project names respectively and `branch` matches the repository branch where we committed our **PITCHME.md** file.\nNote, the `/branch` can be omitted from the slideshow URL if we are referencing the `master` branch.\n\n## GitPitch In 60 Seconds\n\nTo experience just how simple it is to create a GitPitch slideshow presentation follow along with this short tutorial.\n\n### Step 1: Create **PITCHME.md**\n\nUsing the [GitLab web editor](https://gitlab.com/help/user/project/repository/web_editor.md), or your preferred code editor, create a file called **PITCHME.md** in the root directory of your repo, then add and save the following Markdown content:\n\n```\n# Flux\n\nAn application architecture for React\n\n#HSLIDE\n\n### Flux Design\n\n- Dispatcher: Manages Data Flow\n- Stores: Handle State & Logic\n- Views: Render Data via React\n\n#HSLIDE\n\n![Flux Explained](https://facebook.github.io/flux/img/flux-simple-f8-diagram-explained-1300w.png)\n```\n\nBefore moving on to the next step it's worthwhile to note the following:\n\n1. The **PITCHME.md** file name is case sensitive.\n1. The **PITCHME.md** file content is [standard Markdown](https://daringfireball.net/projects/markdown/syntax).\n1. The `#HSLIDE` markdown fragment acts as a delimiter between slides.\n\nUsing `#HSLIDE` is another GitPitch convention, acting as a delimiter to denote the separation between content on different slides in your presentation.\nYou can use [custom delimiters](https://github.com/gitpitch/gitpitch/wiki/Custom-Slide-Delimiters) if you prefer.\nFor this example, when GitPitch processes the Markdown content it will result in a simple presentation with just three slides.\n\n\n### Step 2: Commit **PITCHME.md**\n\nIf you used the GitLab web editor in step 1 then go directly to step 3.\nOtherwise, manually add this file to the root directory of your Git repo and push to GitLab:\n\n```\ngit add PITCHME.md\ngit commit -m \"Added my first GitPitch slideshow content.\"\ngit push\n```\n\n### Step 3: Done!\n\nYour GitPitch slideshow presentation is now waiting for you to share or present at its public URL.\nTo see a live demonstration of this slideshow presentation [click here](https://gitpitch.com/gitpitch/in-60-seconds?grs=gitlab).\nYour own presentation should look a lot like this:\n\n![Slideshow-In-60-Seconds](https://about.gitlab.com/images/blogimages/gitpitch-slideshow-presentations-for-developers-on-gitlab/slideshow-in-60-seconds.jpg){: .shadow}\n\nImmediately you can [download](https://github.com/gitpitch/gitpitch/wiki/Slideshow-Offline) your slideshow for offline presentation, [print](https://github.com/gitpitch/gitpitch/wiki/Slideshow-Printing) it as a PDF document, or [share](https://github.com/gitpitch/gitpitch/wiki/Slideshow-Sharing) it on social media.\nBut first, you might want to apply some personal touches using GitPitch customization, the topic we'll look at next.\n\nNote that beyond support for standard Markdown on presentation slides, GitPitch delivers a number of features tailored for developers, including support for [code blocks](https://github.com/gitpitch/gitpitch/wiki/Code-Slides), [GitHub GIST](https://github.com/gitpitch/gitpitch/wiki/GIST-Slides), [math formulas](https://github.com/gitpitch/gitpitch/wiki/Math-Notation-Slides) along with [image](https://github.com/gitpitch/gitpitch/wiki/Image-Slides), and [video](https://github.com/gitpitch/gitpitch/wiki/Video-Slides) support.\nThe full set of GitPitch features are documented on the [GitPitch Wiki](https://github.com/gitpitch/gitpitch/wiki).\nTo see a live slideshow demonstration of these features try out the GitPitch [Kitchen Sink](https://gitpitch.com/gitpitch/kitchen-sink?grs=gitlab).\n\n\n## GitPitch Customization\n\n\nAs with any presentation, a GitPitch presentation not only needs to capture and render compelling content, it also needs to be able to reflect the style, image or brand of the associated project, product or organization.\nTo help us develop a strong visual identity for our slideshow presentations, GitPitch offers six distinct visual themes out-of-the-box.\nSee the [GitPitch Themes](https://github.com/gitpitch/gitpitch/wiki/Theme-Setting) Wiki page to learn more.\n\n![Slideshow-Night-Theme](https://about.gitlab.com/images/blogimages/gitpitch-slideshow-presentations-for-developers-on-gitlab/slideshow-night-theme.jpg){: .shadow}\n\nBuilding on these base themes we can further [customize the look and feel](https://github.com/gitpitch/gitpitch/wiki/Slideshow-Settings) of our slideshow presentations using background images, our own logo, and even custom CSS to bend the pixels to our needs.\n\n![Slideshow-Custom-Bg](https://about.gitlab.com/images/blogimages/gitpitch-slideshow-presentations-for-developers-on-gitlab/slideshow-custom-bg.jpg){: .shadow}\n\n## GitPitch and GitLab Workflow\n\nThe **PITCHME.md** markdown for our slideshow presentation becomes just another file in our GitLab project repo.\nTherefore all of the benefits we currently enjoy when working with GitLab Workflow apply equally when developing our slideshow presentations.\n\nGiven GitPitch can render a slideshow presentation for any branch within a public GitLab repo, using feature branches also offers an excellent way to customize a presentation's content for different target audiences. For example:\n\n1. Branch to tailor code snippets for a Scala rather than Java audience.\n2. Branch to adjust the presentation focus for a dev-ops audience.\n3. Branch to emphasize participation of a partner or customer for a specific conference.\n\nSome common, in-person workflows are also greatly improved when working with GitPitch presentations.\nFor example, how often have you heard this simple request following a successful presentation:\n\n> Can you please send me your slides?\n\nIf our presentation lives outside of our GitLab project it is very easy to misplace or forget to follow up.\nWith GitPitch, a simple answer is always at hand:\n\n> The slideshow presentation is part of the project on GitLab, just click on the [GitPitch Badge](https://github.com/gitpitch/gitpitch/wiki/Slideshow-GitHub-Badge) found in the project **README.md**.\n\n\n## Going Faster from Idea to Presentation\n\n\nGitLab champions new, modern development tools and practices that foster collaboration and information sharing to help developers go [faster from idea to production](/blog/announcing-the-gitlab-issue-board/#gitlab-from-idea-to-production).\nGitPitch embraces and extends this approach by helping individuals, teams and organizations to promote, pitch and present their ideas and code to ever wider audiences.\n\nNote, by default the GitPitch service on [GitPitch.com](https://gitpitch.com) integrates with [GitLab.com](https://gitlab.com).\nIf you are interested in using GitPitch with your own GitLab server see [this note](https://github.com/gitpitch/gitpitch/wiki/Git-Repo-Services) on the GitPitch Wiki.\n\nLike GitLab, GitPitch itself is an [open source project](https://gitlab.com/gitpitch/gitpitch), built on some wonderful open source software.\nSee the [GitPitch website](https://gitpitch.com/#gitpitch-about) for details. And remember, getting started couldn't be easier.\nGitPitch requires no sign-up. And no configuration. Just add **PITCHME.md** ;)\n\n## About Guest Author\n\nDavid Russell is a freelance developer, consultant for-hire, [open source contributor](https://github.com/onetapbeyond) and the creator of [GitPitch](https://gitpitch.com).\nYou can reach David on Twitter [@gitpitch](https://twitter.com/gitpitch).\n",{"slug":3389,"featured":6,"template":679},"gitpitch-slideshow-presentations-for-developers-on-gitlab","content:en-us:blog:gitpitch-slideshow-presentations-for-developers-on-gitlab.yml","Gitpitch Slideshow Presentations For Developers On Gitlab","en-us/blog/gitpitch-slideshow-presentations-for-developers-on-gitlab.yml","en-us/blog/gitpitch-slideshow-presentations-for-developers-on-gitlab",{"_path":3395,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3396,"content":3402,"config":3407,"_id":3409,"_type":16,"title":3410,"_source":17,"_file":3411,"_stem":3412,"_extension":20},"/en-us/blog/trends-in-version-control-land-open-source",{"title":3397,"description":3398,"ogTitle":3397,"ogDescription":3398,"noIndex":6,"ogImage":3399,"ogUrl":3400,"ogSiteName":713,"ogType":714,"canonicalUrls":3400,"schema":3401},"Trends in Version Control Land: Open Source","In this final post, I’d like to share my thoughts on an exciting new trend: open source practices expanding into a variety of industries.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683589/Blog/Hero%20Images/sunset.jpg","https://about.gitlab.com/blog/trends-in-version-control-land-open-source","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Trends in Version Control Land: Open Source\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n        \"datePublished\": \"2016-08-29\",\n      }",{"title":3397,"description":3398,"authors":3403,"heroImage":3399,"date":3405,"body":3406,"category":14},[3404],"Sid Sijbrandij","2016-08-29","\n\nEarlier in this series, we explained how [innersourcing][post-1] can solve\ncommon enterprise challenges, the benefits of\n[releasing early and often][post-2], and the efficiency of\n[microservices architecture][post-3]. In this final post, I’d like to\nshare my thoughts on an exciting new trend: **open source** practices expanding into a variety of industries.\nOver the past year, we've seen more and more companies are engaging with open source.\n\n\u003C!-- more -->\n\nIt turns out that as more companies become comfortable with the implications\nof open source - loosening control in exchange for more productive collaboration — open source is turning out to be an incredibly useful\nsolution in a number of industries. In fact, according to the 2016\n[Future of Open Source Survey][survey], **90%** of respondents say open source improves efficiency,\nand **65%** contribute to open source projects.\n\nThere's been a shift toward open source across the board, and there are a few key reasons why this is happening.\n\n**1. When a lot of people use it, open source just makes sense.**\n{: .alert .alert-success}\n\nWhen a lot of people use a program, there's greater opportunity\nto crowdsource feedback and solutions from users. Therefore, [going open source][open-source-who] offers\na shortcut to improvement.\n\nSoftware that’s used by the majority of a large company, for example, is\nlikely to become open source, as is software that’s very popular within a\nparticular sector. More and more, enterprise infrastructure is becoming open\nsource, including networking programs, security scanning, ERP, etc.\n\n**2. If a lot of companies use it, open source makes even more sense.**\n{: .alert .alert-success}\n\nWhen there’s a software solution that can serve a lot of different needs,\nand thus is adopted by [a lot of different companies][open-source-companies], then\nit will likely become open source. The same rule applies as above\n(more users = shortcut to improvement), but broad international use\nintensifies this effect, where having a strong reputation among developers\nand the ability to facilitate collaborative development will drive interest\nin open source. We [saw this happen with, e.g., Linux][open-source-linux].\n\n**3. If it’s close to developers, it’ll become open source.**\n{: .alert .alert-success}\n\nSoftware that’s close to people who actually have the skill set to\nimprove on it is very likely to go open source. If a developer has\nan issue with the software, they can scratch that itch and fix it,\n_bing-bang-boom!_ 💥 This is the beauty of open source. Not surprisingly,\nthis happens most often in verticals like development tooling. It also\nhelps that in verticals that are close to developers, decision\nmakers are likely to include those who understand the value of open\nsource, making it a faster leap.\n\nReally, the only software that is likely to stay proprietary is something\nthat is used by very small or specific groups. This includes verticals like oil and\ngas or healthcare. Although, even in [healthcare, open source is happening](https://en.wikipedia.org/wiki/List_of_open-source_health_software) — it’s\njust happening more slowly, and it may not affect everyone.\n\nHave you spotted a [version control](/topics/version-control/) trend that you want to share or that\nyou’d like us to write about? Let us know! Comment or tweet at us [@GitLab].\n\n\u003C!-- Identifiers, in alphabetical order -->\n\n[@GitLab]: https://twitter.com/gitlab\n[open-source-companies]: https://en.wikipedia.org/wiki/List_of_free_and_open-source_software_packages\n[open-source-linux]: https://en.wikipedia.org/wiki/Open-source_software#Open-source_software_development\n[open-source-who]: http://www.makeuseof.com/tag/people-contribute-open-source-projects/\n[post-1]: /topics/version-control/what-is-innersource/\n[post-2]: /blog/release-early-release-often/\n[post-3]: /2016/08/16/trends-in-version-control-land-microservices/\n[survey]: https://www.blackducksoftware.com/2016-future-of-open-source\n\n\n\u003Cstyle>\n  .alert-success {\n    color: rgb(60,118,61) !important;\n  }\n\u003C/style>\n",{"slug":3408,"featured":6,"template":679},"trends-in-version-control-land-open-source","content:en-us:blog:trends-in-version-control-land-open-source.yml","Trends In Version Control Land Open Source","en-us/blog/trends-in-version-control-land-open-source.yml","en-us/blog/trends-in-version-control-land-open-source",{"_path":3414,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3415,"content":3421,"config":3426,"_id":3428,"_type":16,"title":3429,"_source":17,"_file":3430,"_stem":3431,"_extension":20},"/en-us/blog/moving-to-gitlab-yes-its-worth-it",{"title":3416,"description":3417,"ogTitle":3416,"ogDescription":3417,"noIndex":6,"ogImage":3418,"ogUrl":3419,"ogSiteName":713,"ogType":714,"canonicalUrls":3419,"schema":3420},"Customer Story: Moving to GitLab! Yes, it's worth it!","Migrating from GitHub to GitLab and setting up your own GitLab instance","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665885/Blog/Hero%20Images/love-the-sun-gitlab.jpg","https://about.gitlab.com/blog/moving-to-gitlab-yes-its-worth-it","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Customer Story: Moving to GitLab! Yes, it's worth it!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fabio Akita\"}],\n        \"datePublished\": \"2016-08-04\",\n      }",{"title":3416,"description":3417,"authors":3422,"heroImage":3418,"date":3424,"body":3425,"category":14},[3423],"Fabio Akita","2016-08-04","\n\n**Note:** This post is a customer story on the benefits of migrating from GitHub to GitLab, by Fabio Akita, a Brazilian Rubyist.\n{: .note}\n\nI started [evangelizing Git in 2007][evang]. It was a very tough sell to make at the time.\n\nOutside of the kernel development almost no one wanted to learn it and we had very worthy competitors, from Subversion, to Mercurial, to Bazaar, to Darcs, to Perforce, and so on. But those of use that dug deeper knew that Git had the edge and it was a matter of time.\n\nThen GitHub showed up in 2008 and the rest is history. For many years it was just \"cool\" to be in GitHub. The Ruby community drove GitHub up into the sky. Finally it became the status quo and the one real monopoly in information repositories - not just software source code, but everything.\n\nI always knew that we should have a \"local\" option, which is why I tried to [contribute to Gitorious][gitorious] way back in 2009. Other options arose, but eventually GitLab appeared around 2011 and picked up steam in the last couple of years.\n\nGitHub itself raised [USD 350 million in funding][gh-fund] and one of its required goals is to nail the Enterprise Edition for big corporations that don't want their data outside their closed gardens. Although GitHub hosts every single open source project out there, they are themselves closed-source.\n\n[GitLab Inc.][GL] started differently with an open source-first approach with their Community Edition (CE) and having both a GitHub-like hosted option as well as a supported Enterprise Edition for fearsome corporations. They already raised [USD 5.62 million in funding][gl-fund], and they are the most promising alternative to GitHub so far.\n\n\u003C!-- more -->\n\nOf course, there are other platforms such as Atlassian's Bitbucket. But I believe Atlassian's strategy is slower and they have a larger suite of enterprise products to sell first, such as Confluence and Jira. I don't think they ever posed much of a competition against GitHub.\n\nGitLab really started accelerating in 2015 as this [commit graph][comm-graph] shows:\n\n![contributors to gitlabhq](https://about.gitlab.com/images/blogimages/moving-to-gitlab-yes-its-worth-it/contributors-to-gitlabhq.png){: .shadow}\n\nIt's been steadily growing since 2011, but they seem to have crossed the first tipping point around late 2014, from early adopters to the early majority. This became more important as **GitHub** announced their [pricing changes][gh-prices] in May.\n\nThey said they haven't committed to a dead line to enforce the change, so organizations can opt out of the new format for the time being. They are changing from \"limited repositories and unlimited users\" to \"unlimited repositories and limited users\".\n\n## The Cost-Benefit Conundrum\n\nFor example, if you have up to 8 developers in the USD 50/month (20 private repositories), the change won't affect you, as you will pay USD 25/month for 5 users and USD 9 for additional users (total of USD 52/month).\n\nNow, if you have a big team of 100 developers currently in the Diamond Plan of USD 450/month (300 private repositories), you would have to pay USD 25/month + 95 times USD 9, which totals a staggering USD 880/month! **Double the amount!**\n\nThis is an **extra USD 10,560** per year!\n{: .alert .alert-danger}\n\nAnd what does **GitLab** affords you instead?\n\nYou can have way more users and more repositories in a **USD 40/month** virtual box (4GB of RAM, 60GB SSD, 4TB transfer).\n{: .alert .alert-success}\n\nAnd it doesn't stop there. GitLab also has very functional [GitLab Multi Runner][runner] which you can install in a separate box (actually, at least 3 boxes - more on that below).\n\nYou can easily connect this runner to the build system over GitLab so every new git push trigger the runner to run the automated test suite in a Docker image of your choosing. So it's a fully functional, full featured Continuous Integration system nicely integrated in your GitLab project interface:\n\n![pipelines](https://about.gitlab.com/images/blogimages/moving-to-gitlab-yes-its-worth-it/pipelines-cm42-archived-gitlab.png){: .shadow}\n\n![builds](https://about.gitlab.com/images/blogimages/moving-to-gitlab-yes-its-worth-it/test-144-builds-cm42-archived-gitlab.png){: .shadow}\n\nReminds of you anything? Yep, it's a fully functional alternative to Travis-CI, Semaphore, CircleCI or any other CI you're using with a very easy to install procedure. Let's say you're paying **Travis-CI USD 489/month to have 10 concurrent jobs**.\n\nYou can install **GitLab Runner** in **3 boxes of USD 10/month** (1GB RAM, 1 Cores, 30GB SSD) and have way more concurrent jobs (20? 50? Auto-Scale!?) that **runs faster** (in a simple test, one build took 15 minutes over Travis took less than 8 minutes at Digital Ocean).\n\nSo let's make the math for a year's worth of service. First considering no GitHub plan change:\n\nUSD 5,400 (**GitHub**) + USD 5,868 (**Travis**) = **USD 11,268 a year**.\n{: .alert .alert-danger}\n\nNow, the GitLab + GitLab Runner + Digital Ocean for the same features and unlimited users, unlimited repositories, unlimited concurrent builds:\n\nUSD 480 (**GitLab**) + USD 840 (**Runner box**) = **USD 1,320 a year**.\n{: .alert .alert-success}\n\nThis is already **almost 8.5x cheaper** with almost **no change in quality**.\n\nFor the worst case scenario, compare it when **GitHub** decides to enforce the new plans:\n\nUSD 10,560 (**GitHub new plans**) + USD 5,868 (**Travis**) = **USD 16,428**\n{: .alert .alert-danger}\n\nNow the **GitLab** option is **11x cheaper**! You're **saving almost USD 15,000 a year!** This is not something you can ignore in your cost sheet.\n{: .alert .alert-success}\n\nAs I said, the calculations above are only significant in a scenario of a 100 developers. You must do your own math taking into account your team size and number of active projects (you can always archive unused projects).\n\nEven if you don't have 100 developers. Let's consider the scenario for 30 developers in the new GitHub per user plans and a smaller Travis configuration for 5 concurrent jobs:\n\nUSD 3,000 (**GitHub new plan**) + USD 3,000 (**Travis**) = **USD 6,000**\n{: .alert .alert-danger}\n\nIt's **4.5x cheaper** in the **Digital Ocean + GitLab** suite option.\n{: .alert .alert-success}\n\nHeck, let's consider the Current **GitHub** plan (the Platinum one, for up to 125 repositories):\n\nUSD 2,400 (**GitHub current plan**) + USD 3,000 (**Travis**) = **USD 5,400**\n{: .alert .alert-danger}\n\nStill **at least 4x more expensive** than a **GitLab-based** solution!\n{: .alert .alert-success}\n\nAnd how long will it take for a single developer to figure out the set up and migrate everything from GitHub over to the new **GitLab** installation? I will say that you can reserve 1 week of work for the average programmer to do it following the official documentation and my tips and tricks below.\n\n## Installing GitLab CE\n\nI will not bore you with what you can readily find over the Web. I highly recommend you start with the easiest solution first: [Digital Ocean's One-Click Automatic Install][do-inst]. Install it in at least a 4GB RAM machine (you will want to keep it if you like it).\n\nOf course, there is a number of different installation options, from AWS AMI images to Ubuntu packages you can install manually. Study the [documentation].\n\nIt will cost you **USD 40 for a month of trial**. If you want to **save** as much as **tens of thousands of dollar**, this is a bargain.\n\nGitLab has many customization options. You can lock down your private GitLab to allow only users with an official e-mail from your domain, for example. You can configure [OAuth2 providers][omni-auth] so your users can quickly sign in using their GitHub, Facebook, Google or other accounts.\n\n### A Few Gotchas\n\nI've stumbled upon a few caveats in the configuration. Which is why I recommend that you plan ahead - study this entire article ahead of time! -, do a quick install that you can blow away, so you can \"feel\" the environment before trying to migrate all your repos over to your brand new GitLab. As a reference, this is a part of my `/etc/gitlab/gitlab.rb`:\n\n```shell\n# register a domain for your server and place it here:\nexternal_url \"http://my-gitlab-server.com/\"\n\n# you will want to enable [LFS](https://git-lfs.github.com)\ngitlab_rails['lfs_enabled'] = true\n\n# register your emails\ngitlab_rails['gitlab_email_from'] = \"no-reply@my-gitlab-server.com\"\n\n# add your email configuration (template for gmail)\ngitlab_rails['smtp_enable'] = true\ngitlab_rails['smtp_address'] = \"smtp.gmail.com\"\ngitlab_rails['smtp_port'] = 587\ngitlab_rails['smtp_user_name'] = \"-- some no-reply email ---\"\ngitlab_rails['smtp_password'] = \"-- the password ---\"\ngitlab_rails['smtp_domain'] = \"my-gitlab-server.com\"\ngitlab_rails['smtp_authentication'] = \"login\"\ngitlab_rails['smtp_enable_starttls_auto'] = true\ngitlab_rails['smtp_openssl_verify_mode'] = 'peer'\n\n# this is where you enable oauth2 integration\ngitlab_rails['omniauth_enabled'] = true\n\n# CAUTION!\n# This allows users to login without having a user account first. Define the allowed providers\n# using an array, e.g. [\"saml\", \"twitter\"], or as true/false to allow all providers or none.\n# User accounts will be created automatically when authentication was successful.\ngitlab_rails['omniauth_allow_single_sign_on'] = ['github', 'google_oauth2', 'bitbucket']\ngitlab_rails['omniauth_block_auto_created_users'] = true\n\ngitlab_rails['omniauth_providers'] = [\n  {\n    \"name\" => \"github\",\n    \"app_id\" => \"-- github app id --\",\n    \"app_secret\" => \"-- github secret --\",\n    \"url\" => \"https://github.com/\",\n    \"args\" => { \"scope\" => \"user:email\" }\n  },\n  {\n    \"name\" => \"google_oauth2\",\n    \"app_id\" => \"-- google app id --\",\n    \"app_secret\" => \"-- google secret --\",\n    \"args\" => { \"access_type\" => \"offline\", \"approval_prompt\" => '', hd => 'codeminer42.com' }\n  },\n  {\n    \"name\" => \"bitbucket\",\n    \"app_id\" => \"-- bitbucket app id --\",\n    \"app_secret\" => \"-- bitbucket secret id --\",\n    \"url\" => \"https://bitbucket.org/\"\n  }\n]\n\n# if you're importing repos from GitHub, Sidekiq workers can grow as high as 2.5GB of RAM and the default [Sidekiq Killer](https://docs.gitlab.com/ee/operations/sidekiq_memory_killer.html) config will cap it down to 1GB, so you want to either disable it by adding '0' or adding a higher limit\ngitlab_rails['env'] = { 'SIDEKIQ_MEMORY_KILLER_MAX_RSS' => '3000000' }\n```\n\nThere are [dozens of default variables][vars] you can [override], just be careful on your testings.\n\nEvery time you change a configuration, you can just run the following commands:\n\n```shell\nsudo gitlab-ctl reconfigure\nsudo gitlab-ctl restart\n```\n\nYou can open a Rails console to inspect production objects like this:\n\n```shell\ngitlab-rails console\n```\n\nI had a lot of trouble importing big repos from GitHub, but after a few days debugging the problem with GitLab Core Team developers [Douglas Alexandre][douglas], [Gabriel Mazetto][gabriel], a few Merge Requests and some local patching and I was finally able to import relatively big projects (more than 5,000 commits, more than 1,000 issues, more than 1,200 pull requests with several comments worth of discussion threads). A project of this size can take a couple of hours to complete, mainly because it's damn slow to use GitHub's public APIs (they are slow and they have rate limits and abuse detection, so you can't fetch everything as fast as your bandwidth would allow).\n\n(By the way, don't miss GitLab will be over at [Rubyconf Brazil 2016][conf], on Sep 23-24)\n\nMigrating all my GitHub projects took a couple of days, but they all went through smoothly and my team didn't have any trouble, just adjusting their git remote URLs and they're done.\n\nThe import procedure from GitHub is quite complete, it brings not only the git repo per se, but also all the metadata, from labels to comments and pull request history - which is the one that usually takes more time.\n\nBut I'd recommend waiting for at least version 8.11 (it's currently 8.10.3) before trying to import large GitHub projects.\n\nIf you're on Bitbucket, unfortunately there are less features in the importer. It will mostly just bring the source code. So be aware of that if you extensively depend on their pull request system and you want to preserve this history. More feature will come and you can even help them out, they are very resourceful and willing to make GitLab better.\n\n## Side-track: Customizations for every Digital Ocean box\n\nAssume that you should run what's in this section for all new machines you create over Digital Ocean.\n\nFirst of all, they come without a swap file. No matter how much RAM you have, the Linux OS is meant to work better by combining a swap file. You can [read more about it][do-ub] later, for now just run the following as root:\n\n```shell\nfallocate -l 4G /swapfile\nchmod 600 /swapfile\nmkswap /swapfile\nswapon /swapfile\n\nsysctl vm.swappiness=10\nsysctl vm.vfs_cache_pressure=50\n```\n\nEdit the `/etc/fstab` file and add this line:\n\n```shell\n/swapfile   none    swap    sw    0   0\n```\n\nDon't forget to set the [default locale][locale] of your machine. Start by editing the `/etc/environment` file and adding:\n\n```shell\nLC_ALL=en_US.UTF-8\nLANG=en_US.UTF-8\n```\n\nThen run:\n\n```shell\nsudo locale-gen en_US en_US.UTF-8\nsudo dpkg-reconfigure locales\n```\n\nFinally, you should have Ubuntu automatically install stable security patches for you. You don't want to forget machines online without the most current security fixes, so just run this:\n\n```shell\nsudo dpkg-reconfigure --priority=low unattended-upgrades\n```\n\nChoose \"yes\" and you're done. And of course, for every fresh install, it's always good to run the good old:\n\n```shell\nsudo apt-get update && sudo apt-get upgrade\n```\n\nThis is the very basics, I believe it's easier to have an image with all this ready, but if you use the standard Digital Ocean images, these settings should do the trick for now.\n\n## Installing the CI Runner\n\nOnce you finish your GitLab installation, it's [super easy][inst-gl-run] to deploy the GitLab Runner. You can use the same machine but I recommend you install it in a separate machine.\n\nIf you don't know what a runner is, just imagine it like this: It's basically a server connected to the GitLab install. When it's available and online, whenever someone pushes a new commit, merge request, to a repository that has a `gitlab-ci-yml` file present, GitLab will push a command to the runner.\n\nDepending on how you configured the runner, it will receive this command and spawn a new Docker container. Inside the container it will execute whatever you have defined in the `gitlab-ci.yml` file in the project. Usually it's fetching cached files (dependencies, for example), and run your test suite.\n\nIn the most basic setup, you will only have one Runner and any subsequent builds from other users will wait in line until they finish. If you've used external CI services such as Travis-CI or CircleCI, you know that they charge for some number of concurrent builds. And it's **very expensive**.\n\nThe less concurrent builds available, the more your users will have to wait for feedback on their changes, and less productive you will become. People may even start to avoid adding new tests, or completely ignore the tests, which will really hurt the quality of your project over time. If there is one thing you **must not** do is not having good automated test suites.\n\nGabriel Mazetto pointed me to a very important GitLab CI Runner feature: [auto-scaling]. This is what they use in their hosted offering over at [GitLab.com].\n\nYou can easily set up a runner that can use \"docker-machine\" and your IaaS provider APIs to spin up machines on the fly to run as many concurrent builds as you want, and it will be super cheap!\n\nFor example, on Digital Ocean you can be charged USD 0.06 (6 cents) per hour of usage of a 4GB machine. Over at AWS EC2 you can be charged USD 0.041 per hour for an m3.medium machine.\n\nThere is extensive documentation but I will try to summarize what you have to do. For more details I highly recommend you to study their [official documentation][doc-runner].\n\nStart by creating 3 new machines at Digital Ocean, all in the same Region with private networking enabled! I will list a fake private IP address just for the sake of advancing in the configuration examples:\n\n- a 1GB machine called \"docker-registry-mirror\", (ex 10.0.0.1)\n- a 1GB machine called \"ci-cache\", (ex 10.0.0.2)\n- a 1GB machine called \"ci-runner\", (ex 10.0.0.3)\n\nYeah, they can be small as very little will run on them. You can be conservative and choose the 2GB RAM options just to be on the safe side (and pricing will still be super cheap).\n\nDon't forget to execute the basic configuration I mentioned above to enable a swapfile, auto security update and locale regeneration.\n\nSSH in to \"docker-registry-mirror\" and just run:\n\n```shell\ndocker run -d -p 6000:5000 \\\n    -e REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io \\\n    --restart always \\\n    --name registry registry:2\n```\n\nNow you will have a local Docker images registry proxy and cache at 10.0.0.1:6000 (take note of the real private IP).\n\nSSH in to \"ci-cache\" and run:\n\n```shell\nmkdir -p /export/runner\n\ndocker run -it --restart always -p 9005:9000 \\\n        -v /.minio:/root/.minio -v /export:/export \\\n        --name minio \\\n        minio/minio:latest /export\n```\n\nNow you will have an AWS S3 clone called [Minio] running. I didn't know this project even existed, but it is a nifty little service written in Go to clone the AWS S3 behavior and APIs. So now you can have your very own S3 inside your infrastructure!\n\nAfter Docker spin ups, it will print out the Access Key and Secret keys, make notes. And this service will be running at `10.0.0.2:9005`.\n\nYou can even open a browser and see their web interface at `http://10.0.0.2:9005` and use the access and secret keys to login. Make sure you have a bucket named \"runner\". The files will be stored at the `/export/runner` directory.\n\n![Minio browser](https://about.gitlab.com/images/blogimages/moving-to-gitlab-yes-its-worth-it/minio-browser.png){: .shadow}\n\nMake sure the [bucket name is valid][bucket] (it must be a valid DNS naming, for example, **DO NOT use underlines**).\n\nOpen this URL from your freshly installed **GitLab CE**: `http://yourgitlab.com/admin/runners` and take note of the **Registration Token**. Let's say it's `1aaaa_Z1AbB2CdefGhij`\n\n![admin area](https://about.gitlab.com/images/blogimages/moving-to-gitlab-yes-its-worth-it/admin-area-gitlab.png){: .shadow}\n\nFinally, SSH in to \"ci-runner\" and run:\n\n```shell\ncurl -L https://github.com/docker/machine/releases/download/v0.7.0/docker-machine-`uname -s`-`uname -m` > /usr/local/bin/docker-machine\n\nchmod +x /usr/local/bin/docker-machine\n\ncurl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash\n\nsudo apt-get install gitlab-ci-multi-runner\n\nrm -Rf ~/.docker # just to make sure\n```\n\nNow you can register this new runner with your GitLab install, you will need the Registration Token mentioned above.\n\n```shell\nsudo gitlab-ci-multi-runner register\n```\n\nYou will be asked a few questions, and this is what you can answer:\n\n```shell\nPlease enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/ci )\nhttps://yourgitlab.com/ci\nPlease enter the gitlab-ci token for this runner\n1aaaa_Z1AbB2CdefGhij # as in the example above\nPlease enter the gitlab-ci description for this runner\nmy-autoscale-runner\nINFO[0034] fcf5c619 Registering runner... succeeded\nPlease enter the executor: shell, docker, docker-ssh, docker+machine, docker-ssh+machine, ssh?\ndocker+machine\nPlease enter the Docker image (eg. ruby:2.1):\ncodeminer42/ci-ruby:2.3\nINFO[0037] Runner registered successfully. Feel free to start it, but if it's\nrunning already the config should be automatically reloaded!\n```\n\nLet's make a copy of the original configuration, just to be safe:\n\n```shell\ncp /etc/gitlab-runner/config.toml /etc/gitlab-runner/config.bak\n```\n\nCopy the first few lines of this file (you want the token), it will look like this:\n\n```shell\nconcurrent = 1\ncheck_interval = 0\n\n[[runners]]\n  name = \"my-autoscale-runner\"\n  url = \"http://yourgitlab.com/ci\"\n  token = \"--- generated runner token ---\"\n  executor = \"docker+machine\"\n```\n\nThe important part here is the \"token\". You will want to take note of it. And now you also will want to create a [new API Token over at Digital Ocean][do-tok]. Just Generate a New Token and take note.\n\nYou can now replace the entire `config.toml` file for this:\n\n```toml\nconcurrent = 20\ncheck_interval = 0\n\n[[runners]]\n  name = \"my-autoscale-runner\"\n  url = \"http://yourgitlab.com/ci\"\n  token = \"--- generated runner token ---\"\n  executor = \"docker+machine\"\n  limit = 15\n  [runners.docker]\n    tls_verify = false\n    image = \"codeminer42/ci-ruby:2.3\"\n    privileged = false\n  [runners.machine]\n    IdleCount = 2                   # There must be 2 machines in Idle state\n    IdleTime = 1800                 # Each machine can be in Idle state up to 30 minutes (after this it will be removed)\n    MaxBuilds = 100                 # Each machine can handle up to 100 builds in a row (after this it will be removed)\n    MachineName = \"ci-auto-scale-%s\"   # Each machine will have a unique name ('%s' is required)\n    MachineDriver = \"digitalocean\"  # Docker Machine is using the 'digitalocean' driver\n    MachineOptions = [\n        \"digitalocean-image=coreos-beta\",\n        \"digitalocean-ssh-user=core\",\n        \"digitalocean-access-token=-- your new Digital Ocean API Token --\",\n        \"digitalocean-region=nyc1\",\n        \"digitalocean-size=4gb\",\n        \"digitalocean-private-networking\",\n        \"engine-registry-mirror=http://10.0.0.1:6000\"\n    ]\n  [runners.cache]\n    Type = \"s3\"   # The Runner is using a distributed cache with Amazon S3 service\n    ServerAddress = \"10.0.0.2:9005\"  # minio\n    AccessKey = \"-- your minio access key --\"\n    SecretKey = \"-- your minio secret key\"\n    BucketName = \"runner\"\n    Insecure = true # Use Insecure only when using with Minio, without the TLS certificate enabled\n```\n\nAnd you can restart the runner to pick up the new configuration like this:\n\n```shell\ngitlab-ci-multi-runner restart\n```\n\nAs I said before, you will want to read the extensive [official documentation][auto-sc-doc] (and every link within).\n\nIf you did everything right, changing the correct private IPs for the docker registry and cache, the correct tokens, and so forth, you can log in to your Digital Ocean dashboard and you will see something like this:\n\n![DO droplets](https://about.gitlab.com/images/blogimages/moving-to-gitlab-yes-its-worth-it/digital-ocean-droplets.png){: .shadow}\n\nAnd from the `ci-runner` machine, you can list them like this:\n\n```shell\n# docker-machine ls\n\nNAME                                    ACTIVE        DRIVER   STATE     URL            SWARM   DOCKER    ERRORS\nrunner-xxxx-ci-auto-scale-xxxx-xxxx  -  digitalocean  Running  tcp://191.168.0.1:237    v1.10.3\nrunner-xxxx-ci-auto-scale-xxxx-xxxx  -  digitalocean  Running  tcp://192.169.0.2:2376   v1.10.3\n```\n\nThey should not list any errors, meaning that they are up and running, waiting for new builds to start.\n\nThere will be 2 new machines listed in your Digital Ocean dashboard, named \"runner-xxxxx-ci-auto-scale-xxxxx\". This is what `IdleCount = 2` does. If they stay idle for more than 30 minutes (`IdleTime = 1800`) they will be shut down so you don't get charged.\n\nYou can have several \"runner\" definitions, each with a `limit` of builds/machines that can be spawned in Digital Ocean. You can have other runner definitions for other providers, for example. But in this example we are limited to at most 15 machines, so 15 concurrent builds.\n\nThe `concurrent` limit is a global setting. So if I had 3 runner definitions, each with a `limit` of 15, they would still be globally limited to 20 as defined in the `concurrent` global variable.\n\nYou can use different providers for specific needs, for example, to run macOS builds or Raspberry Pi builds or other exotic kinds of builds. In the example I am keeping it simple and just setting many builds in the same provider (Digital Ocean).\n\nAnd don't worry about the monthly fee for each machine. When used in this manner, you will be paying per hour.\n\nAlso, make sure you spun up all your machines (docker-registry, minio cache, CI runner) all with private networking enabled (so they talk through the internal VLAN instead of having to go all the way through the public internet) and that they are all in the same region data center (NYC1 is New York 1 - New York has 3 sub-regions, for example). Don't start machines in different regions.\n\nBecause we have Docker proxy/cache and Minio/S3 cache, your builds will take longer the first time (let's say, 5 minutes), and then subsequent build will fetch everything from the cache (taking, let's say, 1:30 minute). It's fast and it's convenient.\n\n## Setting up each Project for the Runner\n\nThe Runner is one of the newest pieces of the GitLab ecosystem so you might have some trouble at first to figure out a decent configuration. But once you have the whole infrastructure figured out as described in the previous section, now it's as easy as adding a `.gitlab-ci.yml` file to your root directory. Something like this:\n\n```yaml\n# This file is a template, and might need editing before it works on your project.\nimage: codeminer42/ci-ruby:2.3\n\n# Pick zero or more services to be used on all builds.\n# Only needed when using a docker container to run your tests in.\n# Check out: https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#what-is-service\nservices:\n  - postgres:latest\n  - redis:latest\n\ncache:\n  key: your-project-name\n  untracked: true\n  paths:\n    - .ci_cache/\n\nvariables:\n  RAILS_ENV: 'test'\n  DATABASE_URL: postgresql://postgres:@postgres\n  CODECLIMATE_REPO_TOKEN: -- your codeclimate project token --\n\nbefore_script:\n  - bundle install --without development production -j $(nproc) --path .ci_cache\n  - cp .env.sample .env\n  - cp config/database.yml.example config/database.yml\n  - bundle exec rake db:create db:migrate\n\ntest:\n  script:\n    - xvfb-run bundle exec rspec\n```\n\nMy team at [Codeminer 42][codeminer] prepared a simple [Docker image] with useful stuff pre-installed (such as the newest phantomjs, xvfb, etc), so it's now super easy to enable automated builds within GitLab by just adding this file to the repositories. (Thanks to Carlos Lopes, Danilo Resende and Paulo Diovanni - who will be talking about [Docker at Rubyconf Brasil 2016][docker-conf], by the way).\n\nGitLab CI even supports building a pending Merge Request, and you can enforce the request so it can only be merged if builds pass, just like in GitHub + Travis. And as Code Climate is agnostic to Repository host or CI runner, you can easily integrate it as well.\n\n![merge requests](https://about.gitlab.com/images/blogimages/moving-to-gitlab-yes-its-worth-it/settings-codeminer42-cm-fulcrum-gitlab.png){: .shadow}\n\n## Conclusion\n\nThe math is hard to argue against: the GitLab + GitLab CI + Digital Ocean combo is a big win. GitLab's interface is very familiar so users from GitHub or Bitbucket will feel quite at home in no time.\n\nWe can use all the [Git flows] we're used to.\n\n**GitLab CE** is still a work in progress though, the team is increasing their pace but there are currently more than [4,200 open issues][gl-issues]. But as this is all Ruby on Rails and Ruby tooling, you can easily jump in and contribute. No contribution is too small. Just by reporting how to reproduce a bug is help enough to assist the developers to figure out how to improve faster.\n\nBut don't shy away because of the open issues, it's fully functional as of right now and I have not found any bugs that could be considered show stoppers.\n\nThey have many things right. First of all, it's a \"simple\" Ruby on Rails project. It's a no-thrills front-end with plain JQuery. The choice of HAML for the views is questionable but it doesn't hurt. They use good old Sidekiq+Redis for asynchronous jobs. No black magic here. A pure monolith that's not difficult to understand and to contribute.\n\nThe APIs are all written using Grape. They have the [GitLab CE][ce] project separated from other components, such as the [GitLab Shell][shell] and [GitLab CI Multi-Runner][run].\n\nThey also forked [Omnibus][omn] in order to be able to package the CE Rails project as a \".deb\". Everything is orchestrated with Docker. And when a new version is available, you only need to `apt-get update && apt-get upgrade` and it will do all the work of backing up and migrating Postgresql, updating the code, bundling in new dependencies, restarting the services and so forth. It's super convenient and you should take a look at this project if you have complicated Rails deployments into your own infrastructure (out of Heroku, for example).\n\nI am almost done moving hundreds of repositories from both Bitbucket and GitHub to GitLab right now and the developers from my company are already using it in a daily basis without any problems. We are almost at the point where we can disengage from Bitbucket, GitHub and external CIs.\n\nYou will be surprised how **easy your company can do it** too and **save a couple thousand dollars** in the process, while **having fun doing it**!\n\n----\n\n_**Note:** this article was originally posted by [AkitaOnRails]._\n\n\u003C!-- identifiers -->\n\n[AkitaOnRails]: http://www.akitaonrails.com/2016/08/03/moving-to-gitlab-yes-it-s-worth-it\n[auto-sc-doc]: https://gitlab.com/gitlab-org/gitlab-runner/blob/master/docs/configuration/autoscale.md\n[auto-scaling]: /releases/2016/03/29/gitlab-runner-1-1-released/\n[bucket]: http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html\n[ce]: https://gitlab.com/gitlab-org/gitlab-ce\n[codeminer]: http://www.codeminer42.com/\n[comm-graph]: https://github.com/gitlabhq/gitlabhq/graphs/contributors?from=2015-03-14&to=2016-08-02&type=c\n[conf]: http://www.rubyconf.com.br/pt-BR/speakers#Gabriel%20Gon%C3%A7alves%20Nunes%20Mazetto\n[do-inst]: https://www.digitalocean.com/features/one-click-apps/gitlab/\n[do-tok]: https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-api-v2\n[do-ub]: https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04\n[doc-runner]: https://gitlab.com/gitlab-org/gitlab-runner/blob/master/docs/install/autoscaling.md#prepare-the-docker-registry-and-cache-server\n[Docker image]: https://hub.docker.com/r/codeminer42/ci-ruby/\n[docker-conf]: http://www.rubyconf.com.br/pt-BR/speakers#Paulo%20Diovani%20Gon%C3%A7alves\n[documentation]: /install/\n[douglas]: https://gitlab.com/dbalexandre\n[evang]: http://www.akitaonrails.com/2007/9/22/jogar-pedra-em-gato-morto-por-que-subversion-no-presta\n[gabriel]: https://gitlab.com/brodock\n[gh-fund]: https://www.crunchbase.com/organization/github#/entity\n[gh-prices]: https://github.com/blog/2164-introducing-unlimited-private-repositories\n[Git flows]: /2014/09/29/gitlab-flow/\n[GitLab.com]: https://gitlab.com/users/sign_in\n[gitorious]: https://gitorious.org/gitorious/oboxodo-gitorious?p=gitorious:oboxodo-gitorious.git;a=search;h=9f6bdf5887c65a440bc3fdc43a14652f42ddf103;s=Fabio+Akita;st=committer\n[gl-fund]: https://www.crunchbase.com/organization/gitlab-com#/entity\n[gl-issues]: https://gitlab.com/gitlab-org/gitlab-ce/issues\n[gl]: /\n[inst-gl-run]: /blog/how-to-set-up-gitlab-runner-on-digitalocean/\n[locale]: http://askubuntu.com/questions/162391/how-do-i-fix-my-locale-issue\n[Minio]: https://github.com/minio/minio\n[omn]: https://gitlab.com/gitlab-org/omnibus-gitlab\n[omni-auth]: https://docs.gitlab.com/ee/integration/omniauth.html\n[override]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/environment-variables.md\n[run]: https://gitlab.com/gitlab-org/gitlab-runner\n[runner]: https://gitlab.com/gitlab-org/gitlab-runner\n[shell]: https://gitlab.com/gitlab-org/gitlab-shell\n[vars]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/attributes/default.rb#L57\n",{"slug":3427,"featured":6,"template":679},"moving-to-gitlab-yes-its-worth-it","content:en-us:blog:moving-to-gitlab-yes-its-worth-it.yml","Moving To Gitlab Yes Its Worth It","en-us/blog/moving-to-gitlab-yes-its-worth-it.yml","en-us/blog/moving-to-gitlab-yes-its-worth-it",{"_path":3433,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3434,"content":3440,"config":3445,"_id":3447,"_type":16,"title":3448,"_source":17,"_file":3449,"_stem":3450,"_extension":20},"/en-us/blog/7-myths-about-open-source",{"title":3435,"description":3436,"ogTitle":3435,"ogDescription":3436,"noIndex":6,"ogImage":3437,"ogUrl":3438,"ogSiteName":713,"ogType":714,"canonicalUrls":3438,"schema":3439},"7 Myths About Open Sourcing Your Company's Software","Here are some common misconceptions about what happens when you open source your code.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668402/Blog/Hero%20Images/code-gitlab-tanuki.png","https://about.gitlab.com/blog/7-myths-about-open-source","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"7 Myths About Open Sourcing Your Company's Software\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Folson\"}],\n        \"datePublished\": \"2016-07-08\",\n      }",{"title":3435,"description":3436,"authors":3441,"heroImage":3437,"date":3443,"body":3444,"category":14},[3442],"Amanda Folson","2016-07-08","\n\nMany companies benefit from open source, and countless companies have opted to open source components of their infrastructure (or even their bread and butter) in an effort to give back. However, there are a lot of misconceptions about what happens when you open up your business' code and workflows to the public, and as companies delve into how to apply open principles within their organization, it's easy to get lost in the weeds. Here are some common misconceptions about what happens when you open source your code.\n\n\u003C!-- more -->\n\n**Myth #1: Open source is giving my business away for nothing**\n{: .alert .alert-info}\n\nFalse! Open sourcing your infrastructure/apps is giving your code away in hopes that someone else finds it useful. Opening up your source code allows people to modify it to suit their needs, but also allows people to submit bug fixes and new features.\n\nYour business is a separate entity, and there's a lot more to it than your code.\n\n**Myth #2: We'll lose control of everything**\n{: .alert .alert-info}\n\nAlso false. Just because the code is out there doesn't mean you'll lose total control of it. The code is still yours, you're just letting other people use it. Sure, someone could fork your project. If you take the time to pick out a solid open source license, you'll likely be allowed to merge their changes back into your project if you desire.\n\n**Myth #3: There's no value to open source**\n{: .alert .alert-info}\n\nWindows, macOS, and Linux all contain open source components. Your web hosting stack is probably comprised of mostly open source projects. Even your cell phone has open source software on it, so this statement is demonstrably false.\n\n**Myth #4: Someone will steal my idea**\n{: .alert .alert-info}\n\nIs your idea really unique? Maybe, maybe not—but never underestimate the value of the business around the project. As stated previously, there's a lot more to this than just giving away the source code. Product management and marketing can be key differentiators between you and your competitors.\n\nMicrosoft had the market cornered on enterprise productivity with tools like Office and Outlook. Open source alternatives have been made for both. Social networks, CRM software, operating systems, ride sharing apps, and even knitting patterns all have open alternatives. If you build it, they'll open source it.\n\n**Myth #5: My bottom line will plummet**\n{: .alert .alert-info}\n\nIt's possible, but extremely unlikely as a direct result of open sourcing your code. If you take the time to build a healthy ecosystem around your projects, you'll likely find that you bring in more business as your project develops a reputation.\n\n**Myth #6: We'll go out of business**\n{: .alert .alert-info}\n\nAlso unlikely. There are numerous companies that have open sourced projects that are critical to their business, and they happen to still be in business. Red Hat, Rackspace, Comcast, and more have all released countless projects and all are still multi-billion dollar companies. It's possible to be open and profitable.\n\n**Myth #7: Competitors will steal our stuff**\n{: .alert .alert-info}\n\nThey might copy your features even if your source is closed. Open sourcing code allows them to see the logic of features, but doesn't necessarily make it easier for them to integrate it into their own work. It's also fairly obvious to some consumers when businesses start copying each other. As stated previously (and I still can't state it enough), there is much more to a business than the source code that runs it.\n\nMaking the choice to open source something can be scary, but it doesn't need to be. Open source is here to stay—isn't it time you gave back?\n\n*This post was originally featured on [Opensource.com](https://opensource.com/business/16/6/7-myths-about-open-sourcing-your-companys-software) and is licensed under a [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) license.*\n",{"slug":3446,"featured":6,"template":679},"7-myths-about-open-source","content:en-us:blog:7-myths-about-open-source.yml","7 Myths About Open Source","en-us/blog/7-myths-about-open-source.yml","en-us/blog/7-myths-about-open-source",{"_path":3452,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3453,"content":3459,"config":3464,"_id":3466,"_type":16,"title":3467,"_source":17,"_file":3468,"_stem":3469,"_extension":20},"/en-us/blog/continuous-delivery-with-gitlab-and-convox",{"title":3454,"description":3455,"ogTitle":3454,"ogDescription":3455,"noIndex":6,"ogImage":3456,"ogUrl":3457,"ogSiteName":713,"ogType":714,"canonicalUrls":3457,"schema":3458},"Continuous Delivery with GitLab and Convox","This tutorial will show you how to use GitLab and Convox together to ship software quickly and reliably.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684833/Blog/Hero%20Images/gitlab-convox-cover.jpg","https://about.gitlab.com/blog/continuous-delivery-with-gitlab-and-convox","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Continuous Delivery with GitLab and Convox\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Noah Zoschke\"}],\n        \"datePublished\": \"2016-06-09\",\n      }",{"title":3454,"description":3455,"authors":3460,"heroImage":3456,"date":3462,"body":3463,"category":14},[3461],"Noah Zoschke","2016-06-09","\n[Convox](https://convox.com/) is an open-source tool for deploying, managing, and monitoring applications on cloud infrastructure. It increases the productivity of your developers, reduces your infrastructure spend, and ensures that your architecture is resilient, consistent, and compliant.\n\nRecently, Convox launched a native integration with [GitLab](/) for Continuous Delivery (CD). This tutorial will show you how to use GitLab and Convox together to ship software quickly and reliably.\n\n**Note:** For this tutorial we assume you are familiar with Continuous Deployment (CD) and have a GitLab, [Slack](https://slack.com/) and [Amazon Web Services](https://aws.amazon.com/) (AWS) account. We also assume you are curious about how [Convox](https://convox.com/) utilities make setting up a private, production-ready cloud environment easy.\n{: .note}\n\n\u003C!-- more -->\n\n----------\n\n### What's in this page?\n{:.no_toc}\n\n- TOC\n{: toc}\n\n----\n\n## Continuous Delivery\n\nContinuous Delivery (CD) is a modern software development best practice. Your team wants and needs the ability to safely push updates to production multiple times a day. With a great CD pipeline you can:\n\n* Ship features faster and more frequently\n* Roll out bug fixes and security patches instantly\n* Keep your development team in a coding flow\n* Eliminate work and interruptions on infrastructure that’s not core to your business\n\nIf you don’t have CD tools, you may be spending too much precious time and budget on infrastructure, servers and bespoke deployment tools.\n\nSee the [Wikipedia article on Continuous Delivery](https://en.wikipedia.org/wiki/Continuous_delivery) for more details about the Continuous Delivery approach.\n\n## CD with GitLab and Convox\n\nThe best Continuous Delivery workflow offers a way to `git push` code and automatically deploy it to resilient cloud infrastructure.\n\nConvox and GitLab together represent a modern open-source based Continuous Delivery solution. With both of them your team can:\n\n* **Set up a private deployment cloud in minutes** with `convox install`\n* **Create a production-ready application** with `convox apps create`\n* **Link GitLab.com or GitLab CE/EE and Slack to your deployment cloud** through the Convox Console\n* **Push code to GitLab** with `git push`\n* **Let GitLab webhooks or CI automate builds**, tests and deploys of your code to Convox\n* **Notify your team via Slack** when the new release is live\n\nThis level of automation enables your team to safely release new code as fast as possible, offering an extremely productive workflow for you and your team.\n\nAll of this is built on open-source software that you are free to read, modify, and work with the OSS communities to improve.\n\nOn top of the open-source projects, both GitLab and Convox offer enterprise-grade options to run this in a totally isolated environment where your code, images and containers never leave your control.\n\n![Continuous Delivery from GitLab to Convox](https://about.gitlab.com/images/blogimages/continuous-delivery-with-gitlab-and-convox/gitlab-integration.png)*Continuous Delivery from GitLab to Convox*\n\n![Push Code, Get Service](https://about.gitlab.com/images/blogimages/continuous-delivery-with-gitlab-and-convox/slack.png)*Push Code, Get Service*\n\n### Setting up a Convox Deployment Environment\n\nWe first need to configure an isolated environment where we will deploy everything. When deploying to AWS, there is a minimum architecture we want for a production-ready environment. Convox makes this simple with the `convox install` and `convox apps create` tools. Click the \"Get Started\" button on [convox.com](https://convox.com/) to access the web or command line installer.\n\nConvox expertly integrates the following AWS services:\n\n* Virtual Private Cloud spanning 3 availability zones for network isolation\n* EC2 and an AutoScale Group (ASG) with at least 3 instances for redundancy\n* CloudFormation stacks for safe, automated updates for new AMIs or to scale up instance type and count\n* EC2 Container Service (ECS) for container-based zero downtime deploys\n* EC2 Container Registry (ECR) for storing build artifacts\n* Elastic Load Balancer (ELB) for SSL, websockets and load balancing\n* CloudWatch Logs for log tailing, archiving and search\n\nWith this consistent, batteries-included cluster setup with the `convox` tools we can now relibly deploy, configure and scale our applications.\n\nYou can read the [Getting Started on Convox](https://convox.com/docs/getting-started/) guide for more detailed instructions about setting everything up.\n\n### Granting GitLab and Slack Auth to Convox\n\nEvery service integration begins with authorizing two services to talk to each other. For the first iteration of GitLab and Convox, we opted for a simple token-based solution.\n\n![Get your GitLab Private Token](https://about.gitlab.com/images/blogimages/continuous-delivery-with-gitlab-and-convox/gitlab-account.png)*Get your GitLab Private Token*\n\n![Give Convox your GitLab Endpoint and Token](https://about.gitlab.com/images/blogimages/continuous-delivery-with-gitlab-and-convox/gitlab-setup.png)*Give Convox your GitLab Endpoint and Token*\n\nConvox encrypts this token, and decrypts it when it needs to perform actions on your GitLab instance like creating a webhook and deploy key.\n\nSimilarly, you integrate Convox and Slack with an OAuth flow.\n\nNow Convox has access tokens to get and send information to GitLab and Slack.\n\n### Git Push Webhooks\n\n[Webhooks](https://docs.gitlab.com/ee/web_hooks/web_hooks.html) — user-defined HTTP callbacks — are the fabric on which Continuous Deployment systems are built.\n\nGitLab has tremendous webhook support, allowing you to configure how it will make an HTTPS request to an external system on events like every comment, code push and code merge.\n\nWhen you integrate GitLab with a Convox app, the first thing Convox does is add a new Push Event webhook to your project pointing to a secure and secret Convox URL.\n\n![Tell Convox About the Push](https://about.gitlab.com/images/blogimages/continuous-delivery-with-gitlab-and-convox/gitlab-webhooks.png)*Tell Convox About the Push*\n\nWhen this is configured, Convox will get a notification every time your team pushes new code.\n\n### GitLab Deploy Keys\n\nGitLab has an impeccable security model. If a system like Convox happens to learn the URL for a private repo via a webhook, we still want to control its ability to read or write to this private repo.\n\nTo grant Convox limited, read-only access to your private repo, GitLab offers “[Deploy Keys](https://docs.gitlab.com/ee/user/project/deploy_keys/).” These are SSH keys that have read-only access to a repo, guaranteeing that a third-party system can clone code, but can not push any code back.\n\n![Read-only SSH key](https://about.gitlab.com/images/blogimages/continuous-delivery-with-gitlab-and-convox/gitlab-deploy-key.png)*Read-only SSH key*\n\nWhen you integrate GitLab with a Convox app, the next thing Convox does is generate a new SSH keypair, encrypt and save the private key, and set up a new Deploy Key with the public key.\n\nWith a webhook and deploy key, Convox can dutifully perform an automatic build and/or deploy.\n\n### Delivering Code to Production\n\nNow that a Convox environment is running and it is authorized to get webhooks and pull code from GitLab, and send notifications to Slack, we can do our first `git push` deploy that rolls out new containers:\n\n```\n$ git push gitlab master\nCounting objects: 8, done.\nDelta compression using up to 4 threads.\nCompressing objects: 100% (8/8), done.\nWriting objects: 100% (8/8), 758 bytes | 0 bytes/s, done.\nTotal 8 (delta 7), reused 0 (delta 0)\nTo https://gitlab.com/nzoschke/httpd.git\n   176d4d2..896d06b  master -> master\n\n$ convox builds\nID           STATUS    RELEASE      STARTED         ELAPSED DESC\nBCPSBDTVSVB  complete  RQYRSVEXGLD  56 seconds ago  52s      push nzoschke/httpd refs/heads/master 896d06b2a72e702c3c2efe8fae9670bd19f5f255\nBSZIBYZFDDU  complete  RVUEQWAOHTN  5 days ago      60s      push nzoschke/httpd refs/heads/master 176d4d22d0631c1223ea7ba31d80f837e4a24390\n\n$ convox builds info BCPSBDTVSVB\nRUNNING: git clone --progress git@gitlab.com:nzoschke/httpd.git src\nRUNNING: git checkout 896d06b2a72e702c3c2efe8fae9670bd19f5f255\nRUNNING: /usr/local/bin/git-restore-mtime .\nRUNNING: docker pull httpd\n...\ncb604ab7d359: Pull complete\nDigest: sha256:3eae43b977887f7f660c640ba8477dc1af1626d757ff1a7ddba050418429f2f6\nStatus: Downloaded newer image for httpd:latest\nRUNNING: docker tag -f httpd httpd/web\nRUNNING: docker tag -f httpd/web 132866487567.dkr.ecr.us-east-1.amazonaws.com/convox-httpd-owdnefujkr:web.BCPSBDTVSVB\nRUNNING: docker push 132866487567.dkr.ecr.us-east-1.amazonaws.com/convox-httpd-owdnefujkr:web.BCPSBDTVSVB\nThe push refers to a repository [132866487567.dkr.ecr.us-east-1.amazonaws.com/convox-httpd-owdnefujkr] (len: 1)\n...\nweb.BCPSBDTVSVB: digest: sha256:943ca8f7dbbbfa99f761fae8f8f8d57fa99b6ac7b939ce787ec33735ec68edcb size: 23914\n\n$ convox releases\nID           CREATED       STATUS\nRQYRSVEXGLD  1 minute ago  active\nRVUEQWAOHTN  5 days ago    active\n\n$ convox ps\nID            NAME  RELEASE      SIZE  STARTED         COMMAND\n1bac0db9b7b5  web   RQYRSVEXGLD  256   25 seconds ago  httpd-foreground\n47542b8458a8  web   RVUEQWAOHTN  256   5 days ago      httpd-foreground\nd29eb239fda9  web   RQYRSVEXGLD  256   25 seconds ago  httpd-foreground\nef1d2825f528  web   RVUEQWAOHTN  256   1 day ago       httpd-foreground\n```\n\nYou can see that release `RQYRSVEXGLD` is rolling out and replacing an older release `RVUEQWAOHTN`. In a few more seconds the new code will be up and running. The build and zero-downtime deploy is fully automated by Convox and GitLab.\n\nThe final icing on the cake is that your whole team is notified about the new release on Slack:\n\n![Push Code, Get Service](https://about.gitlab.com/images/blogimages/continuous-delivery-with-gitlab-and-convox/slack.png)*Push Code, Get Service*\n\n### Automated Testing\n\nI'm sure you noticed that we went directly from a code push to production. This demonstrates all the heavy lifting, and may be suitable for QA or staging workflows, but for anything going out to production we almost certainly want to run some tests too.\n\nThis is possible to set up with a few changes. [GitLab CI](/solutions/continuous-integration/) is an excellent tool and service for automating tests.\n\nYou can tell GitLab to deploy to Convox by setting `CONVOX_PASSWORD` as a User-defined variable, then adding a `.gitlab-ci.yml` file similar to:\n\n```yaml\ntest:\n  script:\n  - make test\n\nproduction:\n  type: deploy\n  script:\n  - curl -Ls https://install.convox.com/linux.zip > convox.zip\n  - unzip convox.zip\n  - convox login\n  - convox switch org/rack\n  - convox deploy --app app\n  only:\n  - tags\n```\n\nSee the [CI Variables](https://docs.gitlab.com/ee/ci/variables/) doc and [GitLab CI Examples](https://docs.gitlab.com/ee/ci/examples/) doc for more information.\n\n## Open Source Evolution\n\nBoth GitLab and Convox are always working hard to improve APIs, integrations and tools for automating continuous delivery as open-source projects.\n\nWe encourage you to participate in the open-source projects future enhancements in this space such as a more formal [GitLab Deploy](https://gitlab.com/gitlab-org/gitlab-ce/issues/3286#note_4141009) enhancement and the [Convox Build / Deploy / Release Pipeline](https://github.com/convox/rack/milestones/Build%20/%20Deploy%20/%20Release%20Pipeline) milestone.\n\n## Conclusion\n\nAs you can tell, there are a lot of details to coordinate between your team pushing code and delivering it as a production service in the cloud.\n\nGitLab and Convox understand how important Continuous Delivery is and have gone to great lengths to make this process available to everyone with free and open-source software.\n\n## About guest author Noah Zoschke\n\n[Noah](https://medium.com/@nzoschke) is CTO at Convox. Previously he was Platform Architect at Heroku. He believes that the cloud should be easy to use, secure, reliable and cost effective for teams and systems of all sizes. He believes that simple, open-source tools will unlock this true utility of the cloud.\n",{"slug":3465,"featured":6,"template":679},"continuous-delivery-with-gitlab-and-convox","content:en-us:blog:continuous-delivery-with-gitlab-and-convox.yml","Continuous Delivery With Gitlab And Convox","en-us/blog/continuous-delivery-with-gitlab-and-convox.yml","en-us/blog/continuous-delivery-with-gitlab-and-convox",{"_path":3471,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3472,"content":3478,"config":3483,"_id":3485,"_type":16,"title":3486,"_source":17,"_file":3487,"_stem":3488,"_extension":20},"/en-us/blog/8-tips-to-help-you-work-better-with-git",{"title":3473,"description":3474,"ogTitle":3473,"ogDescription":3474,"noIndex":6,"ogImage":3475,"ogUrl":3476,"ogSiteName":713,"ogType":714,"canonicalUrls":3476,"schema":3477},"8 Tips to help you work better with Git","Read our eight tips that will ensure you perform better with git and help to improve your workflow today. Learn more here!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684361/Blog/Hero%20Images/leaves.jpg","https://about.gitlab.com/blog/8-tips-to-help-you-work-better-with-git","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"8 Tips to help you work better with Git\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patricio Cano\"}],\n        \"datePublished\": \"2015-02-19\",\n      }",{"title":3473,"description":3474,"authors":3479,"heroImage":3475,"date":3481,"body":3482,"category":14},[3480],"Patricio Cano","2015-02-19","\n\nGit is a very powerful [version control system](/topics/version-control/). It can be a little bit daunting to try to learn everything around it, so\nmost people just use the basic commands. We want to give you here some help with some tips you may or may not have heard.\nEither way, these tips can make your workflow a little easier.\n\n\u003C!-- more -->\n\n## Git aliases\n\nOne of the best ways to ease your daily workflow with Git is to create aliases for common commands you use every day. This\ncan save you some time in the terminal.\n\nYou can use the following commands to create aliases for the most used Git commands, `checkout`, `commit` and `branch`.\n\n```\ngit config --global alias.co checkout\ngit config --global alias.ci commit\ngit config --global alias.br branch\n```\n\nThis way, instead of typing `git checkout master` you only need to type `git co master`.\n\nYou could also edit them or add more by modifying the `~/.gitconfig` file directly:\n\n```\n[alias]\n    co = checkout\n    ci = commit\n    br = branch\n```\n\n## Stashing uncommitted changes\n\nLet’s say we are working on a new feature, but there is an emergency and we need to fix to our project immediately.\nWe don’t want to commit an unfinished feature, and we also don’t want to lose our current changes.\n\nThe solution is to temporarily remove these changes with the git stash command:\n\n```\n$ git stash\n```\n\nThe git stash command hides these changes, giving us a clean working directory. We’re now able to switch to a new\nbranch to make our important updates, without having to commit a meaningless snapshot just to save our current state.\n\nOnce you are done working on the fix and want to show your previous changes again, all you need to is run:\n\n```\n$ git stash pop\n```\n\nAnd your changes will be recovered. If you no longer need those changes and want to clear the stash stack you can do so\nwith:\n\n```\n$ git stash drop\n```\n\n## Compare commits from the command line\n\nAn easy and quick way to compare the differences between commits, or versions of the same file is to use the command\nline. For this you can use the `git diff` command.\n\nIf you want to compare the same file between different commits, you do the following:\n\n```\n$ git diff $start_commit..$end_commit -- path/to/file\n```\n\nAnd if you want to compare the changes between two commits:\n\n```\n$ git diff $start_commit..$end_commit\n```\n\nThese commands will open the diff view inside the terminal, but if you prefer to use a more visual tool to compare your\ndiffs, you can use `git difftool`. A really great diff viewer/editor is Meld.\n\nTo configure Meld:\n\n```\n$ git config --global diff.tool git-meld\n```\n\nNow to start viewing the diffs:\n\n```\n$ git difftool $start_commit..$end_commit -- path/to/file\n# or\n$ git difftool $start_commit..$end_commit\n```\n\n\n## Resetting files\n\nSometimes when you start modifying your code, you realize that the changes you did are not that good and would like to reset\nyour changes. Instead of clicking undo on everything you edited, you can reset your files to the HEAD of the branch:\n\n```\n$ git reset --hard HEAD\n```\n\nOr if you want to reset a single file:\n\n```\n$ git checkout HEAD -- path/to/file\n```\n\nNow, if you already committed your changes, but still want to revert back, you can use:\n\n```\n$ git reset --soft HEAD~1\n```\n\n## Use Git blame more efficiently\n\nGit blame is a great tool for finding out who changed a line in a file, but there are ways you can use it more efficiently.\nYou can pass different flags, depending on what you want to show.\n\n```\n$ git blame -w  # ignores white space\n$ git blame -M  # ignores moving text\n$ git blame -C  # ignores moving text into other files\n```\n\n\u003Chr/>\n\n\nNow that you know some very useful tips about working with Git, let us give you some other tips on how to best use Git\nwithin your workflow.\n\n## Pull frequently\n\nIf you are using the [GitLab Workflow](/solutions/gitlab-flow/), it means that you are working\non feature branches. Depending on how long your feature takes to implement, a lot of changes might have been made to the\nmaster branch.\n\nIn order to avoid major conflicts at the end of the development of your feature, you should pull the changes from the\nmaster branch to your branch often. This will allow you to resolve any possible conflicts as soon as possible and it will\nmake merging your branch to master easier.\n\n## Commit often, but don't push every commit\n\nCommitting your changes often will keep your changes concise and make them easier to revert, if you were to need that. But\nit is not necessary to push every single commit to the server, as it will appear in the activity feed and probably spam\nyour colleagues. Work on your changes until you are ready to push.\n\n## Push when changes are tested\n\nA nice sign that your changes are ready to push is when they have been tested and the tests are green. This usually also\nmeans that this part of your feature is done and you can concentrate on the next part. Push your changes once this has been\ndone and let the CI server test them again.\n",{"slug":3484,"featured":6,"template":679},"8-tips-to-help-you-work-better-with-git","content:en-us:blog:8-tips-to-help-you-work-better-with-git.yml","8 Tips To Help You Work Better With Git","en-us/blog/8-tips-to-help-you-work-better-with-git.yml","en-us/blog/8-tips-to-help-you-work-better-with-git",{"_path":3490,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3491,"content":3497,"config":3501,"_id":3503,"_type":16,"title":3504,"_source":17,"_file":3505,"_stem":3506,"_extension":20},"/en-us/blog/innersourcing-using-the-open-source-workflow-to-improve-collaboration-within-an-organization",{"title":3492,"description":3493,"ogTitle":3492,"ogDescription":3493,"noIndex":6,"ogImage":3494,"ogUrl":3495,"ogSiteName":713,"ogType":714,"canonicalUrls":3495,"schema":3496},"The 7 Most Important Open Source Workflow Practices for Enterprises","Learn about the 7 most important open source workflow practices for enterprises.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668213/Blog/Hero%20Images/innersourcing-improves-collaboration-within-an-organization.jpg","https://about.gitlab.com/blog/innersourcing-using-the-open-source-workflow-to-improve-collaboration-within-an-organization","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The 7 Most Important Open Source Workflow Practices for Enterprises\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n        \"datePublished\": \"2014-09-05\",\n      }",{"title":3492,"description":3493,"authors":3498,"heroImage":3494,"date":3499,"body":3500,"category":14},[3404],"2014-09-05","\n\nOpen source development has shown that volunteers can produce amazing software such as the Linux kernel that runs both on smartphones and supercomputers.\nThe workflow used by open source projects helps to explain why these worldwide communities of volunteers are able to cooperate so effectively.\nSimilarly, in large organizations software developers are spread out across many departments and they do not frequently meet in person nor do they report to the same boss.\nTo improve collaboration within the enterprise some companies are starting to take advantage of the same workflow used by open source projects.\nTim O’Reilly [coined the term “inner-sourcing”](http://www.oreillynet.com/pub/a/oreilly/ask_tim/2000/opengl_1200.html) and defines it as the use of open source development techniques within the corporation.\n\nThe 7 most important open source workflow practices for enterprises are:\n\n1. Visibility: all software projects are by default visible to all employees\n1. Forking: everyone who can see the code, can create a copy [(fork)](/blog/how-to-keep-your-fork-up-to-date-with-its-origin/) where they can make changes freely; these forks are visible for everyone.\n1. Pull/merge requests: even people outside the project are able to suggest changes and you can have a conversation about the code with line comments.\n1. Testing: software includes unit- and integration-tests so that changes can be made with less fear of causing problems.\n1. Continuous Integration: every proposed change is automatically tested and the result is shown with the change.\n1. Documentation: all software projects include a readme that describes what the software does, why that is important, how run it and how to develop it.\n1. Issue tracker: there is a public issue tracker in which everyone can submit a bug or ask a question\n\nMost of these workflow improvements are made possible by distributed version control and modern tooling.\nIn the past a developer had to use word of mouth to find out what other projects were available within the organization and than had to hunt down someone able to give them access to it.\nAdding someone to a project to make changes required a leap of faith on part of the responsible team.\nThis hurt collaboration across departments and led to a duplication of effort.\nWith a modern workflow the developers can reuse work from colleagues and help projects outside their department without first having to ask for permissions and authorizations.\n\nMany enterprises use GitLab to enable this workflow internally.\nAt their request we have introduced a third visibility level for projects.\nInstead of just public projects (visible to the whole world) or private projects (visible only to the participants) you can also mark a project as internal.\nInternal projects are visible to everyone that is logged into the on-premises GitLab server.\nThis way all employees can reuse software, fork it and contribute back.\nWith GitLab an organization can quickly benefit from all open source workflow practices while keeping their code secure.\n\nTo learn more about innersourcing please see this [list of articles about innersourcing](http://www.inner-sourcing.com/wiki/inner-source-wiki/), [email us](mailto:contact@gitlab.com) or ask a question in the comments below.\n",{"slug":3502,"featured":6,"template":679},"innersourcing-using-the-open-source-workflow-to-improve-collaboration-within-an-organization","content:en-us:blog:innersourcing-using-the-open-source-workflow-to-improve-collaboration-within-an-organization.yml","Innersourcing Using The Open Source Workflow To Improve Collaboration Within An Organization","en-us/blog/innersourcing-using-the-open-source-workflow-to-improve-collaboration-within-an-organization.yml","en-us/blog/innersourcing-using-the-open-source-workflow-to-improve-collaboration-within-an-organization",16,[686,706,728,747,766,788,808,828,850],1753799761051]