VCS for your software project

I always wonder how the “Avukana statue of Lord Buddha” was built. Sculpting a gigantic statue without any fissures is amazing and requires extraordinary talent and coordination of effort. I believe many people have contribute to this project by engaging in cracking, shaping, polishing various parts of the rock. Each and every hammering should be perfect. If you put little bit of extra pressure than you need,  entire months work will be wasted and you’ll have to find a another rock and start it all over again.

But when it comes to building software, mistakes are acceptable. Each and every piece of code you check-in is not perfect and it is known. that’s why you need proper software repository to manage the different versions.  Quality of the code is important as the source code control system. Choosing the right software repository is really important in building a sophisticated deployment pipeline. There are wide range of commercial and non commercial software repositories  in use today. We have many many options to choose. But what are the key aspects needs to be looked at before selecting a software repository for your project.

Distributed vs Centralized                                                                                                             Version control systems like Git offers a much different type of version control in that it’s a distributed version control system. With a distributed version control system, there isn’t one centralized code base to pull the code from. Different branches hold different parts of the code. These systems do not necessarily rely on a central server to store all the versions of a project’s files. Instead, every developer “clones” a copy of a repository and has the full history of the project on their own hard drive. This copy (or “clone”) has all of the metadata of the original.                                                                                                                              Other version control systems, such as SVN and CVS, use centralized version control, meaning that only one master copy of the software is used.When you’re working with a centralized verison control system, your workflow for adding a new feature or fixing a bug in your project will usually look something like this:

  • Pull down any changes other people have made from the central server.
  • Make your changes, and make sure they work properly.
  • Commit your changes to the central server, so other programmers can see them.                                                                                                                                                                  Important Terms      
  • Repository                                                                                                                                                 The collection of files that make up your project (with or without version control) plus the database maintained by your VCS
  • Working Directory                                                                                                                                     Without version control your working directory is your project folder (and any sub-folders). With distributed version control it’s the same only you have the ability to update your working directory to whatever version of your code you want to work on very quickly and very easily.
  • Change set                                                                                                                                                   All of the changes that represent the difference between a commit and the prior commit (two versions of your project). Say you make some changes to one of the files in a project and then commit that change, the change set is the difference between the commit you just made and the prior one, i.e. the changes you made to that one file.
  • Branch & Tip                                                                                                          Blank Flowchart - New Page                 A  branch essentially takes a single version of your code and creates two copies of it. You can then change those two copies independently of each other, changes to one do not affect the other.
  • Change Set                                                                                                                                                All of the changes that represent the difference between a commit and the prior commit (two versions of your project). Say you make some changes to one of the files in a project and then commit that change, the change set is the difference between the commit you just made and the prior one, i.e. the changes you made to that one file.
  • Merge                                                                                                                                Blank Flowchart - New Page                                                Most of the source control systems, you can branch your code, so different teams work on it separately. Each team can have its own branch of the code to work on independently.  For example above diagram depicts two branches and two merges.

    Merging occurs when you want to bring the work back together. Since the work has been done independently on different branches, some code files (and other changes) may have occurred in some of the same files. A merge conflict may occur as it might not be clear how to put together a file from different branches correctly – this normally requires manual intervention and is what most coders refer to when talking about “merge hell”.                                                                                                                             Few VCS to look at before choosing a VCS

  • GitHub
  • CVS
  • SVN
  • Mercurial 

Journey of DevOps

Druid Getafix’s magic potion transforms skinny Astrix into a superhuman within seconds. But is it enough to fight against powerful Romans? The simple answer is “No!”.  Most importantly Astrix has a brilliant brain on top of his shoulders to come up with new ways of attacking and defending.

Same as in IT industry, throwing money into IT service delivery process was not able to solve the problems we had. In fact, it made some of the problems worse.

What are the common challenges  in IT service delivery? Inability to produce high quality and timely software, nail biting production incidents, failures in meeting ever-changing customer requirements and unsuccessful releases are only a few of them.

Agile was the first step

Over time IT has evolved into a necessity from a luxury. So the need of demolishing these challenges has become number one priority.

Agile is a great answer for most of the IT service delivery challenges.  Agile methodologies like rapid delivery of working software, co-location, simplicity, self organizing teams, Test driven development  are used in almost all of the successful modern organizations. Yet we couldn’t achieve the quality which we were expecting. Some of the underlying core challenges were still existing and pulling the hair out of CIOs, CEOs. Business was not totally happy.

Why we couldn’t demolish some of the challenges with “Agile” itself? Which is something that needs to be carefully analyzed.

“IT service delivery” or more accurately “IT as a service” is comprised of  four phases. Namely design, development, Release and operation/maintenance. Agile was an only solution for development and part of design and maintenance phases. But we didn’t have a solution for challenges in other phases. Although Related, But in a different context, Agile was a great solution for Dev and QA. But operations left out and they had their own problems and solutions.

Fear of change and responsibility dilemma  

Operation people like App, Network, DBA engineers were not ready to continuously change the code in production environments or to introduce new features, Because they were feared of inevitable truth which they believed in. I.e. “All the releases will break the production”

On the other hand, with agile dev teams were kept creating small replaceable meaningful chunks of code and throwing them over the “ Berlin Wall of Dev and Ops”. But it was not a synchronized effort. Dev ownership was scoped and limited to creating code only. They were not responsible for neither how code is running and serving customers in production environment nor the production stability after they threw the code over the wall.

When there is a production incident, Dev was not keen on getting their hands dirty and jump in as it was someone else’s responsibility. They had lots of things in their backlog, which they tend to focus on.

On the other hand Operations teams were never engaged in the design and development phases of the products. Operations feedback was not sent to the design phase to improve the code and ops never involved in non functional requirement development. Agile teams were kept missing non functional requirements like instrumentation, monitoring, fault tolerance mechanisms, vendor interoperability, security… Etc.. As a result of that, technical debt increased over time. What happens when technical debt is increasing? It creates the vicious cycle of production instability.

Infrastructure Readiness

Meanwhile, infrastructure was not ready to support agile software development. Rigid infrastructure  technologies and lack of human resources made this problem more and more challenging. For an example, let’s consider a new server provisioning request for a feature. When the requirement was picked up from the backlog scrum team starts working on building the new feature. But since there isn’t an Ops representation in the scrum team nobody is concerned about the time taken to provision servers,set up monitoring,setup network and other non functional requirements for the feature. When a scrum team is nearing the finish line they tend to worry about and start thinking about those NFRs. But rigid technologies and manual procedures don’t allow ops teams to create servers on the fly or setup network easily. Then the conflict begins.  This is just a small example from practical world. Dev was ready to take the “IT as a service Challenges” with agile. But Ops was moving in a different way.

Emerging new culture

Because of such incidents, demand for collaborative culture between dev and ops was increasing and DevOps starting to create a paradigm shift in IT industry. DevOps is neither a tool nor a person. It is the modern IT culture and an outgrowth of agile which addresses the challenges in all phases of “IT as a service” when combined with agile/XP practices.

With DevOps and agile culture dev and Ops together responsible for the entire flow of  IT service delivery.  Transformation and adoption process of DevOps culture should be carefully planned and should happen gradually.

In the initial stages, it’s important to create the synchronization between dev and ops.  Ops should start involving in early stages of product creation. Ops give their feedback in design stages and involve in non functional requirement development as well. Ideally Application engineers and DBAs should be part of the scrum team and their contribution should be calculated as part of the velocity of the team. Application engineer or site reliability engineer’s role is vital to DevOps culture. Some organizations tend to hire people for a role called DevOps engineer. My personal belief is DevOps is culture and not a role. Even Though they were specifically hired as DevOps engineers, DevOps is a culture which spans across all the employee’s in the organization.

Key Enablers of DevOps

Automation is a key driving factor in DevOps adoption. Automation enables  rapid, seamless deployment of software. Modern “IT as service” providers are having multiple releases per day through  appropriate automation. Some organizations release 30 to 50 times a day to the production environment.  Automation leads us to continuous integration, continuous delivery and then to continuous deployment. The final goal of all automation is the continuous operation. In an ideal DevOps world, feature team should be able to automatically push the code upto production environment without any manual intervention and downtimes.

As mentioned earlier rigid infrastructure is the biggest bottleneck of the Continuous operation. As a solution to that, PaaS (Platform as a Service) and IaaS (Infrastructure as a Service) concepts gained the popularity and infrastructure provisioning has reached to a new dimension due to that. With the appropriate automation and cloud computing technologies, infrastructure provisioning has become seamless. Especially with the use of the A/B deployment mechanism, modern operation teams are equipped for DevOps transformation.

Sharing is very important in a true DevOps culture. Coding the software is merely a one activity in provisioning “IT as a service”. There is a lot more into it. Everyone understands the big picture is important in developing the DevOps culture.  Also Everyone as a unit should be responsible for the entire flow of work while engaged in one or more actions to complete the flow. Developers getting alerts and reacting  in the middle of the nights and operations involving in non functional development activities is a healthy example of sharing responsibilities. Most importantly What we need to understand is “DevOps is a culture which has its own set of values. If these values are not understood by everyone in the organization, DevOps can drive you to an endless maze.