Abhinav Rai

Devops — Phase 1

Why should we know devops?

My profile reads product engineer. I build products. So as a product engineer, I should know end to end of my product. Its my job as a products engineer. Coding the business logic to deploying it till the end (reaching to the end user and adding business value). Moreover in a fast moving environment, it makes more logic to do the same. Assume a company where a software engineer writes code and other deploys it. The other person has to know about the in and outs of the code before deploying. And lets say any bug comes, the communication overhead between the 2 teams is massive. The ticket generally just floats in the middle dropping the productivity and business value massively.

Making the Code System Agnostic

We all had our Java Game Of Life project which we made in Core Engineering Bootcamp. All were made on OSX. Now we wanted to made the code system Agnostic. Say If I have a windows user, OSX user and Linux user in my team and I want them to run my Game of Life code.

One way is for me write 3 Readme. One for each. And the installation steps for each. But to correctly write them, I need these systems myself. Tough job!

Other way is to fix an OS in the team. Say Linux. Now if we can make everyone access this from any system, our job is done. VM’s to the rescue.

Firstly, What’s _Vagrant_? Vagrant is a tool which help us manage the Virtual Machine. Make a Vagrant file and use the file anywhere to replicate the machine.

  1. Run a VM with image of the decided OS.
  2. Link the folder to the Vagrant. By default, its /Vagrant . So the directory in which VagrantFile is there will be present in the VM.
  3. We now just need to have the build and run instructions for only the specific OS in readme.
  4. Or lets have these build instructions run in the Vagrant file everytime anyone does a Vagrant up. Use a bash shell as provisioner to run the instructions.

So the only instruction in Readme now is Vagrant up and everyone who wants to work has to just spin up the VM with Vagrant up.

Vagrant file for Installing Java10.

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/xenial64"
  config.vm.provision "shell", inline: <<-SHELL
     sudo add-apt-repository ppa:linuxuprising/java
     sudo apt-get update
     sudo apt-get -y install oracle-java10-installer
  SHELL
end

Continuous Integration (CI)

Continuous Integration (CI) is a development practice where developers integrate code into a shared repository frequently, preferably several times a day. Each integration can then be verified by an automated build and automated tests. When an integration breaks, everyone is notified to not push until the pipeline is fixed.

One thing, all the tests and automated build are done only when the code is pushed. And when a build fails, a red build is there and its on the highest priority to fix it first.

Why CI?

Its very easy to work in simple systems than complex systems. If we check for bugs on every small change, we can identify them very easily because the change is less. Simple to debug.This is the key benefit of integrating regularly. We can detect errors quickly and locate them more easily. As each change introduced is typically small, pinpointing the specific change that introduced a defect can be done quickly.

Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove. — Martin Fowler

So the next task for us was to build the CI pipeline. But for that, we should have an application to work on. GOF on Java is not something great for production. So we were given the homework of making a CRUD app on rails with BDD followed as a homework. Hell of a night it was. But in the end I got it working and it was amazing. The next task for us was to build a CI for this CRUD app. Follow next blog for the same.