DEV Community: Anthony Viard

Composable Apps security practices with Entando on Kubernetes, featuring Ippon expert

Anthony Viard — Fri, 27 Jan 2023 14:23:36 +0000

Building composable apps means, without a doubt, understanding how it manages security and reliability. Composable apps offer a lot of advantages to streamline applications, provided by the modularity and reusability of Packaged Business Capabilities. Individual modules and PBCs help isolate problems and security design, separate frontend and backend concerns and allow patching at the component level. At the company level, and with a good hub policy, it turns into “patch once, secure all” because you can easily leverage security fixes if they are applied to centralized modules in a store that all your applications rely on.

However, security strategies should not be applied at the code or module level only. The infrastructure has to be fully resilient and secure. No one can imagine using a car with seat belts within an insecure chassis. It doesn't make sense. Security is everyone’s business.

Fortunately, solutions exist to help us design at all levels with security as one of the top priorities.

"Shift security left". It is more than a buzzword, It is good advice according to Lucas Ward in a recent article called Hardening Kubernetes and What That Entails With Entando. There, Ward describes how building applications with Kubernetes is challenging.

I agree, building a fully secured application with Kubernetes is a real adventure. If there is something we can't live without, it is security. Whatever business domain we work in, security should be at the center of the design and production processes.

Delaying its implementation is risky; executing it is time consuming.

As Ward spells out, we can rely on frameworks to bring a smooth and dependable way to secure applications, especially with Kubernetes. He says that using a platform such as Entando provides simplicity and a solid base with best practices you can count on to promote security from the ground up.

From solid structures and base setup with code generation to a well documented CI/CD process, and opinionated build pipelines, Ward asserts that "using Entando as your platform of choice covers a lot of ground in the Development, Build, and Infrastructure scape."

Saying more without spoiling it is just impossible, just read it! This is my only advice.

Explore Docker-based bundles with JHipster and Entando 7.1

Anthony Viard — Tue, 10 Jan 2023 10:08:27 +0000

At Entando we define a bundle as a package that contains one or more components. A bundle can be a single component, component collection, PBC, or solution template, based on the level of granularity. Any bundle built with Entando is an Entando Bundle.

Entando 7.1 introduces a major new change for bundles with a Docker-based structure. This article explores all the things you need to know about that feature.

A shift from Git-based bundles

If you’ve already built or used bundles with Entando, you should know that before v7.1, the bundles were Git-based. That means the source code (called project) and the built artifact (the deployable bundle) were stored under two different Git repositories.

Traditionally, the source code repository is used by the Creators team for coding and building components with development tooling. The coding flow is similar to what we find in any development team, pushing and merging branches to share and review the code within the team.

The second repository stores the result of the compiling process, the artifact, that Curators can register in a hub, and Composers can install on their Application Composition Platform.

The Docker-based bundle is a total shift from that point. The source repository is still present but, all the artifacts are now sent to a Docker registry using Docker images.

A structure modification

The publishing process was improved with the tool change, so we took the opportunity to streamline the bundle structure itself.

We have a more readable and consistent bunch of folders with the Docker-based bundles.

Git-based	Docker-based
bundle/descriptor.yaml The main bundle descriptor	entando.json The main Entando file that contains components definition and metadata
ui/ The micro frontends sources folder	microfrontends/ Centralized micro frontends folder
src/ The backend sources folder	microservices/ The microservices folder, one per component
src/main/docker The auxiliary service folder such as Docker compose files and Keycloack configuration for local usages	svc/ The auxiliary service folder such as Dockercompose files and Keycloack configuration for local usage
*.sh Shell script used by the CLI to compile and build the bundle
	platform/ The folder for any Entando related component such as pages, content, page templates… One sub-folder per component type

If you like to make a deep comparison between these implementations, our documentation provides a table here.

This means that the cli and commands are now following that structure and you can easily run them to create a new one.

Let’s start a new project to discover this

Create a new 7.1 bundle with the ent CLI

Prerequisites

Before moving forward, you have to ensure that your Entando CLI is up to date. If not, please run the following command:

bash <(curl -sfL https://get.entando.org/cli) --update

Don’t forget to activate it with the following command

source "$HOME/.entando/activate"

Initialize the project

From your favorite folder, run the following command to initialize the project.

ent bundle init my-bundle

Please note you can replace “my-bundle” according to your project name.

A new folder is created with this project name; open it as a project with your favorite IDE to check the new structure.

You can check the entando.json file content, and the metadata:

{
   "microservices": [],
   "microfrontends": [],
   "svc": [],
   "name": "my-bundle",
   "version": "0.0.1",
   "description": "my-bundle description",
   "type": "bundle"
}

Add a microservice

In the project folder, run the following command to add a new microservice.

ent bundle ms add sample-ms --stack=spring-boot

We specify the stack because of the dedicated metadata we may need with some stack types. This command creates a new folder, sample-ms, in microservices and adds an entry in the entando.json.

{
   "microservices": [
       {
           "name": "sample-ms",
           "stack": "spring-boot",
           "healthCheckPath": "/api/health"
       }
   ],
   "microfrontends": [],
   "svc": [],
   "name": "my-bundle",
   "version": "0.0.1",
   "description": "my-bundle description",
   "type": "bundle"
}

Please note this new folder is empty and you have to add your own code. We provide an easy way to start; let’s do it with JHipster.

Call JHipster with the following commands

cd microservices/sample-ms
ent jhipster --blueprints=entando

Then, select only the default values.

When the generation is done, the sample-ms folder contains all the files provided by JHipster.

Customize the bundle for JHipster

You just need to tweak a couple of things to make it work properly.

Edit the entando.json and update microservices/sample-ms to set the healthCheckPath and dbms properties:

   "healthCheckPath":"/management/health",
   "dbms":"postgresql"

Move the Blueprint-provided auxiliary service definitions into the svc directory in the bundle project:

mv microservices/sample-ms/src/main/docker/* svc/

This enables the ent CLI to start Keycloak:

ent bundle svc enable keycloak

For advanced use cases, you can add MFEs with this tutorial. Please note that for microservices, you have to execute some extra steps.

Discover the new publishing process

This new bundle structure comes with a simpler publishing process provided by new streamlined CLI commands.

You can find a graphic of the different steps below. It describes the overall process and helps you to understand the details involved in every step.

Let's follow it for our new 7.1 bundle.

Build

From the root project folder, run the following command:

ent bundle pack

Please note, you need to have Maven installed for this to execute. You also need Docker installed; you can check the installation procedure here regarding your environment.

You can run the docker image ls command to see your available images.

Publish

Once it’s finished, run the next command to publish the bundle to a Docker repository.

ent bundle publish

In this step, you need to be logged into the Docker hub, ensure you have an account or create a new one on this website: https://hub.docker.com

_Please note, you can decide to publish the images to another registry by providing the URL with the --registry parameter.

Deploy

This step is the same as the previous Entando version, even if the commands have been modified to keep the consistency. Here, you need to have an available running instance of Entando. Visit https://developer.entando.com to install a local one.

Please note that you need your ent CLI profile to be connected to your Entando instance. If you followed the previous steps and installed a local multipass VM, you might have to run this command:ent attach-vm entando where “entando” is the virtual machine name.

Otherwise, it is possible to attach a kubeconfig file with this: ent attach-kubeconfig {kubeconfig-file}.

From your bundle root folder, run the following command:

When the deploying process is finished, you can navigate to your Local Hub by clicking on the “Hub” menu.

Then, you should see your bundle.

Install

As you can see, the bundle is available in your Local Hub but not installed yet. That means nothing is running on your cluster from that bundle and the components are not available for composition.

To install them, you can use the UI and click on the install button in the Local Hub or, you can run the following command from your bundle root folder: ent bundle install

The micro frontends are now available in the App Builder to compose new pages. the microservices as pods and you can check them with ent kubectl get pods -n entando.

Conclusion

In this article, we discovered a few new features provided by Entando 7.1. The bundle structure has been rebuilt; they are now docker-based and the publishing process has been optimized with the ent CLI commands. The JHipster blueprint has been optimized to match this new paradigm.

You can find explanations of these features during our 7.1 live with Sohini.

Did you know the bundle we just created can be used like a template to create a new one? Maybe not, because it’s also a new feature on 7.1 and this is the topic of the next blog post in this series. Stay tuned.

Using Vue.js to create a Micro Frontend

Anthony Viard — Mon, 27 Jun 2022 13:15:56 +0000

Disclaimer

This article has been written with the help of the ModSquad Community. The related live session is available here:

Introduction

Hi, fellow developers!

After learning how to create micro frontends with Angular and React, we’re jumping into another world with Vue.js. Remember, we’re trying to create a micro frontend using the web component specifications for each of the following frameworks: Angular, React, and Vue.js.

Does Vue provide the best developer experience when creating a micro frontend social card? Let’s try it!

Create the Vue.js app

First, ensure that you have installed Node with npm (you can use Yarn instead) and Vue CLI.

npm install -g @vue/cli

Then you can create the application by running the following command in your target folder. I suggest using the default option Default ([Vue 3] babel, eslint).

vue create vue-social-card

That should create a folder named vue-social-card that contains a fresh Vue.js project.

Please note that by default the application is configured to include certain features, such as npm scripts to start your app and eslint to help you code.

Discover your application

Before making any changes and creating a micro frontend, let’s run the application locally using the command npm run serve. Your application should then be available at the following URL: http://localhost:8080/.

Create the social card component

Vue.js helps you organize yourcode with components. That means we need to create a file to contain all the card code. You can delete the default file called HelloWorld.vue.

Once you’ve created a new file named SocialCard.vue in the components folder, copy the following code into it:

<script>
export default {
  props: {
    card: {
      type: Object,
      required: true
    }
  },
};
</script>

<template>
 <div class="card">
  <h2>{{ card.name }}</h2>
     <span>{{ card.description }}</span>
  <img :src="card.image" :alt="card.image_alt"/>
 </div>
</template>

<style>
.card {
width: 320px;
height: auto;
min-height: 450px;
background: rgb(60, 62, 68);
border-radius: 20px;
overflow: hidden;
padding: 10px 15px;
margin-bottom: 24px;
margin-right: 10px;
transition: all 0.2s linear;
cursor: pointer;
color: white;
}
img {
margin-top: 5%;
 max-width: 100%;
 height: auto;
}
.card:hover {
transform: scale(1.01);
box-shadow: 0 3px 12px 0 rgba(0, 0, 0, 0.2),
 0 1px 15px 0 rgba(0, 0, 0, 0.19);
}
.card > .title {
margin: 0;
}
</style>

Our component is just a simple piece of HTML/CSS code that requires an entry object named card and defines the following properties: name, description, image and image_alt.

As it is, your application might be broken due to an error in the app.vue file. It’s time to update it.

Update App.vue

The reason your app doesn’t work is that the main component still includes the default component. To fix it, replace the file contents with the following code:

<script>
import SocialCard from "@/components/SocialCard";

export default {
  components: {
    SocialCard
  },
  data() {
    return {
      shiba_card: {
        id: 1,
        name: 'Shiba Inu',
        description: 'The Shiba Inu is the smallest of the six original and distinct spitz breeds of dog from Japan.\n' +
            '      A small, agile dog that copes very well with mountainous terrain, the Shiba Inu was originally\n' +
            '      bred for hunting.',
        image: 'https://material.angular.io/assets/img/examples/shiba2.jpg',
        image_alt: 'The Shiba Inu image'
      },
    }
  }
};
</script>

<template>
  <SocialCard :card=shiba_card></SocialCard>
</template>

This imports our social card component, defines a card object shiba_card in the data() function to store the different properties, then passes the card object to the social card component in the template section.

The application is working again and the default Vue landing page is replaced with the Shiba Inu social card.

However, we only built a classic single page application and need to migrate it to a micro frontend.

Define the custom element

In order to reuse this app as a web component, we need to define a custom element, which is a typical step we discovered when using Angular and React.

Replace the content of the main.js file with the following:

import App from './App.vue'

import { defineCustomElement } from 'vue'

const SocialCardElement = defineCustomElement(App)

customElements.define('social-card-element', SocialCardElement)

This code defines the social-card-element custom element and wraps the Vue app. As we saw before, this app is now rendering the card as expected.

Next, replace <div id="app"></div> in the public/index.html file with the custom element:

<body>
 <noscript>
   <strong>We're sorry but <%= htmlWebpackPlugin.options.title %> doesn't work properly without JavaScript enabled. Please enable it to continue.</strong>
 </noscript>
 <social-card-element></social-card-element>
 <!-- built files will be auto injected -->
</body>

Congratulations! You have just built a Vue.js micro frontend using a custom element.

Please note, as I’m writing this article there is an issue with styling and custom elements that is discussed in detail here: https://github.com/vuejs/core/issues/4662. Please follow this ticket to know when it will be fixed or for current workarounds.

Resources

The code above is available on GitHub: https://github.com/avdev4j/vue-social-card

Thanks to this repo for the card example: https://github.com/AlanPenaRuiz/vue-rick-and-morty

Are you already using Entando and looking for Vue.js components? Take a look at this sample: https://github.com/entando-samples/ent-project-template-vue

Watch micro frontend videos on our YouTube channel: https://www.youtube.com/c/EntandoVideos

Join us on Discord to share and learn about composable apps: https://discord.gg/SdMCvyzzHm

Using React to create a Micro Frontend

Anthony Viard — Mon, 20 Jun 2022 09:26:06 +0000

Disclaimer

This article has been written with the help of the ModSquad Community. The related live session is available here:

Introduction

Hi, fellow developers!

Having discovered micro frontend creation with Angular, we jump into another world with React. Remember, I’m trying to create a micro frontend using the web component specifications foreach of the following frameworks: Angular, React, and Vue.js.

Does React provide the best developer experience when creating a micro frontend social card? Let’s try it!

Create the React app

React offers a simple way to create React applications using the Create React App.

As seen in the previous blog, you need to have npm installed. You can then run the following command to create the application skeleton:

npx create-react-app react-social-card

Once complete, you should have a new React project available in the react-social-card folder.

Start it using the command npm start.

The default React page is reachable at http://localhost:3000.

Add the social card code

Before configuring the custom-element, we have to create the React social card component. After some research, here is an example of code we can use: https://codepen.io/leoraw/pen/ZjvRpL. Thanks to @leoraw for sharing this example.

Create the React components

The social card is split into two different React components: a button box and the card itself.

First, we create a new file for the button box in the components folder, name it ButtonBox.js and copy this code:

import React from "react";

const UiButton = props => {
   const classes = (props.isClicked) ?
     "ui-button clicked" : "ui-button";
   const number = (props.isClicked) ?
         (props.number + 1) : props.number;

   return (
     <button className={classes} id={props.text}
       onClick={() => props.onClick()}>
       <span className="ui-icon">{props.icon} </span>
       {number}
     </button>
   );
};

class ButtonBox extends React.Component {
   constructor(props) {
     super(props);
     console.log(props.likeIsClicked);
     this.state = {
       likeIsClicked: props.likeIsClicked

     };
   }

   toggle(index) {
     let state = {};
     state[index] = !this.state[index];
     this.setState(state);
   }

   render() {
     return (
       <div>
         <UiButton icon='♥' text='likes'
           number={this.props.likes}
           onClick={() =>
             this.toggle('likeIsClicked')}
           isClicked={this.state.likeIsClicked}/>
       </div>
     );
   }
}

export default ButtonBox;

Then, in the same folder, we create the SocialCard.js file and copy the following content.

Please note that this new component imports and use the previous one. Effectively, the internal architecture in the micro frontend allows us to use multiple components, and all the components are built into one custom element.

import React from "react";
import ButtonBox from "./ButtonBox";

const UiCard = props => {
 let {image, title, content} = props.content;
 return (
   <div class="card-wrapper">
     <div className='card-img'>
       <img src={image} />
     </div>
     <div className='card-content'>
       <h3>{title}</h3>
       <div>{content}</div>
     </div>
     </div>
 );
}

class SocialCard extends React.Component {
   render() {
     return (
       <div className='card-body'>
         <UiCard content={this.props.content}/>
         <div className='line'></div>
          <div style={{textAlign: 'right'}}>
             <ButtonBox
             likeIsClicked={this.props.likeIsClicked}
             likes={this.props.likes}/>
         </div>
       </div>

     );
   }
}

export default SocialCard;

Use the new components in the main App.js file

Once these two components are available, we can update the main App.js file and remove the old React demo code.

Update the App.js file by replacing the existing code with this:

import React from 'react';
import './App.css';
import SocialCard from "./components/SocialCard";

const cardDetails = {
   id: 0,
   content: {
       title: 'Shiba Inu',
       image: 'https://material.angular.io/assets/img/examples/shiba2.jpg',
       content: 'The Shiba Inu is the smallest of the six original and distinct spitz breeds of dog from Japan. A small, agile dog that copes very well with mountainous terrain, the Shiba Inu was originally bred for hunting.',
   },
   likeIsClicked: true,
   likes: 5
}

function App() {
 return (
   <SocialCard
     key={cardDetails.id}
     content={cardDetails.content}
     likes={cardDetails.likes}
     likeIsClicked={cardDetails.likeIsClicked}
     />
 );
}

export default App;

You can see here that we are instantiating a new social card component and giving it some data to display.

Now you can restart the application or refresh the page to see our social card appear. However, this is still a raw React application and we need to define the custom-element to finish our task.

Switch the app to a custom element

In the src folder, at the same level as the components folder, we create a new folder named custom-element.

Next, let’s create a new file named social-card-app.js to define the custom-element using the related API.

import ReactDOM from "react-dom"
import React from "react"
import App from '../App'

class SocialCardApp extends HTMLElement {
   connectedCallback() {
       this.mountPoint = document.createElement('span')
       this.render()
   }

   render() {
       ReactDOM.render(<React.StrictMode>
                   <App/>
           </React.StrictMode>,
           this.appendChild(this.mountPoint))
   }
}

customElements.get('react-social-card') || customElements.define("react-social-card", SocialCardApp)

The string “react-social-card” is used to define the custom-element tag and renders the React app using: <App/>.It’s analogous to Russian dolls: custom-element > React app > social card component > buttonbox component.

Then, in the file index.js import the custom-element and replace all the previous content with this code:

import './custom-element/social-card-app';
```



Then, in the following `public/index.html` file, replace the body with this:




```html
<body>
 <noscript>You need to enable JavaScript to run this app.</noscript>
 <react-social-card></react-social-card>
</body>
```




Reload your browser and check the HTML content:



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pmajvoe2sxvzo4id2eoa.png) 


The `react-social-card` custom element is used and loads the React app content.

**Congratulations! You’ve just created your first micro frontend using React!**


## Resources:

The code above is available on GitHub: [https://github.com/avdev4j/react-social-card](https://github.com/avdev4j/react-social-card)

Watch micro frontend videos on our YouTube channel: [https://www.youtube.com/c/EntandoVideos](https://www.youtube.com/c/EntandoVideos)

Join us on Discord to share and learn about composable apps: [https://discord.gg/SdMCvyzzHm](https://discord.gg/SdMCvyzzHm)

Using Angular to create a Micro Frontend

Anthony Viard — Tue, 14 Jun 2022 12:10:59 +0000

Disclaimer

This article has been written with the help of the ModSquad Community. The related live session is available here:

Introduction to Web Components

Web components are a set of technologies, a meta- specification, with reusable isolated elements that make up a web application.

Basically, Web Components need 4 specifications:

Custom Elements: A set of Javascript APIs to define the components and their behaviors.
Shadow DOM: A set of APIs to render the element into a dedicated and isolated DOM.
HTML Templates: Allows you to use <template> and <slot> tags to define a portion of HTML to reuse in which slots could be filled with variable content.
ES Modules: A specification to import and use Javascript Modules to create an agnostic modular approach.

Modern Javascript frameworks offer some solutions to easily create a web component, using a custom element, leveraging all the framework features, and creating small business-oriented apps. This is what we call micro frontends.

Let’s see how to proceed using Angular and let’s see how to create our first micro frontend.

To continue, you need to have installed NodeJS (including npm) and the Angular CLI

npm install -g @angular/cli

Initiate the Project

Here we go. We are going to create our first web component using Angular. For this first exercise, let’s create a card to describe people in our community. We call it “social card”.

With your favorite terminal, create a new Angular project

ng new social-card

Create an Angular Component

Add Angular material

Because we want to use the Angular Material library to create our component, we need to add it as a dependency on our project. During the installation, I select the default values.

ng add @angular/material

Create the Material Card Component

From the example section of the Card component, I choose to implement the “Card with multiple sections” one. https://material.angular.io/components/card/examples

First, I create a new Angular component. Please note “components” here refer to the Angular Component, not Web Components defined in the introduction.

ng generate component card

The Angular CLI automatically creates all the needed files and updates the different files to make the application work out of the box.

In the src/app/card/ folder, open the HTML file and copy the following code into it:

<mat-card class="example-card">
   <mat-card-header>
     <div mat-card-avatar class="example-header-image"></div>
     <mat-card-title>John Doe</mat-card-title>
     <mat-card-subtitle>Dev Adcovate</mat-card-subtitle>
   </mat-card-header>
   <img mat-card-image src="https://material.angular.io/assets/img/examples/shiba2.jpg" alt="Photo of a Shiba Inu">
   <mat-card-content>
     <p>
       The Shiba Inu is the smallest of the six original and distinct spitz breeds of dog from Japan.
       A small, agile dog that copes very well with mountainous terrain, the Shiba Inu was originally
       bred for hunting.
     </p>
   </mat-card-content>
   <mat-card-actions>
     <button mat-button>LIKE</button>
     <button mat-button>SHARE</button>
   </mat-card-actions>
 </mat-card>

Then, open the CSS file and copy the following code:

.example-card {
   max-width: 400px;
}
 .example-header-image {
   background-image: url('https://material.angular.io/assets/img/examples/shiba1.jpg');
   background-size: cover;
}

Import Angular Material Modules in your App Module

Then, open the src/app/app.module.ts to import the MatCardModule and the MatButtonModule.

import {MatCardModule} from '@angular/material/card';
import {MatButtonModule} from '@angular/material/button';

imports: [
 MatCardModule,
 MatButtonModule

Run your application

Edit the app.component.html file from the src/app folder and replace the existing with the following:

<app-card></app-card>

You can start your application by running the following command at the project root level:

ng serve

So far, so good, but the following application is not yet a Web Component and we need to make some changes to transform it.

Transform the Application into a Web Component

Add Angular elements dependency

Angular elements is the name in the Angular ecosystem for custom elements. This dependency allows us to easily create a custom element from our existing application.

ng add @angular/elements

Update the app.module.ts

From the src/app/app.module.ts file, update the constructor, call the createCustomElement() method, and define the custom element tag, ng-social-card.

import {createCustomElement} from '@angular/elements';

export class AppModule {
 constructor(private injector: Injector) {
   const el = createCustomElement(AppComponent, { injector });
   customElements.define('ng-social-card', el);
 }

 ngDoBootstrap() {
 }
}

Remove the AppComponent in the bootstrap array. we don’t need it anymore and it could generate errors in the console log.

Update the index.html

Open the src/.html file and change the content to use the custom-element instead of the initial value. \

<body>
 <ng-social-card></ng-social-card>
</body>

We have now instantiated the application, using a custom element instead of the regular app-root tag.

Start the application again using ng serve and check that the application is still working.

Build and Run Your Web Component

Build it!

To build your component you have to run the following command:

ng build

A dist folder is now created containing an HTML file and all the Javascript and CSS files.

If you open the index.html, you can see it contains the custom elements previously defined.

<head>
 <meta charset="utf-8">
 <title>NgSocialCard</title>
</head>
<body>
 <ng-social-card></ng-social-card>
<script src="runtime.6ef72ee47cb5bc7a.js" type="module"></script>
<script src="polyfills.41cc36d27639541d.js" type="module"></script>
<script src="main.8609c098aeba9ec8.js" type="module"></script>
</body>

Run it!

To run it, you can install serve through npm to start a lightweight web server.

npm install -g serve

And from the dist/ng-social-card folder, run the following command:

serve

Congratulations! You’ve just created your first micro frontend using Angular.

Resources

All the code is available at the repository: https://github.com/avdev4j/ng-social-card

Find more micro frontends videos on our YouTube channel: https://www.youtube.com/c/EntandoVideos

Join us on Discord to share and learn about Composable apps: https://discord.gg/SdMCvyzzHm

We analyze the JHipster Community Survey on YouTube

Anthony Viard — Thu, 03 Mar 2022 17:12:06 +0000

Hi there,
You probably did not miss our Community Survey and the results shared by Alina on this blog post.

During my weekly "Compose with Anthony" Live stream session with the ModSquad on YouTube, I tried to understand and analyze the results of the survey and how we can imagine the future of the project.

Thanks to all participants! Please find the replay below and share your thoughts with us ;)

4 Tips I Wish I Knew 10 Years Ago

Anthony Viard — Thu, 03 Mar 2022 12:44:57 +0000

Hey, fellow developers!

What advice would you give to yourself if you could travel back in time? What if you could leverage your acquired experience? What are the top pieces of advice you would give to any beginner developer?

This is the exercise I tried to do and want to share with you. Great Scott! Let’s go back to the future!

1. Work on the Basics

This advice sounds logical and natural for a beginner in any domain, including IT. However, we do know IT is an exciting world full of distractions. When you start you want to test everything, learn everything, and move forward on every topic at the same time.

What I would do differently is focus on “basic” knowledge, such as learning design patterns, mastering a method of development like Test Driven Development (TDD), etc… I’m not saying I skipped these things, but they’re worthy of a deep understanding.

My tips: Learn the basics, enforce your knowledge. This will help you to be better.

2. Contribute to Open Source Projects

Contributing to OSS is probably the best decision I made in my career. But, I probably should have done it sooner. I know it’s hard to expose yourself and your weaknesses to the rest of the world, but it’s an opportunity to share your strengths and help others.

It was easy to take action once I felt it was time. What I learned is: whatever your experience, your knowledge, your position… you are valuable. You can help communities by sharing your know-how.

What happens if you fail? You realize that making mistakes is the best way to learn.

If I could, I’d contribute sooner than I did.

My tips: Start contributing as soon as possible. Don’t frame it like you can add value to existing projects; you are the value.

3. Avoid Toxic People

I don’t know if I’m a lucky person or if the IT world is mostly kind, but I don’t think I’ve met too many toxic people. My overall experience is a good one, and when I met good technical people I also met a lot of friends.

In my experience, IT people don’t fit the nerd stereotype. I have a lot of good memories of meeting new people, learning from different cultures, and learning from new friends.

However, I also had bad experiences working with toxic people. You know people are toxic when they think about themselves while the team is trying to build a project as one person. You know people are toxic when they put a lot of pressure on you, or don’t hesitate to blame teammates for something that went wrong or when tasks have not been completed in time.

I did encounter people like this and I swear their toxicity can destroy a team’s effort. Unfortunately, I might have lacked the confidence to fight this type of person.

The world is full of kind people. Be close to them. Run away from the others.

My tips: Feel free to claim you don’t want to work with toxic people. Don’t let them put in your mind that you are not good enough or valuable. Enjoy smart and kind people and be the person you want the other to be. Throw away toxicity.

4. Don’t Think You Don’t Deserve It

Several times I felt I did not deserve all the good things that happened to me. In a constantly moving technical world, it’s hard to find our place and understand this one is legit. You can quickly be the trusted person for a given application if you work on it for several months.

You can quickly teach others about a specific technology, framework or tool you worked on.

After 3 or 5 years you can carry a team and be a reference for beginners.

So often I was wondering if all this attention was normal and I was not cheating my colleagues.

I think my main issue was the inability to do some introspection and understand that if people trusted me for a task that meant they were doing it with good reason.

My tips: If sometimes you feel you’re overestimated, know that people trust you for good reason. You deserve the good things that happen because you worked hard for them. We are never totally prepared for new things, embrace them.

Conclusion

I have a gut feeling that all the things I would like to tell myself sound familiar to other developers. However, I also know we all have different stories, different experiences, and we probably give ourselves different advice.

I’m wondering, what advice would you give yourself? Is it the same as mine?

Leverage JHipster to build your CI pipelines quickly

Anthony Viard — Thu, 27 Jan 2022 11:27:32 +0000

Hi, my fellow developers,

After having discovered the top 3 features I like to use with GitHub Actions, I’d like to share how you can easily create your own pipelines for a JHipster generated project using the ci-cd generator, with multiple choices of pipeline solutions.

Let’s discover this awesome feature to build your pipelines quickly!

Before diving into the details about building a pipeline, I’d like to remind you how JHipster is built. When you run the CLI using the jhipster command, a few parts of the generators that compose JHipster will be launched one after the other, following the core engine definitions of this sequence.

However, some of the sub-generators included in the JHipster npm package can be called manually to complete a specific task, such as creating a pipeline file definition for an existing application.

Requirements

To generate a pipeline you need to have an existing JHipster application or create a new one.

Install the last JHipster version: npm i generator-jhipster
Run the default JHipster command: jhipster
Select the options you want or use the defaults

Once the project is generated and the npm install command has been run, you can go ahead and create a pipeline.

Generate a pipeline file

In your project folder, run the following command: jhipster ci-cd.

The first step is to select what kind of pipeline you want to generate.

JHipster currently supports Jenkins, GitLab CI, GitHub Actions, Travis CI, and Circle CI.

According to the type of platform chosen, you will need to answer some questions that could be specific to it or ask for each of these provided solutions.

Here is an example of questions you have to ask if you choose GitHub Actions:

Each task adds a new step in the pipeline or adapts the configuration to match the user requirements. As per usual with JHipster, the flexibility of the generator offers a few different capabilities in the final generated product.

It could be, for example, adding a security step with Snyk dependency scanning or analyzing the code with Sonar.

By choosing Sonar here, I answered two more questions to configure it and make it work out of the box.

Finally, the pipeline definition file is generated at this path.github/workflows/github-actions.yml

The GitHub Actions Workflow file in detail

The Github Actions generated file contains a lot of defined actions to have an out-of-the-box viable CI:

name: Application CI
on: [push, pull_request]
jobs:
   pipeline:
       name: cicd pipeline
       runs-on: ubuntu-latest
       if: "!contains(github.event.head_commit.message, '[ci skip]') && !contains(github.event.head_commit.message, '[skip ci]') && !contains(github.event.pull_request.title, '[skip ci]') && !contains(github.event.pull_request.title, '[ci skip]')"
       timeout-minutes: 40
       env:
           NODE_VERSION: 14.17.6
           SPRING_OUTPUT_ANSI_ENABLED: DETECT
           SPRING_JPA_SHOW_SQL: false
           JHI_DISABLE_WEBPACK_LOGS: true
           NG_CLI_ANALYTICS: false
       steps:
           - uses: actions/checkout@v2
           - uses: actions/setup-node@v1
             with:
                 node-version: 14.17.6
           - uses: actions/setup-java@v2
             with:
                 distribution: 'temurin'
                 java-version: 11
           - name: Install node.js packages
             run: npm install
           - name: Run backend test
             run: |
                 chmod +x mvnw
                 npm run ci:backend:test
           - name: Run frontend test
             run: npm run ci:frontend:test
           - name: Analyze code with SonarQube
             env:
                 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
                 SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
             run: |
                 if [ ! -z "$SONAR_TOKEN" ]; then
                     ./mvnw -ntp initialize sonar:sonar -Dsonar.host.url=https://sonarcloud.io
                 else
                     echo No SONAR_TOKEN, skipping...
                 fi
           - name: Package application
             run: npm run java:jar:prod

By using this solution you will be able to leverage the community knowledge on CI definition and use the proper version for each tool needed such as Java and NodeJS versions. If you upgrade your JHipster version, you can generate the pipeline file again to upgrade it or upgrade yours.

This workflow executes the following steps:

Checkout the project
Install NodeJS
Install Java
Run the npm install command
Run both backend and frontend tests
Run the Sonar analysis we added during the previous step
Package the application

Update the pipeline to automatically deploy your application to Heroku

In order to turn your pipeline into a continuous deployment one, JHipster provides a simple solution using Heroku as a provider.

You simply need to select the following task “Deploy to Heroku” when you generate the pipeline.

Then a new task is added in the pipeline named Deploy to Heroku, launched only when new commits are added on the main branch. To be sure this works, you need to add a new secret in your GitHub repository HEROKU_API_KEYand have a Heroku account.

Conclusion

I hope this article helps you to understand this feature from JHipster and you are willing to use it in your applications to create great pipelines to automatically test them and reach your KPIs.

Of course, a lot of details remain to be discovered, such as the different platforms to run your pipelines or all the options provided by JHipster.

It could be another story I’d like to share with you… Stay tuned!

My top 3 advanced features you can’t miss on GitHub Actions

Anthony Viard — Thu, 20 Jan 2022 09:17:26 +0000

Hi, my fellow developers!

My last blog post showed how to use GitHub Actions to create simple Continuous Integration workflows for your projects, and today I’d like to share the advanced GitHub Actions features I find most exciting.

Here are my top 3 features you should not miss!

#1 Welcome to the matrix

No revolution here, but the matrix strategy can be explained as “Defined once, run multiple times.”Basically, it allows you to define a job structure to be run in multiple scenarios.

According to the official documentation: “A matrix allows you to create multiple jobs by performing variable substitution in a single job definition. For example, you can use a matrix to create jobs for more than one supported version of a programming language, operating system, or tool. A matrix reuses the job's configuration and creates a job for each matrix you configure.”

So when is the matrix strategy valuable? Of course, it’s hard to define all of the cases where a matrix is helpful, but here are scenarios based on my own experience:

You want to run your job over several versions of a tool, e.g. Java 11 and 17, or different OS versions
You want to inject variables to run jobs differently, e.g. change the path to your micro frontends
You want to combine the two cases above for maximum flexibility

The Entando Standard Banking Demo workflow leverages the matrix strategy to ensure that micro frontend jobs use the same definition for all components. This only changes the final subfolder of a job, and that path value is defined on the fly via variable injection.

Please note, with the include option we can specify several variable values of a job defined by the matrix strategy.

 micro-frontends:
    name: ${{ matrix.widget }} micro frontend
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        widget:
          - alert-bar-icon-react
          - dashboard-card-angular
          - dashboard-card-config
          - dashboard-card-react
          - transaction-table
        include:
          - widget: dashboard-card-angular
            test-script-name: test-ci
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2.1.4
        with:
          node-version: '14.15.0'
      - name: Run tests
        run: |
          cd $GITHUB_WORKSPACE/$PROJECT_NAME/ui/widgets/banking-widgets/${{ matrix.widget }}
          npm install
          npm run ${{ matrix.test-script-name || 'test' }}

If you’re interested in other examples of how the matrix strategy can be used, I suggest you check out JHipster pipelines. In fact, JHipster offers many options combinations to generate apps and using the matrix feature addresses most of them.

#2 Compose your jobs using composite actions

My second favorite feature of GitHub Actions is composite actions. Yes, you heard it right. You can create reusable actions and compose them to create a job.

This feature is available as of summer 2021 and lets you not only use scripts or actions from the marketplace, as you could before but also reference actions defined in separate files.

Composite actions allow you to reduce duplication and improve reusability. You can create, update and maintain one action for several jobs and workflows in the same repository.

You can also share these actions across multiple repositories, but that means you need to checkout the project where the actions belong. To do that, you will need to set up a Personal Acces Token and inject it into your repository as an environment variable.

To summarize, using composite actions is great for streamlining your actions inside a repository, or across multiple repositories for more complex cases.

Once again, in the Standard Banking Demo I exploited composite actions to improve my pipelines. For instance, I have created one action to run each time I want to run my Spring Boot backend microservice tests.

name: 'Unit testing Microservice backend application'
description: 'Run unit tests for a backend Spring boot application'
inputs:
  path:
    description: the project path
    required: true
runs:
  using: 'composite'
  steps:
    - name: Run backend tests
      shell: bash
      run: |
        cd ${{inputs.path}}
        chmod +x mvnw
        ./mvnw -ntp clean test

Please note, we need to explicitly set the using value to 'composite' and specify the shell we are using for each step (e.g. bash).

In the following action, I use one input value (a parameter) to define the path to the project. I have to set it each time I use this action.

name: Banking Plugin CI
on: push
env:
  PROJECT_NAME: banking-plugin
jobs:
  backend:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-java@v1
        with:
          java-version: '11.x'
      - uses: ./.github/actions/ms-unit-tests
        with:
          path: $GITHUB_WORKSPACE/$PROJECT_NAME
      - uses: ./.github/actions/ms-build
        with:
          path: $GITHUB_WORKSPACE/$PROJECT_NAME

Please note, to use a composite action you need to give the path to the action file (e.g. uses: ./.github/actions/ms-unit-tests), then pass parameters using the keyword with:.

#3 Link your jobs to each other

I believe linking jobs is important for creating a synergy between several jobs when you need to handle complex use cases.

The keyword needs allows you to define a job need that must be completed before another can run. If backend2 needs backend1, then backend2 will launch only when backend1 has finished successfully.

name: Banking Plugin CI
on: push
env:
  PROJECT_NAME: banking-plugin
jobs:
  backend1:
[...]
  backend2:
    needs: backend1

Or, you can decide to run the second job, even if the first one is failing.

name: Banking Plugin CI
on: push
env:
  PROJECT_NAME: banking-plugin
jobs:
  backend1:
[...]
  backend2:
    if: ${{ always() }}
    needs: backend1

Pro Tip

The if parameter allows you to run a job only when a condition is met, e.g. always() means that the job will always run (but still after the previous job has finished, successful or not). It is useful to have flexibility in your pipelines or fallback steps.

Below is an example of dependency between jobs from the project JHipster-lite. The matrix jobs need tests-windows and tests-linux to run, while codecov needs all the matrix jobs.

Conclusion

In this blog post I’ve shared what I like the most about GitHub Actions in an advanced scenario. From my own experience and the different projects I’ve seen on GitHub, these three features were best suited to complete some of my use cases. However, your own experience and needs will determine what works best for you.

What are the best features you’ve used already in your GitHub Actions workflows? Feel free to share it with us on Twitter!

GitHub Actions using the Standard Banking Demo: Put Your First Workflow in Action

Anthony Viard — Mon, 10 Jan 2022 18:01:15 +0000

Initiate the Github Actions Workflow

To understand this article you’ll need to reference the Standard Banking Demo, which is a sample modular project provided by Entando.

Because this project contains multiple applications, we have to create one workflow per application to separate them into clear pipelines.

In this tutorial, we are going to define a workflow for the Banking microservice and the related micro frontends.

After checking out the project, create a file at this location: .github/workflows/banking-plugin-ci.yml

Copy the global properties at the top of the file:

name: Banking Plugin CI
on: push
env:
 PROJECT_NAME: banking-plugin
jobs:

name is the workflow name
on defines the triggers the workflow is listening to
env defines a list of reusable environmental properties available to the workflow
jobs is the list of jobs the workflow executes

Add a Backend Job

The first job performs this sequence of steps:

Checkout the project
Install Java 11
Run the backend tests
Package the application

Each job is a new entry in the job list and runs concurrently with the other jobs.

The job has to declare the runner it uses and the sequence of tasks, or steps, it executes.

jobs:
 backend:
   runs-on: ubuntu-latest
   steps:

Please note this “backend” entry matches the job name used in the GitHub Action UI.

To define a step, you can either use existing actions from the marketplace, create your own composite actions with uses, or run a bash command with run.

steps:
 - uses: actions/checkout@v2
 - uses: actions/setup-java@v1
   with:
     java-version: '11.x'
 - name: Run backend test
   run: |
     cd $GITHUB_WORKSPACE/$PROJECT_NAME
     chmod +x mvnw
     ./mvnw -ntp clean verify
 - name: Package application
   run: |
     cd $GITHUB_WORKSPACE/$PROJECT_NAME
     ./mvnw -ntp package -Pprod -DskipTests

Please note the commands use environment variable values ($GITHUB_WORKSPACE/$PROJECT_NAME) provided by GitHub Actions or defined at the workflow or job level.

Add a Matrix Job for the Micro Frontends

The matrix feature allows you to run multiple jobs with the same configuration of matrix variable values.

Each matrix variable is usable in the job via a template ${{ matrix.NAME> }}, for example ${{matrix.widget}} in the code below.

Learn more about the matrix feature in the official documentation.

Initiate the Matrix Job

At the same indentation level as the backend, add a new entry named micro-frontends.
Use the matrix variable to differentiate each job by name.
```
name: ${{ matrix.widget }} micro frontend
```
Copy the runner definition from the previous job description.

Add the list of micro frontend names to the matrix strategy. Setting the fail-fast to false allows the jobs to continue if one or more is failing.

strategy:
fail-fast: false
matrix:
widget:
 - alert-bar-icon-react
 - dashboard-card-angular
 - dashboard-card-config
 - dashboard-card-react
 - transaction-table
include:
 - widget: dashboard-card-angular
   test-script-name: test-ci

Add steps to checkout the code, install NodeJS, and run both npm install and npm test.

steps:
 - uses: actions/checkout@v2
 - uses: actions/setup-node@v2.1.4
   with:
     node-version: '14.15.0'
 - name: Run tests
   run: |
     cd $GITHUB_WORKSPACE/$PROJECT_NAME/ui/widgets/banking-widgets/${{ matrix.widget }}
     npm install
     npm run ${{ matrix.test-script-name || 'test' }}

Please note that the include option allows you to define specific properties for a given matrix strategy. The test-script-name in the Angular widget is unique, so we can leverage the include feature to switch to it from the default name.

The final job definition should be as follows:

micro-frontends:
 name: ${{ matrix.widget }} micro frontend
 runs-on: ubuntu-latest
 strategy:
   fail-fast: false
   matrix:
     widget:
       - alert-bar-icon-react
       - dashboard-card-angular
       - dashboard-card-config
       - dashboard-card-react
       - transaction-table
     include:
       - widget: dashboard-card-angular
         test-script-name: test-ci
 steps:
   - uses: actions/checkout@v2
   - uses: actions/setup-node@v2.1.4
     with:
       node-version: '14.15.0'
   - name: Run tests
     run: |
       cd $GITHUB_WORKSPACE/$PROJECT_NAME/ui/widgets/banking-widgets/${{ matrix.widget }}
       npm install
       npm run ${{ matrix.test-script-name || 'test' }}

This job configuration generates five jobs in addition to the previous one:

The Final Workflow Definition

name: Banking Plugin CI
on: push
env:
 PROJECT_NAME: banking-plugin
jobs:
 backend:
   runs-on: ubuntu-latest
   steps:
     - uses: actions/checkout@v2
     - uses: actions/setup-java@v1
       with:
         java-version: '11.x'
     - name: Run backend test
       run: |
         cd $GITHUB_WORKSPACE/$PROJECT_NAME
         chmod +x mvnw
         ./mvnw -ntp clean test
     - name: Package application
       run: |
         cd $GITHUB_WORKSPACE/$PROJECT_NAME
         ./mvnw -ntp package -Pprod -DskipTests
 micro-frontends:
   name: ${{ matrix.widget }} micro frontend
   runs-on: ubuntu-latest
   strategy:
     fail-fast: false
     matrix:
       widget:
         - alert-bar-icon-react
         - dashboard-card-angular
         - dashboard-card-config
         - dashboard-card-react
         - transaction-table
       include:
         - widget: dashboard-card-angular
           test-script-name: test-ci
   steps:
     - uses: actions/checkout@v2
     - uses: actions/setup-node@v2.1.4
       with:
         node-version: '14.15.0'
     - name: Run tests
       run: |
         cd $GITHUB_WORKSPACE/$PROJECT_NAME/ui/widgets/banking-widgets/${{ matrix.widget }}
         npm install
         npm run ${{ matrix.test-script-name || 'test' }}

Conclusion

After exploring GitHub Actions in the first article, we learned how to build a successful workflow using the real-world example of the Entando Standard Banking Demo.

Depending on your needs, your workflow can be modified to add more steps such as security, quality scanning and/or event UI testing. These automatic gates keep the focus on your high-level priorities while ensuring your applications continue to support the requirements and needs of your enterprise.

Stay tuned for part 3 of this series. I’ll be sharing my top 3 advanced features - don’t miss this one!

I render this code like a pro

Anthony Viard — Tue, 21 Dec 2021 11:39:53 +0000

In the past, I struggled so many times trying to properly render a piece of code, considering the indentation, the coloring syntax, and so on.

Then I discovered PrismJS, a lightweight Javascript library that generates the HTML tags needed to wrap code snippets with a wonderful rendering.

It simply uses <pre> and <code> existing tags and the language specified in the CSS class name.

Hmm, what about making this feature reusable by using a component on Entando, the Application Composition Platform?

Of course! Not only is this feature available to me, but also our entire community can easily access it by installing an existing component collection!

To help explain, I created this quick and nifty video below. We’ll walk through becoming a developer, to a developer-contributor and save time (and our sanity) for future solutions.

Step by step, we’ll explore in detail: creating your components, defining bundle descriptions, and sharing on a GitHub repository to use in a sample blog page. The bundle will then be installed and deployed on an Entando instance.

After watching this video, drop a quick comment and share what THE one component is that you would like to share with the community.

Tune in next time as we continue our adventures in this composition world!

Additional resources

Start with Entando components: https://dev.entando.org/v6.3.2/docs/ecr/ecr-bundle-details.html#overview

Start with our JHipster generator, the Entando Component Generator:

https://dev.entando.org/v6.3.2/docs/component-generator/component-gen-overview.html

Learn more about the Entando Component Repository:

https://dev.entando.org/v6.3.2/docs/ecr/ecr-overview.html

Get Started with GitHub Actions

Anthony Viard — Tue, 21 Dec 2021 11:39:15 +0000

Hi, my fellow developers,

Pipelines to perform automation tasks have become a standard in an application lifecycle and have even become a requirement with DevOps adoption.

You probably have already heard about Continuous Integration and Deployment and you are using GitHub as a repository provider.

Did you know GitHub can also meet your automation needs, with GitHub Actions providing a full out-of-the-box feature?

In this blog post, we cover the GitHub Actions introduction and dive into the details of a Workflow definition.

Enjoy!

Why you need a CI/CD

First, let’s define CI/CD and explain why we have to differentiate these concepts.

Continuous Integration

CI refers to “Continuous Integration,” an automation process for development teams. The aim of a CI is to smoothly integrate changes made by different developers and ensure team requirements are reached. CI can run unit tests but also addresses code coverage, bug finding, or technical rules decided by teams (e.g. avoid repeated code blocks). This helps a lot when working with several different branches, maintaining the quality level and improving trust in the code.

Continuous Delivery/Deployment

Continuous Delivery is the ability to automate code releases by adding gates in the pipelines that ensure the product is ready to go live.

This also means automating some manual steps, such as enabling the process to manage all the security steps for you (e.g. checking, signing, uploading). This can help the deployment run smoothly and improve collaboration between the development and the business teams.

However, CD could also refer to Continuous Deployment, which is a continuous process from creation to production.

In this case, the pipelines will automatically deploy each new version of your application into production after it is passed through checking gates.

Whatever you want to do with your pipelines, you will need to define requirements and processes across all the different teams involved.

Tools such as GitHub Actions, Gitlab CI and Jenkins help you to build these pipelines and integrate them into your CI. Here I will mostly focus on GitHub Actions.

Automate your processes with Github Actions

GitHub Actions is a feature provided by GitHub teams to automate development lifecycles. It’s available out-of-the-box with any GitHub repository.

GitHub Actions Components

GitHub Actions Components use Events to trigger specific processes.

According to the GitHub Actions naming nomenclature, an Event triggers Workflows composed of Jobs, which execute Steps on Runners. Within a Step, you can execute Actions, which are the smallest components of the GitHub Action framework.

Runners are servers hosted by GitHub (Ubuntu Linux, Microsoft Windows, or macOS), or even your private Runners. It is useful to reuse existing servers or switch to a specific environment.

Create your first Workflow

GitHub Actions Workflows are based on Yaml files that you have to declare in the .github/workflows folder at the root project level, then commit and push to your Git repository.

Here is an example of a Workflow I have in some of my Monolith sample applications.

name: Application CI
on: [push]
jobs:
run-tests:
 runs-on: ubuntu-latest
 steps:
   - uses: actions/checkout@v2
   - uses: actions/setup-node@v1
     with:
       node-version: 12.18.3
   - uses: actions/setup-java@v1
     with:
       java-version: '11.x'
   - name: Install node.js packages
     run: npm install
   - name: Run backend tests
     run: |
         chmod +x mvnw
         ./mvnw -ntp clean verify -P-webpack
   - name: Run frontend tests
     run: npm run test

The name is optional, but I recommend assigning an appropriate name to have a better overview of your Workflows in your GitHub Actions tab.
on defines Events to trigger the Workflow. In our example, the Workflow will trigger each time a new commit is pushed on any branch of our application.
jobs consists of the Job list contained in this Workflow. We have included one Job, run-tests in our Job list.
runs-on defines the kind of Runner you want the Workflow to run on. Here we’ve selected the last available Ubuntu version.
steps defines the list of Steps the Job will execute. Our Steps can either use existing Actions or only run simple bash commands. Using with in an existing Action allows us to pass parameters.

To summarize, this Workflow will be triggered each time a new commit is pushed on any branch, execute a Job named “run-tests” on a Ubuntu server, and perform this sequence of Steps:

Checkout the project
Install NodeJS using the dedicated Action
Install Java using the dedicated Action
Run the npm install command
Use Maven to run the backend tests
Use npm to run the frontend tests

You can learn more about this in the official documentation.

The GitHub Actions Marketplace

If you want to improve your Workflows by reusing Actions provided by the community, the marketplace is the place to visit.

The Actions can be created by the official Actions account, by organizations, individuals, or companies. Calling an Action can help you to execute a specific step instead of writing the commands yourself.

Leveraging Actions is a great way to easily set up your environment (e.g. install a JDK), integrate popular tools such as Docker and Ansible, or call a third-party solution (e.g. Create an issue on Jira).

When you are comfortable with your Workflow definition, I’d recommend checking the Marketplace to explore how to simplify the Yaml file, make the workflow more readable, and reuse existing Actions.

Plan and pricing

GitHub Actions is free with public repositories. That means you have unlimited automation minutes, while private repositories limit minutes to 2000 per month. Upgrading to a paid plan will grant you access to more minutes for your private repositories (3000 and 50,000 for Teams and Enterprise plans, respectively), and also include more package storage.

You can find more information on this page.

Regarding the usage, some limitations are applied to avoid using too much bandwidth with your Workflow:

A Job can’t run continuously for more than 6 hours; the execution is halted when this limit is reached.
A Workflow can’t run continuously for more than 72 hours; the execution is halted when this limit is reached.
API requests are limited to 1000 calls per hour across a repository.
Concurrent jobs are limited by plan, from 20 (free) to 180 (Enterprise). Please note for MacOS Runners you are limited from 5 to 50.
Any job launched after the limit is reached will be placed in a queue.
The queue can’t host more than 500 jobs in a 10-second interval.

What’s next

This is a good first step into the world of GitHub Actions. We’ve presented the CI/CD concepts, the GitHub Actions overall operation, how to define a good first Workflow, and limitations.

The next blog post will cover a real-world example of how we can create a Workflow based on a real-world project using the Entando Standard Banking Demo.