Dev Ops Overview
Development operations (Dev Ops) is on the human level the
unification of software development engineers and software operations, bridging
the gap in-between where when developers hand over their solution they work
tightly with operations to understand the output.
Traditionally software engineers would hand it over to
operations to as they prepared to implement and they would configure the files
and other data ready for deployment sometimes causing confusion.
Dev Ops is a something between a philosophy and methodology,
that uses multidisciplinary teams to work tightly and efficiently together, using
a number of characteristics, prominently the automation and monitoring at all
stages off software construction, integration, testing, release to deployment
and management infrastructure. Dev ops also employs an agile software
development principle in order to reduce development cycles, increasing
deployment frequency allowing rapid iterations to quick release (Radawan, 2016).
The dev ops workflow or pipeline is a set of practices and
specialised tools to complete a project from the first idea until the finished
product is released, being closely monitored along the way then allowing feed
back to tailor the project to customer and consumer needs.
Dev ops is flexible, there is no certain structure to the
way it is integrated into the business, the semantics and ontology of the
stages may differ slightly in a specific business environment as will the
stages/toolchain, this leaves room to introduce different tools if the tools
that are being used are not making the right impact.
Dev ops involves tools, automation and teams but fundamentally
it is to produce better products as quickly as possible using communication,
understanding of different processes, integration and relationships.
Stages of Dev Ops
The initial stage of planning will involve business
management/owners, IT personnel, software developers/architects, release
management staff, project management, security personnel and IT infrastructure management
collaborating to bring together seamless integration. Planning will
Ideas, production line, toolsets and feedback
Strategies, meetings (agile lean/scrum)
Release plan timing
Security measures, policies and requirements
Some of the tools available for this are altassian, jira,
hipchat, confluence, irise (Altassian, 2018).
The build looks at the coding, software development design
and configuration. The build process is possibly the busiest and covers several
iterations, continuous integration, deployment and delivery working with
infrastructure as code.
Continuous deployment (CD) works in sync with continuous
integration and refers to the application being deployable at any stage or
possibly deploying automatically if passing automated testing. If the commit
passes a several steps and meets the correct criteria the it will be released,
if this does not meet any of the requirements with in the automated quality
testing then the process is aborted and will fall back to the developers for
intervention (Agile Alliance, 2018).
Continuous delivery works of the back of deployment ensuring
that the commit passes the automated testing the necessary configuration has to
be ready to push out to production. Continuous delivery involves the process
from production to eventual release with the process of build, test, configure
and deploy (Codeship, 2018).
CD tools (Jenkins, Bamboo, AWS Codedepoy)
Infrastructure as Code (IaC)
IaC works in conjunction with (continuous delivery and
manages connection topology, networks and load balancers. The physical
equipment used includes bare metal servers and virtual machines (techtarget,
2017; Gucenheimer, 2017).
IaC resembles and can be treated as a software system, the
code can be kept in source control which can be reused to reproduce builds and
also this can be audited, as long as it passes testing practices and the cycle
of continuous delivery. This is dynamic infrastructure that enables software
commands to create and provision servers which previously taken a much longer
time using physical hardware that would be configured to the needs of the
application and then deployed to the hardware this was also expensive (fowler,
IaC uses different approaches and methods, it can ether be
imperative (procedural) which has parameters with explicit steps or declarative
(functional) which is result focused and end state is described and the tool
will attempt to reach it. The methods that can be used are push where control
is centralised and changes are pushed out typically for production and pull
which is highly scalable, which is more suitable for developers and clients
contact the central servers for updates (arquino, 2016)
(Img 1 Review of
tools, methods & approaches (techdata, 2018))
Some IaC and middleware tools are ansible tower, chef,
Diagram 1 flow and components
of Infrastructure as Code.
The verification and testing overlaps with other categories.
This category ensures the quality assurance of the code is sustained so the
best quality product is deployed in unification which the actual release. This
part of the process checks acceptance, regression and configuration testing.
This automated testing speeds up development and testing cycles, this also
gives greater awareness and visibility throughout the whole process to quicker
release (altassian, 2017)
Tools available bamboo, IBM, HP
Continuous integration (CI) is a practice that allows
developers to commit changes to the shared depository several times a day. Each
integration into the master which can be known as the main or trunk is verified
by automated build and testing. This is beneficial as if an error is found,
each change that has been made to the repository is small making it much easier
to identify and fix (Thoughtworks, 2018).
some tools available for (CI) include (docker, TravisCI,
the packaging stage is when the pieces come together and the
product is ready for deployment, this process looks at the approvals for
release, configuration of the package, release times and staging. This stage
will use an artefact repository tool to store the binary files in a centralised
Packaging tools: nexus repository, sonatype, Jfrogs
Release activities include the scheduling to release times,
coordination, provisioning and deployment of product. This is normally managed
through an application release automation tool which combines automation,
workflow and environment modelling, the application release tool accomplishes
the implementation of continuous delivery quickly releasing the product
Release tools: automic, hipchat, XebiaLabs, VMware
The configuration category falls into the operation side,
after the deployment there will be added infrastructure & application
provisioning and configuration for storage, database and networking,
Infrastructure as code overlaps into the category.
Some tools used are: ansible, salt, chef, puppet.
Monitoring is done more or less at every stage of the dev
ops process, this covers the identification of specific issues, release dates,
times and performance, the experience and response from the user, the analysis
and statistics, activity monitoring, logging, vulnerabilities and deployments
Monitoring tools big panda, wireshark, new relic
Continuous feedback can be achieved in many ways service
desk software, bug reports, support tickets and even social media through
twitter and Facebook this is crucial to any business as it directs the team to
tweak the product in the right direction in terms release planning and testing.
Good feedback particularly through social media will promote your
Probably the most important area to look at is security, Secure Assist automatically detects
vulnerabilities and provides just in time guidance to fix them, this option is
open source and may have to work together with another security tool as it only
fixes the most common of security issues. Gautlit
is an automated security tool that has a variety of functions, it facilitates
testing and communication between groups and can be hooked in to the deploy
process. Vault covers securing
tokens, API keys, passwords and certificates and other sensitive resources and
handles leasing, auditing etc. this is the best what I would recommend for
scrummy software although it is at a charge, however I think when it comes to
security it is best to pay for a service that has higher security levels
(Vault, 2018: Synopsis, 2018).
Diagram 2 the complete
dev ops toolchain and processes
All of the processes throughout the toolchain are linked
very close together overlapping into each due to the many of them being a continuous
or ongoing job, the above diagram looks at the entire process and continual
workflow of a development operation, each silo overlaps into one another and is
continuous throughout (larger diagram is
Diagram 3 Dev ops
Toolchain infrastructure using the 7 C’s
The above diagram looks at the 7 C’s which are Continuous
planning, development, integration, deployment, testing, delivery and
monitoring, feedback. This is the workflow within a company using devops.
Img 2 Dev ops periodic
table (XebiaLabs, 2018)
The xebia labs website provides some excellent information
and uses a periodic table to show each of the tools within each category.
Img 3 Dev ops
toolchain and pipeline visualizer (XebiaLabs, 2018)
The pipeline visualizer enables you to see a diagram of your
full toolset in silos from start to finish. The XebiaLabs website also provides
a complete dev ops tool chest.
The tools that are used in a dev ops environment come down
to a few things price, it is possible to run your toolset entirely for free as
most tools can be open source and can be downloaded at no cost. The tools used
can be at preference to the user some may have to have training to operate them
which may always be a positive if they can configure better to other tools and
The most stressful part can be the release of the product
pulling together change, test and deployment information into one place. A
single integrated release dashboard that can keep everything in one place would
be more sufficient such as Jira software
SaaS, PaaS, IaaS
(Img 4 Cloud serices key
differences (BMC, 2017)
Software as a Service (SaaS)
SaaS is also known as the
cloud application service, most commonly applications are web based and will
run on your device web browser this means that no downloads, installations or
upgrades are required by the client. Saas is managed by a third-party vendor through
the internet, they also take care of technical problems such as data,
middleware, storage and servers.
Saas requires minimal planning
and is easy to access and set up it is also very stable and supported by the
large infrastructure and IT team. Reduces costs as there is no need for
technical staff to manage, install or upgrade software. Businesses can scale up
or down depending on seasonal demand Saas does have some downfalls depending on
the business, the client has absolutely no control over the system processing,
software deployment, testing and upgrades, the provider has full access to
client data and integration with other software is difficult or non-compatible,
it may not be bespoke enough for the specific business sectors as It is
normally paid for through subscription as a complete package (BMC, 2018).
Platform as a Service (Paas)
Paas functions at a lower level than Saas, Paas provides a
platform framework for developers to build customize and deploy applications.
Servers storage and networking is managed by the third-party vendor therefore
developers are able to focus on managing their applications. The Paas model is
similar to that of Saas the difference being that a platform is provided to use
the software on to create applications at the same time they do not have to
worry about storage, infrastructure and software updates.
Paas is built on virtualization technology, which allows
businesses to scale up or down if there is changes within the business, this
could be beneficial to scrummy software depending on their business needs
Infrastructure as a Service (Iaas)
Iaas is a self-service model, allowing customers to pay on demand.
Iaas users access their resources through an API/Dashboard where they have
access to there servers and storage this can be purchased as a fully outsourced
service and paid according to the amount of resources consumed, although users
are responsible for managing more of the components: applications, runtime,
middleware and O/S they have the advantage that they can install and required
platform that is niche to there business on top of the infrastructure, however
unlike Saas users are responsible for updating software when new versions are
released and upgrades are required (under ctrl, 2018; BMC, 2018).
Finding the right fit
Depending on the CEO of scrummy software’s finances and what he wants
to spend will be a major factor in which cloud service they opt for, also
taking into consideration the staff that work there if they are capable of
managing the different services. If they are to opt for SaaS then the price
will be the cheaper of the 3, everything is managed by the third-party vendor this
is a positive in that most of the services are managed and they can concentrate
solely on the product, also the software is fully provisioned so they can have
rapid deployment on demand and software is stable as due large cloud
infrastructure and IT team. However, security can be an issue as they have
access to all data, this is ok depending what data is being stored. There are
no control parameters, deployment, testing or upgrades a lot of which is contrary
to which a dev ops continuous pipeline works (Stratoscale, 2018).
If the scrummy software had a dedicated security expert then PaaS
or IaaS might be the way to go, this will come depend on the size of the
business if they are a small to medium sized business then they will likely opt
for SaaS as this covers security unless they can use an outsourced security
Using PaaS you can use your own software to run on the platform
unlike SaaS, also full control over users accessing software and improved
support of integration on the other hand there is no control over the platform,
upgrades and updates are managed by internal staff and again security can be
limited as there is no control over VM processing
IaaS is the most flexible of the cloud computing models and being
that they are a software company it would suggest that they have the skilled
staff to deal with most of the components that IaaS has to manage. They would
have full control over there VM’s and everything within it, integration is
simper due to business infrastructure, although the most expensive of the three
the payoff is that it can run its on virtual infrastructure without cost of
I believe that IaaS would be the best cloud model to opt for as
scrummy software are looking for a full devops approach, if they wish to
relinquish some of the responsibility then PaaS would also be an adequate
option this depends on the market they are serving and if they and how much
control the cloud provider has over the platform.
Tools: Microsoft Azure
provides services for both Paas and Iaas it also supports many programming
languages, tools and frameworks including third-part vendor software. This
would be a good solution for scrummy software as it is highly compatible and
scalable. It does cost depending on what you choose in your bundle
(azure.microsoft.com, 2018). Amazon web services
could be an alternative to this and may be slightly cheaper as it is charged on
a freemium and provides almost the same services as Azure. Open stack is a free and open source IaaS solution and would suit
if finances where tight but does not offer the same capabilities and services
as the bugger companies.
Reliance on automation
Automated systems are not always the best for carrying out
test, of course they can learn and be tweaked to perform better, also they can
Assuming and then depending on Scrummy software’s CAPEX
capital expenditure and OPEX operating expenditure will be which route they
take into DevOps, then take in to consideration the staff they have on board and
there skillsets as a software company I would expect the have any experts and
therefore would be using Iaas as they will be able to manage most of the
technical jobs themselves
Although there are many processes to a Dev Ops toolchain
depending on the business needs there is no standard, so