The Jumpstart UpA Practical Handbook For Leading Agile & DevOpsTransformation

Aymen El Amri / eon01

This book is for sale at http://leanpub.com/the-jumpstart-up

This version was published on 2016-06-13

This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishingprocess. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools andmany iterations to get reader feedback, pivot until you have the right book and build traction onceyou do.

© 2015 - 2016 Aymen El Amri / eon01

Tweet This Book!Please help Aymen El Amri / eon01 by spreading the word about this book on Twitter!

The suggested tweet for this book is:

Just bought The Jumpstart Up: Leading #Startup #Agile & #DevOps Transformation

The suggested hashtag for this book is #TheJumpstartUp.

Find out what other people are saying about the book by clicking on this link to search for thishashtag on Twitter:

https://twitter.com/search?q=#TheJumpstartUp

Also By Aymen El Amri / eon01Saltstack For DevOps

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1To Whom This Book Is Addressed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Conventions used in this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2How to Properly Read And Benefit From This Book . . . . . . . . . . . . . . . . . . . . . 2How To Contribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2About The Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

The Need For The Digital Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Once Upon A Time .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4From CTO to CTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

A Practical Introduction To DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6What Is DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

DevOps Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6DevOps Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6DevOps Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7DevOps Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8DevOps Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

The 15-point DevOps Check List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10A Cross-Functional Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Communication Culture & Global Thinking . . . . . . . . . . . . . . . . . . . . . . . 11Customer-Oriented Culture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Source Control & Revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Infrastructure As Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Routine Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Self-Service Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Automated Builds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Continuous Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Continuous Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Incremental Testing & Test-Driven Development . . . . . . . . . . . . . . . . . . . . . 16Automated release management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Shorter Development Cycles & Time-To-Market . . . . . . . . . . . . . . . . . . . . . 16Key Performance Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

CONTENTS

The DevOps Feedback Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Systems Thinking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Amplifying Feedback Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Culture Of Continual Experimentation And Learning . . . . . . . . . . . . . . 19

Preface1 \ ^__^

2 \ (oo)\_______

3 (__)\ )\/\

4 ||----w |

5 || ||

Assumptions

The digital world is alive and dynamic, it will not stop making global transformations. Todaycompanies and startups have to follow a challenging technical pace to achieve good results, toconvince potential customers, keep current customers and overcome competitors. Competition istough, two similar products or services can lead to two different outcomes. One may fail while theother can have a huge success.

In a world of rapid change, the antonym of innovation is disappearance.When developing your ideasto softwares, “how innovative is my product” is not more important than “how I am developing it”,“how efficient is my development process” or “how my software factory should be built” ..

According to a study developers and engineers need at least 60 minutes a week to make technologywatch in order to keep some credibility in the job market. Today the IT community is busy with allof the information flow, the new technologies and all of these methodologies, philosophies and tools- coming most of the time with blurring definitions: Agile, DevOps, ITIL, Lean, Cloud, Containers,Micro Services, QA, Continuous Integration and Deployment and more words are added every dayto our jargon.

To Whom This Book Is Addressed

According to many studies, almost 90 % - sometimes more - of startups fails withins 3 years forseveral reasons and many of them are related to technical and procedural reasons in developingand producing softwares. This book is an impressionistic, experience-based essay giving practicaland technical point of views to understand and master the process of modern DevOps and agilitytransformations.

If you are a leader of a digital transformation in your company and you want to see further and havemore perspectives, if you start developing your startup softwares and you want to set up an efficientdevelopment and operations process to handle your growth, if you don’t have a solid technicalbackground but you are the founder of a startup/project and you still want to give yourself a taste of

1

Preface 2

the technical transformation, if you would like to modernize you infrastructure, your developmentand operation procedures this book is for you.

The digital world is changing its formula, this book tries to introduce and standardize a formula forchange.

Conventions used in this book

I am trying to be as simple as possible, you can find the following two icons through the book. Notrethat

• Technical terms will have an italic police.

• - To highlight useful and important information

• - Or to to highlight a warning or to prevent

How to Properly Read And Benefit From This Book

Chapters in this book are independent from each others so you are not obliged to follow a particularorder. However, you can find some technical words that you don’t have an instantaneous definitionto and you may find more details about it in other chapters.

It is recommended to navigate sometimes between chapters and sections, pause reading one chapterto start another and get back to the first one when definitions are clearer. You can also readsequentially the book and take notes about the things you don’t understand while reading : Atthe beginning try to make a diagonal reading while focusing on the basic concepts, then try to findsimple definitions of what you have taken as notes.

If you don’t have a good technical backgroud, you may find some difficulties in understanding someparts, even if your global understanding will not be really affected but some online research to finddefinition is recommanded.

How To Contribute

This work is always in progress. I am an adopter of the lean philosophy so the book will becontinuously improved in function of many criteria, but the most important one is your feedback.

Preface 3

If you have any suggestions please contact me, you can find me on Twitter¹ or you can use my blogcontact page².

If you want a better tracking of issues and recommendations about this book, I recommend usingthis github repository³.

This book is not perfect, so you can find typo, punctuation errors or missing words.

About The Author

Aymen El Amri is a DevOps/architect engineer, actually working as the head of IT systemsand DevOps in a Parisian startup where he is leading the DevOps and Agile transformation.He worked on development (python,php..etc), operations and system engineering (Linux) forcompanies and startups. He is interested in the DevOps philosophy, the lean programming andthe tools/methodologies that comes with since his last experiences in this domains were successful.

He co-founded some projects in connection with the community of Free and Open Source Software,an infrastructure provider and hewas involved in hackerspaces and other political/social movementsin relation with Open and Free technology.

Find him on Twitter @eon01⁴ or follow his blog⁵.

¹https://twitter.com/eon01²http://eon01.com/blog/contact-me/³⁴https://twitter.com/eon01⁵http://eon01.com/blog

The Need For The DigitalTransformation

1 \ ^__^

2 \ (oo)\_______

3 (__)\ )\/\

4 ||----w |

5 || ||

Once Upon A Time ..

Once upon a time before the actual accelerating technological change, IT processes were long,expensive and somehow boring. Engineers could spent more than a year just to study and plan.Development releases were not as frequent as today and product deliveries cycles were slow.

Today when working in IT, it’s completely different, you may find yourself buried by a huge massof new terms. When making your usual technology watch, you have surely seen hundreds of newtechnical terminologies, methodologies and technologies.

In spite of the fact that the effect of digitization is not new, the computerized economy is enteringanother age that shows exceptional difficulties for all CEOs.

The definition of “digitizing” has changed with the increasing popularity lean philosophy, we speakabout process improvements to better use time and resources.

In the era of “innovate or die”, businesses are like being attacked permanently by advancedinstruments inciting continuous critical changes in the way they work, inter-communicate andproduce.

This has offered ascend to new open doors and challenges, and has set off the Digital Transformationof endeavors.

From CTO to CTO

Transformation is a whole scale change to expand the compass of organizations, enhance choices,and speed the development of products and the implementation of new features without loosingquality. While the transformation is digital it has an impact on all levels but it still first and foremosta business transformation.With the increasing number of new technologies, the path may vary from

4

The Need For The Digital Transformation 5

an organization to another but let’s be clear that human not technologies are the most importantelement in every process.

One of the most important goals of the actual digital chagne is unlocking productivity gains, that’swhy technology enabled business transformation is one on the most important trends nowadays.The world is becoming a cloud of connected services and outsourced management. Succesfullentrepreneurs learnt that they should focus on one product because time is precious, they adoptedbusiness and development methodologies known for their success, they are more focusing on corevalue while sprinting their planning.

Technologies, methodologies and enterprise cultures like DevOps, Cloud Computing, Lean Startupand Agility are not arbitrarily born but they are the results of several transformations in businessmodels and an evolution of the manner of thinkings.

IT organizations have commons problems like :

• The technical debt• The conflict between development and operations teams• Long product development cycles• IT systems instability• Helpdesk problems

But the real problem is not using the best solutions in the best time, because as you can see, most ofIT organizations have encountred those problems, this is why having a wide view onmethodologies,technologies and the new uprising entreprise cultures is important.

We’re not saying that every trending subject should be blindly followed but having enoughknowledge about what things are would help you take its advantages and avoid its drawbacks that’swhy your CTO (chief technical officer) should be or should cooperate with another CTO (chieftransformation officer).

A Practical Introduction To DevOps1 \ ^__^

2 \ (oo)\_______

3 (__)\ )\/\

4 ||----w |

5 || ||

What Is DevOps

DevOps means a lot of things. People talks about it from many different point of views, differentorganization sizes and different approaches. IT engineers could consider it as techniques to simplifydevelopment and operations, managers could look at this as a culture to increase productivity andrecruiters could call it a job.

I am not considering any of those definitions alone but I prefer having a global view on the culture,the business and the technological aspects of DevOps.

May be the best way to define DevOps to use parallel understandings levels of how things are build.Consider DevOps as a philosophy that comes with values, principles, methods, practices and tools.

DevOps Values

As you know, when developing softwares business needs developers. To deploy their code and runit in a production environment, developers need operations team. The fact that those teams workswith different manners has created a waterfall. DevOps urge the dev & ops collaboration. DevOps isthe reaction to the absence or the poorness of the communication between the different stakeholders:“people over process”. DevOps create transparency and visibility between dev & ops while settingup a continuous improvement and feedback.

DevOps Principles

DevOps is about creating a culture that adopts some lean principles like continuous experimentation,continuous learning and continuous improvement. In DevOps philosophy everything is a chain:Improvements are the result of learning and learning is a the result of experimentation.

DevOps is about the continuity of processes creating a loop-back (feedback from ops to dev). Inorganizations where DevOps is deep-rooted, ops teams consider infrastructure as code and wouldconsider setting up automation plus an infrastructure self service for developers.

Those principles would not be possible to adoptwithout some advanced technologies and tool chains.

6

A Practical Introduction To DevOps 7

DevOps Methods

DevOps is a reaction to the waterfall of traditional IT, like Agile is to the traditional developmentprocesses. DevOps followed Agile: it is the agility applied to systems, operations and infrastructure.Furthermore the term “agile operations” is sometimes used instead of DevOps, thus giving anotherdefinition for DevOps intending to connect Agile development teams to deployments and highlight-ing the value of fast and recurring delivery.

However Agile development environment are not required to have a DevOps team or to adopt aDevOps culture: You can do DevOps without without doing Agile.

In general there are two technical teams in an organization: development teams and system admin-istrators/operations teams. Both teams works differently, have different visions on informationssystems and different priorities, developers would not have a real problems to switch to Agile(Scrum, XP ..etc) but it could be very complicated to system administrators and operation teams. Inreality the latter team is not onlyworking on deployments, they havemany other focal areas: storage,networking, architecture, incidents and production problems. They usually works on stressfulenvironments where every detail is important and they adopts a work model based or similar toon build/run iterations with flexible schedule due to the importance of prioritizing in their work.

Sysadmin Build/Run

Kanban⁶ is one of most known methodologies, and apart from being one of the most compatiblemethodologies for operations and sysadmin teams, may be the majority of sysadmin, if asked,will choose Kanban among all the other methodologies, but some other teams adopted differentmethodologies and others found that a mix of two methodologies is a good fit (scrumban =scrum+kanban, lean Kanban ..etc).

This diversity of choices depends on several factors like the understanding of DevOps, whether it isconsidered as a role/team or not.

⁶https://en.wikipedia.org/wiki/Kanban

A Practical Introduction To DevOps 8

In all cases, don’t forget that developers and operations teams works differently and that adoptinga methodology is not evident, it should grow your own organization and come from operationteams to embrace the agility on the development side while keeping a focus on the stability of yourinfrastructure and your production software factory.

Some definitions are not detailed in this part but this book will detail them in the next chapters.

DevOps Practices

DevOps practices are the utilized procedures to execute the above ideas. Setting up a DevOps cultureneeds giving more time and effort to observations in order to find the best solutions and then act.DevOps is a process of continuous learning and improvements powered by measurements that canbe done during an iteration. As one of the most important things in setting up a DevOps cultureis communication between dev and ops teams, feedback from ops to dev (and vice versa) is animportant practice. We will focus more on this in the “DevOps Feedback Loop” section, but thefollowing schema shows how an iteration with an infinite loop from code to operations to feedbacksshould be done.

Infinite DevOps Loop

Despite the different definitions that organizations can give to “DevOps”, Eric Ries’s definition thathe gave to the Lean Startup or the Running Lean, applies largely to DevOps practices.

Lean methodology is based on the creation of learning cycles to validate ideas and then learningagain by collecting customers feedback and son on.

DevOps Culture incorporate the same principles: A cycle based on learning and ideas, development,validation (QA), operations (integration, deployment), and finally retrieving technical metrics of thesame developed software running on production environments in order to provide feedback to thedevelopment teams. Those valuable feedback will helpful for developers in order to ameliorate theirproducts and fit them to business and information system needs.

The DevOps practices are not based on technical tools, though the technical part is not to beunderestimated, the main goal is not the technical choices but improving time-to-market andadapting technical development challenges to the business.

With new technologies such as the cloud computing, scalability and the infrastructure on demand(dynamic infrastructure), often ops teams have fewer problems in relation with operating system,networking and infrastructure incidents which reduces some burden on developers and gives the

A Practical Introduction To DevOps 9

equivalent of a self-service infrastructure which gives them more time to focus on the product orthe service of the organization and to collaborate more with dev teams.

While the new emerging technologies and the evolution of software development changes the focusof ops teams, also this gives the dev teams more visibility on how their products are running atlarger scale and helps them focus on ameliorating the development process.

DevOps Tools

Let me say it again: DevOps is a culture, a philosophy .. but the rise of DevOps and the emergenceof its culture was accompanied by a considerable number of tools. Some of them are old tools thathave been modernized and many others are recent or very recent.

Most of the the tools used in DevOps environments similar to what a sysadmin and ops teams usebut with more focus on automation and collaboration between dev and ops.

DevOps teams use both developers and system engineers softwares and this is a list of the type oftools they use. Two examples are provided for each type.

• Operating Systems (Ubuntu, Debian)• Application Servers (Websphere, Tomcat)• Web Servers (Apache, Nginx)• Process Supervisors (Supervisor, God)• Logging and Log Management (Logstash, Papertrail)• Monitoring, Alerting, and Trending (Nagios, Cacti)• Metric Collection (Collectd, Collectl)• Cloud Computing (Amazon Web Services, Google Cloud Computing)• Cloud Storage (Amazon Simple Storage Service, OwnCloud)• Configuration Management & Network Configuration Management (SaltStack, Ansible)• Containers (Docker, CoreOs)• Virtualization (Xen, VmWare)• VPN Tools (OpenVPN, PPTP)• Continuous Integration & Continuous Deployment (Jenkins, Travis-ci)• Backups (Amanda, Bacula)• Code Review (Gerrit, Review Board)• RDBMS (Mysql, PostgreSql)• NoSQL (MongoDb, RethinkDB)• Packaging (fpm, Packman)• Test & Build (Ant, Maven)• Queuing & Caching (RabbitMQ, Squid)• Security (Fail2Ban, DenyHosts)• Service Discovery (Consul, ZooKeeper)

A Practical Introduction To DevOps 10

• Collaborative Software & Wikis (DockuWiki, Confluence)• Ticketing systems (BugZilla, Jira)• Web Statistics (Google Analytics, Piwik)• Troubleshooting (Sysdig, Mitmproxy)• Version control (Github, Bitbucket)

The 15-point DevOps Check List

DevOps is a culture that requires some practices and a new vision, its common goal is unifyingpeople and organizations around unique goals.

The DevOps Checklist is neither static nor unique, there is no manifesto that describes DevOps,but it should be adapted to the organization need, human interactions and other specific criteria.In other words, the checklist could help you proceed with setting up a DevOps culture but don’tconsider it as a unique way to proceed with your organization transformation.

You are not obliged to fully implement all of these points, but just start with what you can do andwhat you should do and work on their improvement continually.

These points are cultural, process-related or technical. In all cases, something I had never or rarelyfound in other checklists which is reliability not just your live environments but also processes andthe first thing reliability requires is the simplicity. Simplicity is not an element in the followingchecklist because it must demonstrate in each of these points, so keep thing simple.

The central enemy of reliability is complexity. ∼ Geer et al.

Simplicity is prerequisite for reliability. ∼ Edsger W. Dijkstra

A Cross-Functional Team

A cross-functional team is a group of people with different functional expertise (marketing,operations, development, QA, account managers ..etc) working for the same goals and projects.

A group of individuals of various backgrounds and expertises are assembled to collaborate in bettermanners and solve problems faster.

As said in Wikipedia: The growth of self-directed cross-functional teams has influenced decision-making processes and organizational structures. Although management theory likes to propoundthat every type of organizational structure needs to make strategic, tactical, and operationaldecisions, new procedures have started to emerge that work best with teams.

In DevOps context, the dev and ops teams should not live in separate silos. Each team should providesupport and advices in order to take advantage of the skills of everyone.

According to some management studies, like Peter Drucker’s on management by objectives, cross-functional teams are less goal dominated and less unidirectional which stimulates the productivityand the capability of dealing with fuzzy logic.

A Practical Introduction To DevOps 11

Communication Culture & Global Thinking

When working together on the same products, communication is bound in achieve better resultsand reach valued goals. DevOps is mainly a culture of communication and cross-functionalcollaboration. Individuals and departments could speak in different professional languages, whichcreates different types of communication types, like it is the case between developers and operationteams. Every team has its own goals, operation engineers seek stability, while developers tend tomake changes that may affect the stability in some cases. This is not just the case for developers andoperation engineers, every department in a non-DevOps environment has its own goals and givealmost 100% of the effort and the time to achieve it.

Obviously with different goals, different responsibilities and different professional languages, com-munication becomes difficult. From that point departments will throw responsibilities of problemsthat they either create or encounter.

Being rigid in setting goals for each department is not a good idea in many cases. Having commongoals, goals shared between departments and make managers, executives and all members of a teamaware about the fact that there are common goals can reduce this gap between two or more teams.

Setting up departmental and local goals brings up the “not-my-job” problem where each departmentthrow responsibilities on another one, while establishing common and global goals encourage peopleto work together.

The following hacks could help your organization to ameliorate communication:

• Motivate through Gamification: Gamification is a good way to keep your team motivatedwhile playing.

In my work we are using Hipchat and I integrated several chat bots but the one that I like the most isthe Karma bot: every one in my team instead of saying “Thank you”, can give one or several karmapoints to another colleague.

This is somehow a kind of building a symbolic “meritocracy”. The GNOME Foundation, ApacheSoftware Foundation, Mozilla Foundation, and The Document Foundation are examples of (opensource) organizations that officially claim to be meritocracies. You can find other tools that couldhelp in the gamification of work spaces and the daily professional life like Game Effective⁷ to gamifysales, customer service and employee training.

• The Smiley Board: At the end of each work day, everyone is required to draw a picture oftheir face in one of three modes:

– Happy face– Blah face– Sad face

⁷http://www.gameffective.com/

A Practical Introduction To DevOps 12

The Smiley Board is also called the Niko-niko Calendar (or Smiley Calendar). It is a Japanese creationwhere each member shall put a smiley on his own schedule at the end of the day, before leaving theoffice. This gives a view about the well-being and motivation of each member of the project.

• Playing Games: Game playing is a goodway to create a good communication behavior. A goodexample is the Kanban simulation game⁸ simulates variable work flow for a SaaS companyThe getKanban Board Game is a physical game designed to teach the concepts and mechanicsof Kanban for software development in a class or workshop setting.

• Hackathons: A hackathon, hackfest, codefest or hackday is an event in which individualsinvolved in software or hardware development, design, UX, project management, collaborateintensively on software/hardware projects. Hackathons tend to have a specific focus on atechnology, a theme or a project but some hackathons are open and participants have the fullfreedom. Hackathons are a great way to build communications and allow people from thesame organization to work together and have the same goal. Internal Hackathons are also away that some companies like Netflix, Facebook, Google, Microsoft, Hewlett Packard organizeto promote new product innovation by the engineering staff. For example, Facebook’s Likebutton was conceived during a hackathon.

• Open & shared spaces

Open spaces done right are a key to valuable communications and collaboration.

• Chat Rooms: Internal chat applications are widely used in many organizations, generally chatrooms are specific to a team or a project. Adding chatbots in tools like Hipchat, Slack orany of their alternatives, helps teams to communicate on several recurring events and beingtransparent about:

– Deployments– Incidents– Builds– Developers commit to the enterprise git repository

In my company I have even set up bots to post daily motivational quotes, we have also some chatrooms where we talk about non-work related stuff.

• Team building: Or helping a team to make it more efficient in terms of operability, morecohesive, consistent in its results and competent. This type of accompaniment is particularlyrelevant when the professional situation is internally complex during a process of reorganiza-tion or profound change in the business, or when the situation is externally complex duringa competitive pressure or a changing market. It helps the team to co-build the solution anddevelop their collective intelligence and autonomy.

• Outlets, group outing, Friday drinks, team building

⁸http://getkanban.com/

A Practical Introduction To DevOps 13

Customer-Oriented Culture

Product-centric culture will not work in most cases, especially if you are a startup with an MVP oreven more and trying to be competitive in the market. No one know how a product should be betterthan the customer himself.

To build a customer-oriented culture:- You should not build the best product but create the best solution for your customer. - Stopworryingabout creating new products or features and instead of that search for your customers’ new needsto fill. - Hire people who fit and reward people having deep insights into customers instead ofrewarding new features or product development. - Share your customers needs explicitly with yourdevelopers and operation engineers. Being transparent about business needs and customers needsis the first step to create a customer-oriented culture.

Actually, being focused on customers is the best way to align teams towards the same valuable goalswithout creating an inter-department war. The DevOps feedback loop is also a good way to keepyour systems stable and scalable in the same time, customers need this: stability and scalability.

Source Control & Revisions

According to Wikipedia: A component of software configuration management, version control, alsoknown as revision control or source control, is the management of changes to documents, computerprograms, large web sites, and other collections of information.

Source control can be critical to your success.

When developing a digital product, it is important to give developers a technical tool equivalent toproject management tools but from a pure technical view. Source control was created to resolve realproblems that developers encountered during the coding process. It allows them to :

• Keep the code modification history, so that change management and getting back to olderversions of a working code could be easier.

• Concurrent file editing, in the case when multiple developers works on the same code.• Tagging• Branching• Merging

Version control is not just for developers since one of the best practices in startups is versioningdocumentations. Documentation versioning will help you:

• Track incremental backups and recover• Record any change and revert a documentation to an earlier version• Track co-authoring and collaboration and individual contributions

Most of the modern documentation softwares use versioning like Atlassian Confluence or otheropen source softwares like wiki softwares (MediaWiki, DocuWiki ..etc).

A Practical Introduction To DevOps 14

Infrastructure As Code

Infrastructuremanagement and provisioning is moving to the next big thing: Infrastructure As Code.

Infrastructure as Code (IaC) is the usage of definition and configuration files to create, start, stop,delete, terminate and restart virtual or bare-metal machines. When mastering IaC organizationscan reduce costs and time of infrastructure management in order to focus more on the productdevelopment.

With the rise of DevOps movement the fact of enabling the Continuous Configuration Automationapproach is becoming a key step in the life cycle of a product.

I published a post on medium⁹ where I explain how Infrastructure As Code can work using aconfiguration management tool.

Routine Automation

The DevOps philosophy could be described in different manners, but I saw once on Twitter¹⁰ agood point of view about defining DevOps from an automation perspective: “Using Things You CanProgram, and Programing the Things You Use”.

Automation in the DevOps philosophy is about making faster tasks in order to interface things andcreate automated pipelines. Almost everthing could be done manually, but in order to focus onproduct development and to create a continuous pipelines (continuous integration, delivery, testing,deployment ..etc) and feedback loops, everything starts with automation:

• Automate infrastructure• Automate integration• Automate delivery• Automate feedbacks• Automate scalability• Automate bugs hunting• ..etc

The continuous processes relies on already automated tasks.

Self-Service Configuration

Using cloud technologies with configuration management software allows automated provisioningof infrastructure and services. Generally the operation engineers after listening to developers needfor product development, install and configure software on production-like servers. Using tools like

⁹https://medium.com/@eon01/automating-aws-infrastructure-using-saltstack-2b40aeadc7a9¹⁰https://twitter.com/U_tad/status/517603911570829312

A Practical Introduction To DevOps 15

Chef, Puppet, Ansible or SaltStack, cloud infrastructure like AWS and Digital Ocean, versioningsystems like Github or Bitbucket, containers technologies like Docker, continuous integration anddeployment servers like Jenkins or Rundeck.

• You system configuration should be always into a source control service/servers• Developers should be able to create systems with production-like configurations and data.• Developers should have access to continuous integration tasks to build softwares and testartifacts in a short period: I prefer working with git hooks, where an automatic build islaunched right when a developer push a change to development branch.

• In a stage of maturity, Developers could be able to deploy a change to production: This canbe complex to achieve, in some cases it is preferred to keep operation engineers deploy toproduction.

Automated Builds

With the increasing number of Jenkins plugin, automating builds is becoming easier. An exampleFor web applications is using automated build tools like Ant with package managers like npm anddependencies managers like php composer.

The main types of automated builds are:

• On-demand automated builds where the user run a script to launch the build if it is needed:This is not really fully automated and it is used in the cases where scheduled and triggeredbuilds are complex or useless.

• Scheduled automated builds like it is the case with the continuous integration servers (suchas Jenkins) running nightly builds

• Triggered automated builds where builds in a continuous integration server are launched justafter commit to a git repository.

Continuous Integration

Continuous integration use automated build to create a process where the integration server builda project if any changes were made or periodically. The process could also include automated testsand automated delivery.

Continuous Delivery

Continuous delivery is a use both the continuous integration and automated builds to deliversoftware to other teams as fast as possible, ideally after a code change. The product is then deliveredin an artifact server or at least a FTP server. As an example, QA teams cloud access to the lastdelivery to do their tests. If the transition from the test phase to the production deployment phaseis automatic, we call this continuous deployment. The big difference between continuous is theautomated deployment.

A Practical Introduction To DevOps 16

Incremental Testing & Test-Driven Development

Testing relies on the concepts of integration testing and incremental testing relies on the continuousintegration and delivery.

Incremental testing is continuous and repetitive as new and fresh functionality is added.

The incremental approach has the advantage of detecting fresh defect. Because finding bugs in anearly stage will help your organization spend less money and stabilize production environments,incremental testing is one the best practices in DevOps.

Different testing approaches could be adopted:

• Top down: Testing takes place from top to bottom, following the control flow. Example:starting from the GUI to the program core.

• Bottom up: Testing takes place from the bottom to top following . Example: starting from thesystem components to the GUI.

• Functional incremental: Testing functions and functionalities like described in the functionalspecification.

Test-driven development is one of the concepts of the extreme programming( a software develop-ment methodology which is intended to improve software quality and responsiveness and one ofthe agile software development practices). TDD is one of the best practices to adopt in a DevOpsculture, it is based on incremental testing and the repetition of a very short development cycle. KentBeck, who is credited with having developed or rediscovered the technique, stated in 2003 that TDDencourages simple designs and inspires confidence.

Test-driven development is a test-first concept that developers can apply in order to improve anddebug their code or even legacy code developed with older techniques and methodologies.

Automated release management

Product development is not just code. The product has a whole life cycle, from development,version control, builds, repositories and artifact delivery, tests and acceptance, server provisioning,application configuration to production deployment. This cycle describes the release management,while automation is one of the pillars of the DevOps culture, the release management should beautomated for better business results. The automation of release management relies on automatingall of its stages, that is why automating releases require setting up a continuous delivery strategy.

Shorter Development Cycles & Time-To-Market

The motivation of being customer-oriented organization while using the techniques mentionedabove will induce development cycle length and in a result the time-to-market.

A Practical Introduction To DevOps 17

Time-to-market (TTM) is the length of time it takes from the conception stage to the product beingdeployed and running in production servers. TTM is important in all industries where products areoutmoded quickly as it happens in organization working onweb applications, SaaS or PaaS products.In order to know the existent and improve it, measuring the time-to-market is a good practice, oneof the simplest approaches to measure it is counting days from the conception of a feature to the thedeployment of the stable release containing the feature to the production.

Agile methodologies and DevOps culture advocates working in developments sprint, while routinetasks are automated, integration and tests are continuous, a sprint may take from one to two weeksand so the time-to-market.

Key Performance Indicators

As said, measuring the time-to-market is a good practice. In order to reduce the length of a productTTM, we should measure its actual one and this is similar for other improvements.

Key performance indicators (KP) are the key-indicators of the efficiency, performance and the goodresult. It can be collective or personal and to promote sharing global global goals, departmental KPIsare less important than global KPIs.

A key performance indicator can meet the following objectives:

• evaluation• diagnostic• communication• information• motivation• continuous progress

Indicators are a key-concept in the continuous improvements and it relies on:

• Choosing your indicators, rather choosing the good indicators - well it simply depends onyour organization specificities, priorities and goals.

• Automating measurements: Working on sprints of improvements is one of the best practices.Improvements are not a stage or a list of tasks to achieve after deploying a product, but acontinuous work that require a continuous measurement that could be automated. Havingthe number of errors and bugs happening in your live or in your integration environments isa good example. I always considered having a screen with live KPI measurements in an openspace is genius idea.

A Practical Introduction To DevOps 18

The DevOps Feedback Loop

To achieve an incremental work flow, a constant, feedback loop between operation and softwaredevelopment teams is important. The feedback is the description of the current state of the softwareacross its life cycle.

The feedback loops, is one of the most important DevOps principles, it can describe the DevOps andthe Lean methodology goals: Continuous improvements while having a fail-fast workflow betweendevelopment and IT.

This feedback could be a real time flow in its most advanced forms.

In startups, change is a law so the high deployment rates will often result a supercharge for IToperations. Clyde Logue, founder of StreamStep, said: “Agile was instrumental in developmentregaining the trust in the business, but it unintentionally left IT operations behind. DevOps is away for the business to regain trust in the entire IT organization as a whole.”

“The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win” book describesthe fundamental principles of DevOps, describes “The Three Ways” from which are the principlesthat all of the DevOps patterns can be derived from.

Systems Thinking

System Thinking

System thinking highlights in the first place the performance of the entire system so that no moredepartmental goals will be considered as more important as the global goals. The focus is on allbusiness value streams that are enabled by IT.

A Practical Introduction To DevOps 19

Amplifying Feedback Loops

Amplifying Feedback Loops

This way is about creating a feedback loop in order to achieve improvements while amplifyingthe loops and this helps understanding customers needs and responding to all the the internal needs(both developers and system administrators ..etc). Amplifying the feedback loop is a way to increasethe global degradation caused by local changes. Some local changes are just optimizations intendedto achieve an individual or a local goal and putting the amplified feedback in work will never passa defect to downstream work centers.

Culture Of Continual Experimentation And Learning

Culture Of Continual Experimentation And Learning

This way is about continuous experimentation, taking risks and continuous learning. The repetitionin this way is the prerequisite to mastery and the experimentation is a path towards improvementswhich is daily work. Feedback could be done in a shorter time.