Semantic Versioning

When the development scope is being incremented, the complexity of development, Testing & Releases would be more complicated in Continuous Integration & Continuous Delivery pipelines. Downloading dependencies in software packages, and versioning is even more complicated of frequent releases if there is no well defined mechanism. Semantic versioning is one of the solution for reduce this complicated hassle.

Version is more important to developers to track their historical tracking, it gives a well defined versions of software releases. Therefor it adds more befits to the software development as well as CI/CD pipelines.

Benefits of Semantic Versioning

  • Historical tracking of code development.
    At any point developers can get the idea of code status from any historical point.
  • Universal builds packages are available to anytime deployment.
    Build can be triggered from any of previous tags, and it includes all the required dependency and other configurations. Therefor those tags can be easily used for build project deliverable as required from history.
  • Easily identify the code changes including API, functional and bug fixes.
  • Helps to manage releases and code development.

Semantic Versioning Format

There are three Major parts are in semantic versioning, Major, Minor & Patch.

  • Patch : Patch is where the developers change code to bug fixes after production deployment. This part is only changed when other major & minor are remained as it is. And this change should be backward compatible Please take a look on below example.
    v1.3.4 //before bugfix
    v1.3.5 //after bugfix
  • Minor : minor part also a backward compatible changed in functional requirements. When there is a feature development for a release, which is versioned with minor part of the version number, and this feature should be backward compatible. Below example shows the feature development versions.
    v1.3.5 // before feature development
    v1.4.0 //new feature development
  • Major : Major version defines about a massive change with backward incompatible of code change. That may a API change, architectural change or related changes.
    In such a major version is released, it cannot be revert back to a previous version since there a backward incompatible changes.

    v1.4.0 // before major change
    v2.0.0 // after major change

There are some several basic rules that everyone adopts in the semantic versioning.

  • Initial development should start with v0.1.0
  • When you want to release as first release from the project, it should be changed to v1.x.x

Best practice of versioning is very convenient way of improving software delivery cycles including CI/CD. Since most of the companies are adopting with DevOps and Agile practices, best practice of versioning is most important.


AWS CodePipeline for Continuous Delivery & Continuous Integration

AWS Codepipeline is one of the best CI/CD tool and which can be configured from developers’ code changes through production deployment. This tool visualizes and automates workflow and can be integrated with pre-configured tools to make the flow easier.

AWS CodePipeline

As in the above figure, AWS CodePipeline has been divided in to five categories.

Source : This is where the code repository is configured, this can be a 3rd party repository or AWS Codecommit lab. Any code change will be triggered soon after the code repository is updated.
Read More »

Jenkins | Deploy & Configure for Play Applications in RHEL 6.x

Jenkins is an open source server for continuous integration and written by JAVA. This is one of a world famous CI(Continuous Integration) tool. This tutorial guides you through the steps to deploy Jenkins server on RHEL(Red Hat Enterprise Linux) server. The steps are given below.

  1. Check the JAVA is available on the RHEL server.
    # java -version
    Output : java version “1.8.0_45”
    Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
    Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
  2. If there is no JAVA is installed on your, install java and get it confirmed that’s installed.
    # yum install java
  3. Add the Jenkins repository to the host machine, then install the rpm file.
    wget -O /etc/yum.repos.d/jenkins.repo
    rpm –import
  4. Install Jenkins server
    # yum install jenkins
  5. Adding jenkins to system boot
    # chkconfig jenkins on
  6. Start Jenkins and check the port 8080 is opened from the server side.
    # service jenkins start
    # netstat -tnlp | grep 8080
  7. Open your browser and load Jenkins server http://:8080
    Screen Shot 2015-05-07 at 3.49.05 PM
  8. After successfully deploy the Jenkins server, you can setup the server to build scala applications. In here the application code will be retrieved from the git server, so git server should have a separate user for jenkins. In order to achieve that, user have to generate a SSH key file from the host machine.
    Read More »