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.
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”
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.
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