In the past 10 there has been a drive in software engineering to use agile methods such as:
Agile in general allows for the whole process of software development to be more reflective, allowing the development of adapt to the ever changing needs of clients, customers and anything else which the world may throw at the development team. Each of the methods mentioned have different characteristics; scrum is characterized by standing meetings, and XP has very fast release cycles through development cycles at different stages.
Traditional software development has operated independently of the IT/Systems admins teams within companies, thus the application would be developed independently of the systems which it would untimely run up on, or it would be developed for a specifically designed system which would change once in a blue moon. This forms of regimented development can see through the flow of the code once it has been signed of by the developers before it does into production.
This could then mean that once quality assurance has been pass for the changes and it has then been passed onto the system team it could then be changed again to allow for it to be deployed on existing systems.
A juxtaposition can be see through the motivations of system administrators and developers.
- Deliver change in accordance to requirements
- Business depends of delivering change
- Maintain Stability
- Fight off change
- Reduce Downtime
- Change is the Enemy
- Increase reliability
Both act in isolation within their own domains within the company, focusing on their own goals with their own specific tool sets to achieve them. When issues arise the blame and fixes are moved between Developers, System Admin, and Quality Assurance teams, with no one knowing what to do all believing it is someone else.
This leads to risky deployment where people don’t have belief in the code whether or not it will run on live environments as people only believe it would work on the machines which it has been developed on, fearing change once the code has been deployed. It also slowed down the release cycles as even though developers may be working to short release cycles in Agile; the system admins would rather release code into production in larger iterations rather than smaller ones, as it means that they have a greater time to test it on systems, and requires less work.
Within System Admins domain their have been many innovations that have allowed for modernisation. Virtualization and Cloud Computing (Infrastructure and Platform as a service such as aws.amazon.com) have been embraced thought the industry, this allows for provisioning of areas of the system for development on the same system as deployment, isolate applications from each other, allows faster provisioning of resources, and reduces hardware tie in for data centres. This form of innovation was allowed through addition of layer of abstraction between code and hardware, allowing hardware problems to now become a software problem.
This in turn has influences the formation of DevOps (Developer Operations) which has seen an increase in popularity side about 2008. The basic concept behind DevOps is to being the Developers closer to the System Admin roles, and vies versa. Some large companies use this method and have increased there relies cycles to 10 to 20 per day, as demonstrated by Flikr.
DevOps is the theory / opinion / movement that by bring the development of code closer to the development of the info-structure you can remove and improve some of the problems previously mentioned. It has to be understood that DepOps is not just a person in the company which bring people together, or a set of processes for problem solving, it is an overall belief and philosophy for developing, deploying, testing, maintaining, using, and implementing code. It is the belief that there is limited too no difference between the System Admin (System Admin Teams) and Software Developers (Software Development Teams). This is breaking down the barriers between teams and departments allowing developers to understand what they are developing on and the system admins deploying environments that developers need. This means developers should be able to move from one language to another, from objects in java to functions on cron jobs. This is trying to limit the distance between development completions to live in production.
Even though it is not a person, some people embody it more than others, enabling DevOps for other people. For a person to embody the DevOps philosophy they need to have a multi discipline skill set, willing to write code, and set up deployment environments. As they sit within multiple campuses they are the ones that make the connections between people, facilitating communication, peace making situations, and being good will ambassadors. This allows for cross discipline teams to come together and work as one entity.
Currently tooling amongst the teams is different, but by unifying the tools allows for a greater understanding the different roles. This can be done through:
- Unified process
- Unified tooling
- Version Controlled Software Libraries and code
- Deeply Modelled Systems
- Automation of manual tasks e.g. increased use of cron jobs
- Cloud Computing
- Iaas (Infrastructure as a Service)
- Paas (Platform as a Service)
This in essence means that developers who blame the System Admins for creating an unreliable environment and the System Admins for blaming the developers for creating unreliable code become mute as they become intertwined, and the ultimate issue of maintenance and quality control become interweaved into a true agilely method.