• Coding

  • code version control and "cloud coding "

Hello

@Rahmu and others as well..

Revising the topic from a change of habit perspective, as apps have evolved from single binaries to mvc and later ascended to script type code that run on various platforms and services, how do you perceive that work habbits in regards to version control have changed when working with agile methodology?

Different devops have a tendency to establish own codebase, config environment, etc. This leads to distributed and independent operations. Now my question to Rahmu is, as you have been moderating and doing version control. How do you things have changed, habits, methodology, ownership, documentation, etc.

What i am eager to hear about is how do you perceive the changes that "cloud coding" brings change and enables developers. What possible downfalls or challenges have you seen.

Opensource is a good reference base. In the past a developer developed an app from start to end handling everything in between. this approach was cumbersome when it came development and release. Development changed to framework type of solutions where individual components and functionscould be addressed and speed up releases. Then you got the mvc etc. Now the trend is towards coding using available API and platforms. Each stage of change along the way has changed to method of working towards a solution diverting from a centrally orchestrated mode of development to the type of working kn a choreography mode. This alone sets chsnges in the development occurs and is maintained.

It would be great if you could share statistics for example. How function code compatibility within a framework is maintained. Or what type of functional code is getting the most changes from code versioining perspective.

Hoping to hear good good examples and debates on the subject.
BL
@BL, I've been asking myself this question for a while and I have not reach any kind of definitive conclusion.

I don't think devs are impacted
As far as "Version Control in dev teams" go, I don't think that the Cloud brings anything new. Or maybe am I missing something? As far as I'm concerned, the biggest game changer in that aspect was git (and distributed version control, in general) going mainstream a few years ago. This was a profound model shift away from ClearCase/Perforce and the likes (and even subversion and cvs-like repos).

However, I believe non-dev teams are getting profoundly transformed. Whether it's QA, testing, deployment or production management, a lot of new techniques are being developed (under the umbrella term of DevOps) and they're all centered around version control.

Configuration as code
One of the most interesting practice I've seen around is "Configuration as code". Sure, this was probably a good practice before the Cloud ever existed, but if you couple extreme flexibility in your infrastructure along with "replayability" of your deployment, you can now test continuously and deploy continuously, with great confidence that:
  • Your changes are tested. These changes can be about the code, the configuration, the underlying infrastructure, or whatever.
  • The changes can be easily reverted if anything goes wrong
  • Your data is unaffected by these modifications
In the past, all of this (code version, app configuration, OS configuration, network configuration, ...) used to be managed as a check-list in the hands of production operators. Now it's becoming a script in your version control repo. It enhances replayability and diminishes greatly the risk of human error.

Immutable deployments
Another idea I find vastly fascinating is Immutable Deployments. This one is vaguely inspired by the concepts of Functional Programming which are very interesting. Fowler's blog post does a great job at explaining what he means by this term, so I'll just briefly summarize the notion:

As a server (or any architectural element) spends time in production, it amasses crap. The probability of "hacks" or "temporary fixes" creeping in your production is proportional to the uptime (and the existence time) of your unit. Any reasonably large production system is full of these crappy and undocumented changes. And if you think yours doesn't, go spend one evening with the on-call ops team (and be prepared for a shocking surprise). Patching the code here, modifying /etc/hosts there, a quick firewall rule modif to let traffic pass, ... it's everywhere, it's undocumented and there's not much you can do about it.

The idea of immutable deployment says that you never modify the state of a server. If there's any modif to be made, destroy the server and replace it with a new one with a new state.

If you couple this with the devops techniques described in earlier paragraphs, you can make sure that everything is going to be versioned, traced and documented.

Tools
Cloud computing allows you to deploy in a flexible manner. "Flexible" can also mean "scriptable", that's why we have IaaS APIs. Most IaaS also provide some tool based on declarative DSLs to describe the infra of your deployment, like AWS Cloudformation or OpenStack Heat. These tools will let you describe your system like: how many machines, hostnames, IPs, number of disks, routers, etc.

These scripts can (and should) be version controlled and replayed in your CI/CD system as often as you want.

Configuration management has also been widely covered. Tools like Chef, Puppet, Ansible, Salt and so many more exist to configure your app, your db, your Rabbit/Zero/WhateverMQ, your cache, your key-value stores, etc etc. This is also in your version control and in your CI/CD.

Summary
In short, I don't think that developers will see major changes (in terms of how they organize themselves, and how they deal with version control) but ops definitely will.

Note that application developers will need to understand the cloud, since the apps of the future are able to smartly manage their infrastructure. High Availability will become the responsibility of each application, and we'll come to expect them to be able to scale, diagnose and repair automatically. But that's a topic for another day...
10 days later