DevOps & DevEx
1 like362 views
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.
DevOps & DevEx
- 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.
- 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