The journey your code change goes on from idea to benefiting the end user depends on a lot of things which are technology dependent like investment in automation and application tech stack but also business dependent like organisational structure and risk profile. Technologists around the world point to their deployment pipelines to allay any fears their business stakeholders may have about risks when changing the software. The thing is, just having an automated pipeline does not guarantee full confidence in releasing changes to your software in large part because not enough teams are looking at the implementation and architecture of their pipeline.
This talk will look at the complexities that arise from different software architectures. Do you have a monolith? Or maybe your application is a monolith deployment but actually is spread across multiple repositories? How does being an independently deployable service architecture impact your delivery pipeline? For all the job titles, working groups, and decision making that goes into software architecture, this talk will explore the implications and support system required for your deployment pipeline to balance the contextual needs, pros and cons of different choices, and good practices in the wider industry.
Three main takeaways will be:
- Examples of how to apply the same architectural awareness and evolution of software to delivery pipelines
- Commonly used patterns to build confidence in software which interacts with other systems like 3rd party application and custom libraries
- How to incorporate clean code methodologies and practices to the creation of delivery pipelines