DEV Community: Wahdan

Semantic Release Automation - Part 3 - deploy to github pages

Wahdan — Mon, 25 May 2020 20:56:12 +0000

In part 2 of Semantic Release Automation series, we configured our Continues Integration part in our workflow using semantic release package along with Github Actions and GitHub Packages. Now lets go live and configure the deployment workflow using Github pages.

Prerequisites
Configure repository settings
Update Github Action

Prerequisites

Basic knowledge of CI/CD workflow, you can refer to my 2 mins article about this topic.
Create Github token, this will be used by Github pages action ( you can skip this part if you have already created it in the previous series).

Configure repository settings

In your Github repository, Create a new branch from your main branch with name gh-pages.
Navigate to settings option.
Go to GitHub Page section.
Make sure that your are selecting the source branch to gh-pages which you created before.

Now copy your site URL and open your package.json file add homepage key with your site URL as a value.

Update Github Action

To simply things for us we are going to use a ready action to deploy to github pages. You can find a full example in the following gist below:

Now push a new commit and watch your pipeline in action, in a successful scenario you should find the build results in gh-pages and your code is deployed to your site URL.

Thanks for reading, waiting your feedback.

Cover Design Credit: Infographic vector created by studiogstock - www.freepik.com

Critical Rendering Path

Wahdan — Mon, 25 May 2020 19:47:11 +0000

Measure then optimize, That being said, the following course/documentation from (Google and Udacity) will explain what is critical rendering path (CRP) and how it is related to web performance.
👉 Course / documentation link

Semantic Release Automation - Part 2 - Setup Semantic Release Package

Wahdan — Wed, 20 May 2020 05:00:03 +0000

Previously I talked about semantic version and why it is important to follow the guidelines for versioning, in this part of the series i will talk about how to maintain the package versioning automatically using semantic release package.

Here is a short description about semantic release from the authors:

semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.

Semantic release is relying on the commit format to determine the next release based on it. You can configure any format you want, the default format is angular message format. for example if we have a package version 1.0.0, a commit message with this format:

feat: added new feature will bump the version to 1.1.0
fix: added more config will bump the version to 1.0.1

For more details about how semantic release works you can find it here.

Note: If you didn't follow the naming conventions, semantic release package won't be able to determine the next release version. Also it would be a problem when you have a large team and you want all of them to follow the rules, luckily there are packages for this, we will talk about them shortly.

I will use semantic release in a simple react project and will use Github actions along with Github packages to automate our workflow.

You can find a full example that we want to achieve at the end of this series here. Get Ready 🔥

Prerequisites 📋
Installing semantic release package 📦
Configure Semantic Release package ⚙️
Pipeline Setup ▶️
See the workflow in action 🧪

Prerequisites 📋

Basic knowledge of CI/CD workflow, you can refer to my 2 mins article about this topic.
Installed npm >=5.2.0
Installed Git.
Fresh repository hosted on Github.
Create Github token, this will be used by semantic release package.

Installing semantic release package 📦

We will use sematnic release CLI package for quick installation. This will help us to configure multiple things:

Git repository.
Package Manager repository (Github packages)
Continuous Integration platform (Github actions) Use this command to configure our workflow:

npx semantic-release-cli setup

You will be asked several questions about your credentials and configuration

NPM registry the registry which you will store your package on it, in our case this we will use Github packages, so copy this url https://npm.pkg.github.com/ and press enter.
Authentication Method Choose token based authentication.
NPM username here we will configure our Github packages credentials, so you need to enter your github username.
NPM password this will be the github token which you have generated it earlier.
Github username this will be the same as username you enterd in NPM username, so enter it again 😅.
Github password wrtie your Github password.
Which CI we will be using Github actions, so choose the last option (other).

If everything goes Ok, the CLI will print out GH_TOKEN and NPM_TOKEN. These values will be used by our CI (Github actions), to be able to push automated commits and publish your package to Github packages.

Now we are going to use GH_TOKEN and NPM_TOKEN and we will create new secrets in Github, which will be used by our pipelines.Go to your repository settings -> find secrets tab in the left panel -> create two secrets, one for GH_TOKEN and the other forNPM_TOKEN. See below image:

Edit your package.json file and add our publish config:

    "publishConfig": {
        "registry": "https://npm.pkg.github.com/",
        "pkgRoot": "build"
    }

pkgRoot key is a path to your build directory, here we are using create-react-app to build our package and produce the result to build directory. With these configations we will able to publish our package to Github packages.

Also change the version value of your package.json file and let it start with 1.0.0

"version":"1.0.0"

Configure Semantic Release package ⚙️

Semantic Release has several configuration out of the box, we will use some of them to build our workflow:

Create a new file (.releaserc.json) in your root directory (there are other ways to create this file.
copy the content of this gist to your .releaserc.json file and change repositoryUrl to your repository url.

You may want to follow the documentation for more clarification.

The default plugins used be semantic release package are ['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']

I added two more external plugins @semantic-release/changelog (to create an automated changelog file) and @semantic-release/git (to bump version in package.json and package-lock.json files and create a new commit with this change)

Dont forget to install them in your dev dependencies

npm install @semantic-release/git -D && npm install @semantic-release/changelog -D

Pipeline Setup ▶️

To Define your Github actions, create .github folder in your root project path and add workflows folder inside it. After that create your action, for example : ci.yml. A full path should be like this .github/workflows/ci.yml.

Here is a full example of basic CI using semantic release command, copy this example to your action file and replace SEMANTIC_RELEASE_GH_TOKEN and SEMANTIC_RELEASE_NPM_TOKEN with your secrets name.

You may noticed that we add this condition the build process if: "!contains(github.event.head_commit.message, 'skip ci')", this means that any commit message contains skip ci will not trigger complete the process of the pipelines, this is useful you wish to pervert unnecessary pipelines triggers for some commit messages.

See the workflow in action 🧪

Now push your commits to your repository and navigate to actions tab in your repository and watch your pipelines progress. If everything goes well you should see a green indicators in all of action's steps.

Semantic release package has created a new release, you can view it in releases tab. Also you can view your deployed package at packages tab

Configurations🎉 now you have a built a basic automated workflow with github actions and semantic release package. Next we will continue our setup and implement the continues deployment part to deploy our app to Github pages.

Thanks to freepik platform, i was able to build my article covered using their awesome designs.
Business vector created by macrovector - www.freepik.com

Bored? 🙄 see what you can do now

Wahdan — Thu, 16 Apr 2020 23:11:22 +0000

Hello World,

We have made a small funny game to see what you can do now. You can try it here .

Note: the content needs more of your contribution.

Slow network simulation using Chrome devtool

Wahdan — Tue, 14 Apr 2020 09:59:18 +0000

Chrome devtool team are developing more and more features to make our development activities easier. One of these interesting features is simulating network speed. you can do this with five simple steps only, lets see this in a practical way:

Press Command+Option+I (Mac) or Control+Shift+I (windows/linux) to open chrome devtool.
Navigate to network tab.
A small dropdown list will appear with default value online. Here you can change the network to another option like slow 3G
Open dev.to
Reload the page and see the magic

Also you can create your own network settings, just click on custom option and type your download/ upload/ latency values.

Here is an offline example for dev.to using offline preset option 😄

Thanks for reading and happy hack week ✌️.

Package alias name using NPM/yarn

Wahdan — Fri, 14 Feb 2020 17:08:51 +0000

Have you ever tried to install a package under an alias? you can do this using NPM or yarn. Lets try to rename lodash package to another name.

with NPM:

npm install yourPackageName@npm:lodash --save

with yarn:

yarn add yourPackageName@npm:lodash

Now you can import your aliased package with

const yourPackageName = require('yourPackageName');

Happy hack week 😎

A practical and fast way to learn Markdown syntax

Wahdan — Sat, 19 Oct 2019 11:00:31 +0000

Go ahead and write an article on dev.to, it's the best way to get started with markdown.

Continuous integration, continuous delivery and continuous deployment in a nutshell

Wahdan — Thu, 17 Oct 2019 20:26:27 +0000

Many people misunderstand between continuous integration, continuous delivery, and continuous deployment terms. In this article, I am going to simply these terms in simple words.

What is Continuous Integration

When you finished developing on a feature branch and you want to merge your code back to your main branch. You need to run your tests before merging to the main branch to make sure that your feature is not breaking anything. This repetitive task is called continuous integration, but doing this manually every time before merging to the main branch is boring and it will be an issue in large teams. Thanks to CI tools such as Jenkins, Travis CI, and circle CI, you can run your tests automatically and apply CI in your workflow.

What is Continuous Deployment

Continuous Deployment is all about releasing your app without any human interaction, so whenever a new code is merged to the main branch (after passing your tests), there will be a new release on your production environment.

What is Continuous Delivery

Continuous Delivery is different from Continuous Deployment in only one thing, you need to click a button to deploy your app or decide when can release your application (human interaction is required).

Now the question is: what is the best choice, Continuous Deployment or Continuous Delivery?

Answer: This depends on your business needs. If you don't have users yet in your system, then continuous deployment should fit your needs, otherwise, you need to follow the continuous delivery approach. I believe you can mix between those two approaches in your workflow by applying continuous deployment on your development branch so that whenever you merge your code to development branch, your app will be deployed automatically on the development environment. If you want to proceed to production, you need to click a button to release your app on production environment.

Here is a simple illustration:

Block specific URL using match pattern with Chrome

Wahdan — Fri, 11 Oct 2019 11:05:47 +0000

Today we are going to learn about blocking some URL with Chrome. There are many use cases to block a specific URL, one of them is that you need to test your application behavior when your images are not accessible anymore for any reason. Chrome has provided a built-in feature to do this, let's discover it.

The steps

1 - To access the DevTools, open a web page in Google Chrome and Right-click on any page and select Inspect.
2 - Click on three-dots icon ( at the top right of the DevTools).
3 - Navigate to more tools option.
4 - Click on the Request blocking option.

5- A new section is opened like the below image:

Click on Add pattern. This will show up a text field.

In the text field, you can write down any specific URL to block for example, https://www.websiteToBlock.com. Or you can use a pattern such as https://*.websiteToBlock.com/foo*, this will block any subdomain of websiteToBlock as long as the path starts with /foo and uses https schema. For more details about Match patterns, you can follow these references from Google Chrome and Mozilla.

Have a nice testing day.

Semantic Release Automation - Part 1 - Understanding Semantic Version

Wahdan — Thu, 26 Sep 2019 20:41:34 +0000

Have you ever wondered why any software package must have a version number? what is the difference between this version 1.0.0 number to this one 1.1.0?

Motivation
What Is Semantic Versioning
Updating Your Package Version
About Semantic Release Package

Motivation

In javascript world, we have multiple package managers such as npm and yarn that handle your dependencies in your application. They provide a bunch of features to make your life easier, you can view these features on their websites.

With each package you installed in your application, there is a version number on each one of them.

What Is Semantic Versioning

Semantic versioning is a set of rules that dictate how version numbers are assigned and incremented. The image below describes what each number means:

So if:

The first number from the right is incremented (patch). It means that there is a new hotfix/bugfix on this package.
The middle number is incremented (minor). It means that there is a new feature.
The last number from the left is incremented (major). It means that there is a breaking change.

It is important to highlight that it should be safe to update the package if there are any patch/minor changes (backward compatibility). If you find any major change, you have to double-check the package's release notes before upgrading its version.

Updating Your Package Version

There are two ways to update your package version, either to do it manually or by using npm commands or yarn commands. If you don't have any package yet you can create a new one by running this command:

npm init

yarn init

Assuming that the current version of your package.json is 1.0.0. If you run this command

npm version patch //1.0.1

This will update your package.json version and it will be set to 1.0.1.What is happened under the hood is npm will read your package.json version and will update its value. You may also like to try out these commands and see the results

npm version minor //1.1.0

npm version major //2.0.0

so whenever you have done with your feature/bugfix or any other change you can use run these commands to update your package version. but there is a problem here, what if we are working within a team and each one of them will run these commands, what is the final version? how to avoid this conflict? even if you are working alone, trust me life is too short to run these commands every time after finishing your stuff.

About Semantic Release Package

semantic release package is designed to automate your releases with many features like:

Create and update CHANGELOG file
Publish your packages to any registry.
Update package.json version.
Integration with any continues integration tool.
Integration with GIT Hosted services.

In my next article, I am going to explain how to set up this package in your project and automate your workflow.

JavaScript’s Primitive Wrapper Objects (the hidden feature)

Wahdan — Mon, 23 Sep 2019 19:55:34 +0000

Prerequisites

To understand this article we need to know more about primitive data types in javascript.

There are seven data types in javascript:

String
Number
Boolean
Object
Null
undefined
Symbol

Primitive data type means it is not an object and has no methods. All primitives are immutable (the value cant be altered). Let's see the following example:

we declared a primitive variable called result and a function that adds five to the result. The output is zero because addFive function creates a local copy of result and adds five to it and then the local copy variable is destroyed.

Keep in mind that there is a difference between altering the value and reassigning the value of a variable.
let number5 = 5; number5 = 10; //(number5 variable is reassigned to a new value (10)
Now we are ready, let's back to our main topic.

Motivation

Have you ever wondered how this line of code even works?

You declared a primitive type (String) but still, you can use toUpperCase method, one of String object methods, how is that possible? another good question, if we can use String methods on str then we can treat it as an object and set properties on it like this one :

But it outputs undefined! sounds weird right?

Explanation

If you try to access properties or set a new property on a string primitive type, javascript will create a temporary object wrapper implicitly on it using String constructor function. See the following example:

As you can see, a temporary object wrapper was created when you tried to set the custom property to str, and the result is 1, after that the temporary object wrapper is removed and the custom property doesn’t exist anymore.

Except for null and undefined, all primitive values have object equivalents that wrap around the primitive values.

Keep in mind that javascript engine doesn’t keep this wrapper object around, as soon as the work of the method or other property is done, it is disposed of.

Thank you for your time, please Don’t hesitate to comment below if you have any questions.

DEV Community: Wahdan

Semantic Release Automation - Part 3 - deploy to github pages

Table of contents

Prerequisites

Configure repository settings

Update Github Action

Critical Rendering Path

Semantic Release Automation - Part 2 - Setup Semantic Release Package

Table Of Contents

Prerequisites 📋

Installing semantic release package 📦

Configure Semantic Release package ⚙️

Pipeline Setup ▶️

See the workflow in action 🧪

Bored? 🙄 see what you can do now

Slow network simulation using Chrome devtool

Package alias name using NPM/yarn

A practical and fast way to learn Markdown syntax

Continuous integration, continuous delivery and continuous deployment in a nutshell

What is Continuous Integration

What is Continuous Deployment

What is Continuous Delivery

Block specific URL using match pattern with Chrome

The steps

Semantic Release Automation - Part 1 - Understanding Semantic Version

Table Of Contents

Motivation

What Is Semantic Versioning

Updating Your Package Version

About Semantic Release Package

JavaScript’s Primitive Wrapper Objects (the hidden feature)

Prerequisites

Motivation

Explanation