DevEx aims to improve the developer experience by focusing on tooling, technologies, and documentation within a DevOps environment. This includes adopting integrated toolchains that streamline the development lifecycle through automation and by ensuring tools are well-tested, configurable, and have comprehensive documentation. The goal of DevEx is to create an optimal software production environment by minimizing friction between development, testing, and operations teams through collaboration, shared tools, and improved processes.

1. DevOps & DevEx
Accelerating software delivery through efficient collaboration,
automated deployment and organisational responsiveness
Twitter: https://twitter.com/SubiyaCryolite
GitHub: https://github.com/SubiyaCryolite
Medium: https://medium.com/@ifungandana

2. About Me
 Ifunga Ndana, a Senior Software Engineer with Broadreach Healthcare
 Broadreach works together with the Ministry of Health in collaboration
with the Centres for Disease Control and Prevention to support
Zambia's national Electronic Health Record system SmartCare.
 Outside of work I've developed a 2D Video Game, an ORM in Kotlin and
worked on several interesting projects on Upwork. Also ranked 1st for
Java and Kotlin in Zambia (GitAwards.com)
 Overall I've been developing software for just over 6 years
 I can be found via the handle SubiyaCryolite on Twitter & GitHub
 Obligatory “views are my own and don’t represent those of my
employer”

3. Lets start from the very beginning

4. Context matters
 We cant truly appreciate DevEx without understanding
DevOps
 We cant truly appreciate DevOps without understanding
Agile Development
 We cant truly appreciate Agile development without
understanding Modern Software Development in general

5. Modern Software Development
 Development Teams can be spread across regions, continents and
time-zones
 Developers do not work in isolation. There are dedicated teams which
handle
 Testing / Quality Assurance
 Deployment / Support
 These teams form a cycle of dependency
 Teams need to be in sync and work efficiently !!!
 Toes should not be stepped on !!!
 Concise and timely communication is key !!!

6. Agile software development
“Agile software development is an approach
to software development under which
requirements and solutions evolve through
the collaborative effort of self-organizing
and cross-functional teams and their end
user.” – Wikipedia, a citeable source

7. Being Agile through Continuous
Integration
“Continuous Integration is the practice of integrating code
into a shared repository and building/testing each change
automatically, as early as possible - usually several times a
day.” - Thoughtworks
 Continuous Integration emphasizes automation tools that
drive build and test, ultimately focusing on achieving a
software-defined life cycle. When CI is successful, build
and integration effort drops, and integration errors are
detected as quickly as practical.

8. Being Agile through Continuous
Integration
Continuous Integration has several advantages:
 It allows teams to detect errors as quickly as possible
 Allows developers to fix issues while fresh in their mind
 Reduces integration problems
 Smaller conflicts & problems are easier to digest
 Problems don’t compound over time
 Allows teams to develop faster, with more confidence

9. Being Agile through Continuous Delivery
“Software is built, configured, and packaged and its
deployment orchestrated in such a way that it can be
released to production in a software-defined manner (low
cost, high automation) at any time.” - Synopsis
 Continuous Delivery/Deployment adds that the software
can be released to production at any time, often by
automatically pushing changes to a staging system.

10. Being Agile through Continuous Delivery
Continuous Delivery provides the following advantages
 Ensures that every change to the system is releasable*
 Lowers risk of each release - makes releases “boring”
 Delivers value more frequently
 Get fast feedback on what users care about

11. CI/CD enable Agile Development
"High-functioning CI/CD practices directly facilitate agility
because software change reaches production more
frequently, providing more opportunities for customers to
experience and provide feedback on change." – Synopsis
In recent times Continuous Automation and Continuous
Delivery have been adopted by many organisations as they
enable quick turnaround times for both development and
release cycles. This is Agile in practice.

12. OK so we’re Agile now, everything's
perfect right?
 Not necessarily
 Remember, Software Developers don’t work in isolation.
 Testing and Deployment/Support Teams need to be part of the equation.
 Successful deployment is not possible without the involvement of these two
functions.
 Historically these functions have been siloed, resulting in barriers which
prevent rapid and effective response to production issues and customer
requests.
 There needs to be a way to seamlessly integrate these functions to fully
leverage the strengths of each without compromising on quality and
turnaround time.

13. Enter DevOps!!!
“DevOps is a set of practices that automates the
processes between software development and IT
teams, in order that they can build, test, and
release software faster and more reliably.
The concept of DevOps is founded on building a
culture of collaboration between teams that
historically functioned in relative siloes.” –
Atlassian

14. DevOps
DevOps emphasizes:
 a shift in mindset;
 better collaboration; and
 tighter integration.
DevOps unites Agile, continuous delivery, automation, and
much more, to help development and operations teams be
more efficient, innovate faster, and deliver higher value to
businesses and customers.

15. DevOps - Lifecycle

16. DevOps - Lifecycle in practice
Assume a small software shop exists with:
 A Development Team consisting of 6 developers in
Livingstone
 A Deployment & Support team primarily concerned with
ensuring production servers are up and running at
optimum capacity in Ndola
 A Product Management team made up of a few testers,
technical writers and Business Analysis functions in Lusaka
 A web-based product hosted on http://whatever.com

17. DevOps - Lifecycle in practice
Furthermore, assume that the development team uses GIT for Source Code
management.
The team has adopted the following branching strategy:
 master branch: Consisting of live code deployed at http://whatever.com
 beta branch: Consisting of live closed beta code hosted at
http://beta.whatever.com
 test branch: Consisting of private code hosted at http://test.whatever.com
 dev branch: Consisting of private code hosted locally on
http://dev.whatever.com
 multiple feature ranches: based on the active sprint and merged into "dev"
via Pull Request. This code would be self-hosted on the developers
workstation.

18. DevOps - Lifecycle in practice
Lastly let us assume this team has adopted Jenkins for their CI/CD pipelines.
Jenkins is the leading open source automation server, and provides hundreds of
plugins to support building, deploying and automating any project. Jenkins can
be hosted locally or on the cloud. Jenkins supports Docker, AWS and many other
popular technologies.
Assume Jenkins has been configured to build and deploy to different domains
based on which branch has had code committed to it. These configurations are
normally defined in “Jenkinsfiles” which execute in a similar manner to bash
scripts. Assume that the teams Git repository is linked to Jenkins via a webhook
plugin such as "Mohami’s Webhook to Jenkins for Bitbucket.

19. DevOps - Lifecycle in practice – Plan
Phase
 Developers gather requirements and feedback
from customers, ideally through the Support and
Test functions
 Work items are added to a general backlog
 Features and Bugs are assigned to iterations or
sprints
 These items are worked on by the developers as
per schedule

20. DevOps - Lifecycle in practice – Code
Phase
 Developers work on items under feature branches in Git
 These feature branches are regularly committed to the
Git SCM server
 The CI server builds the code and runs all defined tests in
the project. Team members are notified of any build or
test errors
 When a feature is complete and passes an internal code
review (Pull Request) it is merged into the “dev” branch,
the feature branch may be deleted

21. DevOps - Lifecycle in practice – Build
Phase
 When code is committed to the Git
repository, Jenkins is alerted via a webhook
 The Jenkins proceeds to perform different
build and deploy functions based on the
affected branch. This is defined in a
Jenkinsfile

22. DevOps - Lifecycle in practice – Build
Phase
 Code committed or merged into the "test branch" is
automatically built, tested & deployed to
http://test.whatever.com where internal testing takes
place.
 Code committed or merged into the "beta branch" is
automatically built, tested & deployed to
http://beta.whatever.com where controlled beta testing
takes place.
 Code committed or merged into the "master branch" is
automatically built, tested & deployed to
http://whatever.com which is the live environment

23. DevOps - Lifecycle in practice – Test
Phase
 At the end of each sprint, code within the "dev" branch is merged into "test"
 This triggers Jenkins which automatically compiles, tests and deploys the
code to http://test.whatever.com
 Internal testers, technical writers and business analysts work with this domain
to test against new and existing functionality
 User Acceptance Tests and controlled pilots may optionally be run from this
domain as well.
 Following these controlled tests, code from the "test" branch could then be
merged into the "beta” branch
 Once again Jenkins kicks in and automatically compiles, tests and deploys the
code to http://beta.whatever.com
 At this point users invited to closed betas can use the most recent version of
the application

24. DevOps - Lifecycle in practice – Release
Phase
 Assuming the closed beta is a success. Code
from the "beta" branch can be merged into
the "master" branch.
 Jenkins is invoked and the code is
automatically compiled, tested and
deployed to http://whatever.com
 All customers are now using the latest
version of the platform.

25. DevOps - Lifecycle in practice – Deploy
Phase
 Jenkins would have automatically deployed the code to
live production servers at the domain
http://whatever.com .
 This deployment is defined within Jenkinsfile's which
behave in a similar fashion to bash scripts. Similar
behaviour can be achieved with different technologies
 There is very little to no human intervention during
deployment

26. DevOps - Lifecycle in practice – Operate
Phase
 The Support team would ensure that the
locally or cloud hosted servers are
functioning at optimal capacity.
 This phase is primarily concerned with
infrastructure configuration and
management e.g. provisioning, scaling etc

27. DevOps - Lifecycle in practice – Monitor
Phase
 On the infrastructure side the support team would
monitor performance and scaling metrics. This
information could then be submitted to developers to
measure any performance regressions introduced in new
code
 The Support and Business Analysis function would interact
with customers to gather feedback and new requests.
 This feedback would be provided to the developers and
would eventually feed into the Planning phase,
completing the cycle

28. DevOps in summary
 Ensures Development, Quality Assurance and
Infrastructure teams work in harmony
 Encourages minimal friction and back & forth across teams
 Encourages collaboration and information sharing
 Encourages automation with the aim of reducing human
error, cost and improving on productivity

29. Cool, so what is DevEx?
 DevEx is short for “Developer Experience”
 As its name implies, DevEx is concerned with
ensuring that Developers have optimal
experiences when functioning in environments
which have adopted DevOps into their
organisation
 DevEx largely focuses on Tooling, Technologies &
Documentation

30. DevEx – Tooling, Technologies &
Documentation
 With DevEx software teams aim to streamline and simplify the
entire software development Lifecyle by adopting powerful,
configurable and seamlessly integrated software tools.
 These toolchains would be used extensively throughout the
development lifecycle.
 These tools and frameworks tend to be well tested and
documented, thus reliable for use in production
 E.g. Jenkins, Maven, Gradle, ESLint, JUnit

31. An Ideal World
DevOps = Agile, CI, CD
DevEx = Integrated and Well Supported Toolchain
DevOps + DevEx = Optimal Software Production
Environment

32. Just the tip of the iceberg
 This talk has barely scratched the surface
 There are many CI/CD and Automation tools on
the market
 There are many ways to structure teams
 At the end of the day, the structure, tools and
practices you adopt must suit your organisation

33. Continuous Integration - TravisCI

34. Continuous Integration - TravisCI

35. Continuous Delivery – Jenkins –
barebones config file

36. Thank You!!!
 Questions?