DEV Community: Kenneth Atria

Git practices with Git flow and semantic-versioning

Kenneth Atria — Tue, 24 Aug 2021 17:40:24 +0000

There are a few things i wish i knew when i started software development and among them are methodologies like git-flow and semantic versioning.

We shall start off with understanding what git-flow and semantic versioning then finish up experiment with git-flow.

GIT STRUCTURE

Setting up the right git structure earlier will set your project for success

OVERVIEW

We create two mandatory branches which are the Master and Development branches that we shall base our temporary branches from.

Temporary branches:

Hot fixes: This is from the master branch and merged back into master. This branch is used when a fix can’t wait for the next release from development and a fix is urgently needed.
Releases: This is got from development branch and is merged back into development. This branch contains what is staging
Features: This is the same as the releases branch coming from our development branch. This temporary branch is used when creating new features, minor updates and patches.

Using the above structure we created with semantic versioning
Semantic versioning is a means of versioning releases in your development environment. This can help you keep track of everything and help reduce the so-called dependency hell during release.

For example: v1.1.1(M.M.P standing for MAJOY-MINOR-PATCH). So, 1.2.1 to 3.3.4 would translate to 2 major changes that are not backward compatible, 3 minor changes and 4 patches backward compatible from version 3.0.0.

What are major changes?
Changes made to configuration that are not backward compatible. This will include:
addition of application workflows

supporting functions to new application workflows What are minor changes? modification made to configuration that are backward compatible. This will include:
modification to features to improve performance What is a patch? This includes bug fixes that are backward compatible

Using our git structure and Semantic versioning together

So we have a work request for the development of a new feature.

A temporary feature branch is created from development branch that is at v3.6.5
Branch under goes changes as feature development is in progress
Not just one developer is working on this but it’s a collaboration of more than one developer
We finally have branch @v3.9.9 ready for release and testing on our staging instance
A temporary release branch is created based off development @3.6.5 and is used to introduce changes from the ready feature branch

Okay !!! I guess Ninjas want to start doing this the hard way but we have git-flow to help us with this.

Let's open up that shell and wrap up this

Setting up git-flow. for this case Ubuntu
apt-get install git-flow

Initializing git-flow : In your project git flow init You will prompted to input your master, development and temporary branches(support, hotfix, feature). You can rename this branches to suit your branch-naming-convention

note : incase you want to change your master branch to let's say main just run : git flow init -f

Start feature development : git flow feature start feature-x If you input git branch you will notice feature-x branch has been created
Publish a feature : git flow feature publish feature-x. The feature is now available on remote, allowing other developers collaborate on to feature-x

incase your development branch is updates to continue working with what's up to date run git flow feature rebase

Collaborating developers : git flow feature pull origin feature-x
Finish up a feature : git flow feature finish feature-x And that's it, feature-x branch has been merged into development and been deleted. if you input git branch you will verify this

Getting features out
git flow release start feature-x-release
you can also add to the end of the above command to
create a release branch based off of development branch at a certain point in time.
git flow release finish feature-x-release
don't forget to use tags

Finally Hotfixes
git flow hotfix start feature-x-patch
Again you can add a at the end of above command to start at a certain point of the master branch.
git flow hotfix finish feature-x-patch

Other considerations

Don't forget to set up branch protection rules for your development and especially master branch.
Assign one or two team members(preferably two) the responsibly of monitoring policies you set around git usage.
keep looking out there for new standards to improve your current standards

Conclusion:

Git-flow does make things easier and keeps things sane but am not saying methodology is one shoe-size fits all, You will need to adjust it to your needs. I would also encourage you to look up Trunk development that suits teams trying to get that MVP out there as fast as possible.

Hope this helps, Have fun doing and learning.

Setting up a CI/CD with Jenkins

Kenneth Atria — Mon, 16 Aug 2021 22:41:41 +0000

What you need ?

Dockerhub and Github Account
Server with linux setup. For this case ubuntu
Your application is already configured on your test instances
This tutorial assumes you have set up a Jenkins file in your project. View reference and make necessary changes

1. Installing Jenkins on your Server

sudo apt update

search of all available packages & pick one from the options
sudo apt search openjdk

For this case I will be using version 11, so
sudo apt install openjdk-11-jdk

Confirm installation with running version check
java -version

Now we are ready to install Jenkins. We start off by appending the Debian package repository address to the server's sources.list

wget -q -O - https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo apt-key add - sudo sh -c 'echo deb https://pkg.jenkins.io/debian-stable binary/ > \ /etc/apt/sources.list.d/jenkins.list'

We'll run update so that apt will use the new repo
sudo apt-get update

Installing Jenkins
sudo apt-get install jenkins=2.289.3

That's all

2. Setting up your Github and retrieving an API key

Login into your Github, and head over to your developer settings : Profile -> Settings -> Developer settings -> Personal access tokens

Note: I wouldn't consider this optional but it's good practice to set an expiration duration for your token.

Select admin:repo_hook

Lastly set repo: *repo_status*. Jenkins likes to access the repo commit status

Click "Generate token" and save your token somewhere.

3. Setting up Jenkins

3.1 Setting up an Administrator

1.SSH in your Jenkins instance
2.To retrieve your temporary password
sudo "cat /var/lib/jenkins/secrets/initialAdminPassword"
3.Visit <your-instance-ip:8080>
4.Paste retrieved password into Jenkins start up page.
5.Go ahead and set up a permanent admin user on Jenkins

3.2 Setting up your Jenkin Projects

1.Log into Jenkins

2.Set up credentials in Jenkins will use to login into servers.
Click Credentials -> click global -> click add credentials and input your instance username: deploy, password :+++++, id: webserver_login

3.Set up docker hub credentials too:
username: username, password :access-token, id: docker_hub_login

4.Set up global properties in Jenkins for staging server
Click "Manage Jenkins" - "Configure System" - "Global properties and select Environment Variables" -> Add
input "name: staging_ip" and "value:staging-ip-address"

5.Set up Jenkins project
Give your project a name -> Select Multibranch pipeline for project type

Under branch sources: click add source -> GitHub
Enter the details and use your GitHub access token as password and Github username as the username, set id e.g "github_key" and description

Select github_key for credentials
Input your GitHub name into owner field
Set repository as intended repo
Go a head and Save

Jenkins will scan your repo and run an initial build

Click Jenkins, In the project - click Master -> Build now

Next up

Powering up and down developer AWS instances using Slack and Jenkins