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 the world of CI/CD, there is currently a notable absence of projects that facilitate the knowledge sharing and collaboration among developers. This often results in developers duplicating efforts and reinventing the wheel. To address this issue, initiatives like R2Devops and to be continuous have emerged. These projects promote collaboration and innovation within the open source community, aiming to improve the quality and reusability of code in the world of CI/CD. Let's take a closer look at those projects 👇

What are R2Devops & to be continuous?​

Both R2Devops and to be continuous are open-source projects that aim to simplify the process of creating CI/CD pipelines for developers on GitLab.

The R2Devops platform offers a marketplace of open source CI/CD templates that are versioned & documented. This allows developers to quickly and easily access a range of pipeline templates, saving them time and effort in building and maintaining their own pipelines from scratch.

#more

When it comes to implementing a continuous integration and continuous delivery (CI/CD) pipeline, developers are often faced with a plethora of options. However, finding a reliable and effective solution can be a daunting task. That's where R2Devops comes in 🔥

What is R2Devops GitLab CI/CD Marketplace?​

R2Devops is an open source community that provides a marketplace of ready-to-use CI/CD templates for GitLab. Our mission is to provide a collaborative space for developers to find, share and contribute to CI/CD templates. We propose the R2 standard which has the value of providing templates that are documented, versioned and configurable.

#more

CI/CD increases the frequency of application distribution through automation. Indeed, it automates the process at the application development stage. The main concepts related to the CI/CD approach are Continuous Integration, Continuous Delivery and Continuous Deployment. CI/CD is a best practice for DevOps development. Today, many platforms exist to help you to set up your CI/CD pipeline. GitLab is one of them! Let’s see how this one works.

How to normally implement a CI/CD pipeline on GitLab?​

Implementing a CI/CD pipeline can be scary if you don’t know where to start. Let’s see how you can implement it on GitLab!

The first step: define stages​

In order to set up your pipeline, the first thing you need to do is to define the stages. They are really important in CI/CD because they define when a job will be executed.

A typical GitLab pipeline may consist of four steps, executed in the following order:

1. Build
2. Test
3. Staging
4. Production

#more

You probably already heard about CI/CD. If not, we recommend you to read those two articles about Continuous Integration and Continuous Deployment.

As a reminder, a job is a set of instructions to perform actions on your project. Comining several jobs together is the key to create a powerful pipeline. We will explain to you why you should use R2Devop’s official jobs. 👇🏼

Guaranteed security with official jobs​

On r2devops.io, you will find a library of CI/CD jobs, some are officials and some are published by the community. Official jobs are jobs written or reviewed by R2Devops’ technical team. The community ones are personal jobs put online by the community, without examination from us.

All our official jobs go through a strong security pipeline. We made it to ensure tthey are all safe to use in your pipelines! Here is a schema of our security pipeline, where you can retrieve all the steps:

#more

What are fixed version? Is it really dangerous to use the Latest version of a CI/CD template? We answer your questions!

Some insight about version​

Following semantic versioning, every time an owner applies changes to their CI/CD template, a new version should be released. They are 3 types of changes, each one corresponding to a number: X.Y.Z.

• Z are patches, meaning bug fixes which don’t change the CI/CD template.
• Y are minor modifications, improving the solution, and are backward compatible.
• X are major changes that are NOT backward compatible.

#more

Since February 2022, R2Devops has joined GitLab technical partners’ list! It’s a stamp validating our engagement to simplify developers life and improve the solutions for the DevOps community.

#more

We are pleased to announce that our project R2Devops has received support from the Occitanie region. The region is supporting our initiative through funding, which will enable us to accelerate research and development and release new AI-related features more quickly. We are honored by the trust that the region has placed in R2Devops.

🇫🇷 La région Occitanie soutient R2Devops

Nous sommes heureux d'annoncer que notre projet R2Devops a reçu le soutien de la région Occitanie. La région soutient notre démarche via un financement qui va nous permettre d'accélérer la R&D et sortir plus rapidement de nouvelles features lié à l'IA. Nous sommes honorés de la confiance que la région a placé dans R2devops.