DEV Community: Pankaj Sharma

Continuous Deployments Foster DevOps Culture

Pankaj Sharma — Mon, 10 Aug 2020 02:44:42 +0000

DevOps culture is talk of the town now a days. Organizations are pushing their management and employees for faster adoption. The trend is noticeably similar to that of Agile adoption. Sadly, what started as a movement to improve the culture, seems to be heavily misunderstood, much like Agile was, and is being adopted and implemented in a way that would make zero difference. I have this feeling in the guts, that says very soon "DevOps is dead" will be trending.

As part of the adoption, most organizations now have a DevOps team. Many of them, to support the movement, have renamed operations to DevOps. These newly formed (rather renamed) DevOps teams are still not ready to let go the control over the release process. Likewise, the developers are neither ready nor being prepared for the added responsibilities that comes with the adoption of DevOps culture.

Organizations are adopting DevOps culture primarily to improve their rate of delivery. In my humble opinion, DevOps culture itself is not a cause but an effect. An effect itself cannot bring any improvement, rather its presence is a sign of improvement. So if DevOps culture if an effect then what is the cause ? Continous Delivery / Continuous Deployment is the cause. Organizations that adopt CD will only be the ones with true DevOps culture.

Organizations should focus on CD rather than the DevOps hype, to improve their speed of delivery. CD at its core is about improving developer productivity and for a successful CD implementation developers first should to be empowered and then made accountable for the entire release process.

Ad-hoc Polymorphism In Elixir Using defprotocol

Pankaj Sharma — Sun, 09 Aug 2020 05:58:48 +0000

This is a follow up on my previous post on Ad-hoc Polymorphism. I highly recommend reading the previous post first. In this post we will refactor the same code to use defprotocol construct. At the end of this post you will notice that using defprotocol results in better encapsulation and fewer lines of code.

defprotocol is a means to achieving ad-hoc polymorphism. Ad-hoc polymorphism in simple terms is a technique of varying behaviour based on their types. Complex states can be modeled in Elixir using the defstruct construct. States defined using defstruct can be used as types for achieving ad-hoc polymorphism.

Lets use defprotocol to define a protocol (aka behavior) that we want to vary based on structs.

  defprotocol ConnectionHandler do
    def handle(con)
  end

defimpl let's us implement different behaviors for protocols defined using the defprotocol construct, as shown below.

  defmodule ConnectionHandler.FirstConnectionHandler do
    defstruct con: nil

    defimpl ConnectionHandler, for: ConnectionHandler.FirstConnectionHandler  do
      def handle(%ConnectionHandler.FirstConnectionHandler{con: con}) do
        "First"
      end
    end
  end

  defmodule ConnectionHandler.SecondConnectionHandler do
    defstruct con: nil

    defimpl ConnectionHandler, for: ConnectionHandler.SecondConnectionHandler  do
      def handle(%ConnectionHandler.SecondConnectionHandler{con: con}) do
        "Second"
      end
    end
  end

Below shown test demonstrates how everything glues together. If you have read the previous post, you might notice that no change has been made to the test.

  defmodule Blaze.Test do
  use ExUnit.Case

  defprotocol ConnectionHandler do
    def handle(con)
  end

  defmodule ConnectionHandler.FirstConnectionHandler do
    defstruct con: nil

    defimpl ConnectionHandler, for: ConnectionHandler.FirstConnectionHandler  do
      def handle(%ConnectionHandler.FirstConnectionHandler{con: con}) do
        "First"
      end
    end
  end

  defmodule ConnectionHandler.SecondConnectionHandler do
    defstruct con: nil

    defimpl ConnectionHandler, for: ConnectionHandler.SecondConnectionHandler  do
      def handle(%ConnectionHandler.SecondConnectionHandler{con: con}) do
        "Second"
      end
    end
  end

  test "demonstration of `defprotocol`" do
    alias ConnectionHandler.FirstConnectionHandler
    alias ConnectionHandler.SecondConnectionHandler

    assert ConnectionHandler.handle(%FirstConnectionHandler{con: []}) == "First"
    assert ConnectionHandler.handle(%SecondConnectionHandler{con: []}) == "Second"
  end
end

This post demonstrates that in Elixir using defprotocol for adhoc-polymorphism leads to fewer lines of code and better encapsulation.

Ad-hoc Polymorphism in Elixir

Pankaj Sharma — Sat, 08 Aug 2020 16:37:25 +0000

Ad-hoc polymorphism is a kind of polymorphism that uses types and polymorphic functions (aka function overloading) to change the function behavior depending on the types of its arguments.

While behaviour and defprotocol are preferred options for achieving polymorphism in Elixir, there is also one more option, probably more simplistic. Ad-hoc polymorphism can be achieved in Elixir using a combination of plain structs, function overloading, pattern matching and destructuring.

First step is to wrap the state, that needs polymorphic behavior in a struct, as shown below.

  defmodule ConnectionHandler.FirstConnectionHandler do
    defstruct con: nil
  end

  defmodule ConnectionHandler.SecondConnectionHandler do
    defstruct con: nil
  end

Then create a module which will house the overloaded functions, that would pattern match over the structs that we just created.

  defmodule ConnectionHandler do
    alias ConnectionHandler.FirstConnectionHandler
    alias ConnectionHandler.SecondConnectionHandler

    def handle(%FirstConnectionHandler{con: con}) do
      "First"
    end

    def handle(%SecondConnectionHandler{con: con}) do
      "Second"
    end
  end

Below shown simple test case demonstrates how it all glues together.

defmodule ConnectionHandler.Test do
  use ExUnit.Case

  defmodule ConnectionHandler.FirstConnectionHandler do
    defstruct con: nil
  end

  defmodule ConnectionHandler.SecondConnectionHandler do
    defstruct con: nil
  end

  defmodule ConnectionHandler do
    alias ConnectionHandler.FirstConnectionHandler
    alias ConnectionHandler.SecondConnectionHandler

    def handle(%FirstConnectionHandler{con: con}) do
      "First"
    end

    def handle(%SecondConnectionHandler{con: con}) do
      "Second"
    end
  end

  test "ad-hoc polymorphism demonstration" do
    alias ConnectionHandler.FirstConnectionHandler
    alias ConnectionHandler.SecondConnectionHandler

    assert ConnectionHandler.handle(%FirstConnectionHandler{con: []}) == "First"
    assert ConnectionHandler.handle(%SecondConnectionHandler{con: []}) == "Second"
  end
end

While this is a way of achieving polymorphism in Elixir, one might want to consider more idiomatic approach of using defprotocol.

Update: Part 2 of this series demonstrates how using defprotocol retults in better encapsulation and fewer lines of code.

In a nutshell: Race Conditions

Pankaj Sharma — Mon, 20 Jul 2020 03:02:35 +0000

Race condition is a term commonly used in scenarios where outcome is non-deterministic, as the outcome depends on the order in which relevant events occur. For example, in a concurrent program with non-synchronized threads trying to write to console, the order of console writes is non-deterministic. In short, it is a term used to represent an non-deterministic outcome.

Data Races are a type of race condition that arise when non-synchronized threads try to access and mutate a memory location.

In a nutshell: Monads and Functors

Pankaj Sharma — Fri, 17 Jul 2020 11:22:21 +0000

Functors

Any object that provides a method with following signature is a functor

map :: (a -> b) -> m a -> m b

m is a container, map opens up the container and converts type a to b.

Monads

Any object that provides a method with following signature is a monad

(flatMap) :: m a -> (a -> m b) -> m b

m is a container, flatMap opens up the container converts a to mb and if in the process multiple mb's are created then it flattens them to return a single mb.

Deployment pipeline for a platform with collaborating bounded contexts

Pankaj Sharma — Thu, 16 Jul 2020 04:44:53 +0000

Deployment Pipeline Best Practices Summarized

Pankaj Sharma — Wed, 15 Jul 2020 03:28:38 +0000

Deployment pipeline as defined in the Continuous Delivery, is a process of converting commits into certified releasable artifact.

As a developer, who loves types, I would rephrase the definition for conciseness as

DeploymentPipeline :: List<Commit> -> Try<ReleaseableArtifact>

While working as a consultant, when it comes to deployment pipelines, I have seen same mistakes being repeated across teams. So it is worth reiterating the deployment pipelines guidelines as mentioned in the Continuous Delivery.

Build your binaries only once
Binaries should not be environment specific
Deploy same way to every environment
Smoke test your deployments
Deploy into copy of production
Each change should propagate through the pipeline instantly
If any part of the pipeline fails stop the pipeline

I highly recommend Continuous Delivery book that further elaborates on each of these points.

Team practices for successful CI

Pankaj Sharma — Fri, 10 Jul 2020 18:24:14 +0000

Goal of a successful continuous integration implementation is to prove that software will remain in working state even after the new increment in merged.

Following practices will help teams get the most out of their CI implementation:

check-in regularly, at least once a day
don't check-in on a broken build
run tests locally before committing
never go home on a broken build
be prepared to revert a previous version
time-box fixing before reverting
fail build for slow tests
fail build for warnings
fail build for formatting issues
fail build for violation of code quality metrics

References: