Security, availability, solidity - that’s what comes to mind when somebody mentions GitLab. This Git hosting service is one of the most trustworthy when it comes to security. Thus, no surprise that more than 30M developers worldwide have already chosen to build their source code on GitLab.

However, what if your data is still at risk regardless of all the security measures the service provider has? Yeap… that’s true. And the best way to have peace of mind that your GitLab source code and metadata information remain safe and available in any event of failure is backup.

Tired of reinventing the wheel every time you start a new project? R2Devops not only puts an end to this tiresome cycle but also transforms the way your developers interact with and reuse code within your organization.

🤯 The CI/CD experience​

❌ Without R2Devops:​

In the pre-R2Devops era, developers often scoured various sources, from existing projects to the vast expanses of the internet, in search of code snippets and configurations. This scattered approach led to inconsistency, wasted time, and the risk of incorporating suboptimal solutions.

✅ With R2Devops:​

Your developers experience a paradigm shift. Templates become the backbone of your inner source culture. Imagine a centralized catalog of pre-approved, company-specific templates that developers can easily access. The days of searching the internet or project repositories are over.

Introduction​

Last week at R2Devops, I had the chance of writing a VSCode extension. Its purpose is to display the Public Marketplace of R2Devops once a .gitlab-ci.yml file is opened. This article will describe the process of creating a VSCode extension that shows a React Webview.

Writing a VSCode extension​

The first step to create a VSCode extension is to create the extension folder and run npm init to create the package.json file. Then we can use the VSCode Yeoman extension generator to create the skeleton of the extension.

$ npm install -g yo generator-code
$ yo code

Anatomy​

Here is the basic structure of the extension

.
├── .vscode
│   ├── launch.json     // Config for launching and debugging the extension
│   └── tasks.json      // Config for build task that compiles TypeScript
├── .gitignore          // Ignore build output and node_modules
├── README.md           // Readable description of your extension's functionality
├── src
│   └── extension.ts    // Extension source code
├── package.json        // Extension manifest
├── tsconfig.json       // TypeScript configuration
├── webview-ui      // The webview directory that contains the React stuff

Each VS Code extension must have a package.json as its Extension Manifest. The package.json contains a mix of Node.js fields such as scripts and devDependencies and VS Code specific fields such as publisher, activationEvents and contributes. You can find description of all VS Code specific fields in Extension Manifest Reference. Here are some most important fields:

• name and publisher: VS Code uses <publisher>.<name> as a unique ID for the extension. For example, the Hello World sample has the ID vscode-samples.helloworld-sample. VS Code uses the ID to uniquely identify your extension.

• main: The extension entry point.

• activationEvents and contributes: Activation Events and Contribution Points.

• engines.vscode: This specifies the minimum version of VS Code API that the extension depends on.

Here are the basics, for further details, you can check the complete anatomy on the VSCode documentation.

Now that we have our Extension skeleton, we can start the design part with React.

In 2020, my co-founder Aurélien Coget and I started our own consulting business, helping other companies to develop their DevOps methodologies. We both have pronounced engineer mindsets, I should point out at this stage.

Begin in CI/CD​

Our main focus was on CI/CD (continuous integration/continuous deployment). We offered a way to automate testing, building, and deployment of clients’ software. Our clients were happy with the value we provided, and we grew quickly to a staff of eight.

However, we felt like we were reinventing the wheel every time. Creating a CI/CD pipeline requires considerable effort. After all this effort, you have something that’s great for your customers, but you also create a single point of failure in their development workflow.

Because, if one day the pipeline stops working, the developers can’t code anymore. So it’s become really critical.