Getting software released to users can be risky, time-consuming and painful. The solution is the ability to deliver reliable software continuously through build, test and deployment automation, and through improved collaboration between developers, testers and operations. In this tutorial we will present principles and technical practices that enable teams to incrementally deliver software of high quality and value into production whenever they want, and extremely fast. The size of the project or the complexity of its code base does not matter.
In the first half of the tutorial we will introduce the concepts of continuous delivery, through continuous integration; and automation of the build, test and deployment process. We will also go through som basic principles and patterns for building automatable applications (architecture). We will cover experiences on team collaboration patterns and lastly; techniques for solving tasks such as an easy and comprehendible version control strategy.
The second half of the tutorial we will be working with automated provisioning of agile infrastructure, including the use of tools (puppet) to automate the management of testing and production environments. We will go through some scripting lessons examplifying how to implement zero-downtime deploys (… and rollback – if something goes wrong!), with examples in both bash and Ruby. Along with controlling the start, stop, restart lifecycles during deploys, we will also show some simple techniques for backups, logging, error handling, monitoring and verification of application health that can make the automation more robust.
We will also use servers "in the cloud" to demonstrate different techniques, and we hope to make it a fun day and to deliver software (examples) several times throughout the workshop.
Required knowledge: Agile/Lean basics, Linux basics, version control basics, maven basics.
Slides from my talk at CoDeOSL 2015, http://www.code-conf.com/osl15/
Abstract:
------------
We are witnessing perhaps the most disruptive and innovative period in IT in our time. Those not transforming their IT organizations towards DevOps and Continuous Delivery (CD) risk being left behind to die. This talk will place DevOps and CD in a historical context and explain how and why this paradigm shift will radically change how businesses acquire customers and deliver value to them.
DevOps & Security from an Enterprise Toolsmith's Perspectivedev2ops
Slides from presentation by Alex Honor and Damon Edwards at DevOps Connect at RSA 2015 in San Francisco on April 20, 2015.
Abstract:
IT organizations are feeling the squeeze from seemingly conflicting business mandates. At one moment the message is “Go Go Go. DevOps, Lean Startup, Continuous Delivery… move faster and give more people access”. The next moment the message is “Be more secure. Compliance above all. Keep us out of the press!”. Damon Edwards and Alex Honor work with many enterprises who are facing these challenges. This talk is an in the trenches view of how these companies are responding and learning to go faster and be more secure.
DevOps emphasizes communication, collaboration and integration between the developers and the operations folks. Some teams figure out DevOps on their own, but most struggle in their effort to implement DevOps practices, such as, automated builds, automated tests, automated deployments, continuous integration, and continuous delivery.
Many consider these practices essential for the success of any software development project, but they require a new way of thinking. In other words: DevOps requires agility.
DOES15 - Elisabeth Hendrickson - Its All About FeedbackGene Kim
Elisabeth Hendrickson, VP of Engineering, Pivotal’s Big Data Suite
Fifteen years ago I was running a traditional QA department, and I had a horrifying realization: the better I got at my job, the worse I made things for the organization as a whole. This counter-intuitive realization spurred me on a journey to understand the relationship between testing and quality, and ultimately to the study of feedback loops in software development processes. Ultimately I found my way to Extreme Programming, and now work at Pivotal where we practice a particularly opinionated form of it. In this talk you’ll hear about my journey from the traditional silos with inherently long feedback latency to my current reality of increasingly tight feedback loops, and the lessons I’ve learned along the way.
Slides from my talk at CoDeOSL 2015, http://www.code-conf.com/osl15/
Abstract:
------------
We are witnessing perhaps the most disruptive and innovative period in IT in our time. Those not transforming their IT organizations towards DevOps and Continuous Delivery (CD) risk being left behind to die. This talk will place DevOps and CD in a historical context and explain how and why this paradigm shift will radically change how businesses acquire customers and deliver value to them.
DevOps & Security from an Enterprise Toolsmith's Perspectivedev2ops
Slides from presentation by Alex Honor and Damon Edwards at DevOps Connect at RSA 2015 in San Francisco on April 20, 2015.
Abstract:
IT organizations are feeling the squeeze from seemingly conflicting business mandates. At one moment the message is “Go Go Go. DevOps, Lean Startup, Continuous Delivery… move faster and give more people access”. The next moment the message is “Be more secure. Compliance above all. Keep us out of the press!”. Damon Edwards and Alex Honor work with many enterprises who are facing these challenges. This talk is an in the trenches view of how these companies are responding and learning to go faster and be more secure.
DevOps emphasizes communication, collaboration and integration between the developers and the operations folks. Some teams figure out DevOps on their own, but most struggle in their effort to implement DevOps practices, such as, automated builds, automated tests, automated deployments, continuous integration, and continuous delivery.
Many consider these practices essential for the success of any software development project, but they require a new way of thinking. In other words: DevOps requires agility.
DOES15 - Elisabeth Hendrickson - Its All About FeedbackGene Kim
Elisabeth Hendrickson, VP of Engineering, Pivotal’s Big Data Suite
Fifteen years ago I was running a traditional QA department, and I had a horrifying realization: the better I got at my job, the worse I made things for the organization as a whole. This counter-intuitive realization spurred me on a journey to understand the relationship between testing and quality, and ultimately to the study of feedback loops in software development processes. Ultimately I found my way to Extreme Programming, and now work at Pivotal where we practice a particularly opinionated form of it. In this talk you’ll hear about my journey from the traditional silos with inherently long feedback latency to my current reality of increasingly tight feedback loops, and the lessons I’ve learned along the way.
DevOps represents cultural change. Whether it’s the change of resistant engineers that don’t want to be on-call or the change of Operations teams to have more empathy towards their counterparts writing code, to the willingness of executives to embrace a culture of automation, measurement and sharing. Organizations must overcome the culture war to be able to approach the agility and productivity that organizations following a DevOps model gain. The faster they can get there, the faster these organizations can take the competitive edge away from traditional enterprises.
DevOps is mainstream - at least the tools, the automation and the metrics. But what happened to DevOps Culture? Does it still matter? If yes - how do we achieve it?
Putting Devs On-Call: How to Empower Your TeamVictorOps
A main tenet of DevOps is bridging the gap between the Dev team and the Ops team. One way to accomplish this is to include devs in the on-call rotation. While this may sound difficult, it’s not impossible to do…as our guide demonstrates.
We profile four companies that have successfully transitioned their dev team to being on-call and their stories can provide examples for how you too can do it.
DevOps Beyond the Buzzwords: What it Means to Embrace the DevOps LifestyleMark Heckler
Session presented at CodeMash 2016.
DevOps is a hot topic, but it’s a bit ambiguous. What do developers really need to know about DevOps? What is it? What ISN’T it? What difference does it make? We’ll start by examining “DevOps”, what it means to embrace it, and the various personnel involved. We consider the potential benefits associated with a DevOps approach and the risks associated with adopting it…and with not adopting it. We take a quick look at some of the tools and platforms that can be used to implement a productive DevOps environment, including (but not limited to):
* Continuous Integration/Continuous Delivery (CI/CD) software
* Infrastructure Build Automation tools
* Virtualization, Containerization, and Cloud options
Finally, we run a live scenario using several of the tools discussed to demonstrate the key components of a DevOps-committed lifestyle. We start from nothing, using available tooling to build the target platform in a scriptable, repeatable fashion…then demonstrate effective use of CI/CD software for a more streamlined and effective software build/test/deploy cycle…and finally show how containers and cloud services form the foundation upon which everything else is built.
AWS Community Day: From Monolith to Microservices - What Could Go Wrong?Phuong Mai Nguyen
Almost every tech organisation right from start-ups to unimaginably big ones have had monolithic applications in the past and have moved on to nimbler approaches like microservices, making use of powerful cloud technologies. But not every organisation has made this move yet, with most of them still in analysing phase.
If you are part of this or interested in exploring how major players in the industry have managed to convert monoliths to microservices, join us in the talk to get an in-depth knowledge about things that could go wrong and how to make the right choices using AWS services. On top of practical techniques and real-life case studies, we will also be exploring agile methodologies and discuss if microservices are the right choice for your field of work.
(Talk given at Continuous Lifecycle London 2016)
Continuous Delivery techniques and practices are often misunderstood. This session will explore some Continuous Delivery anti-patterns based on work 'in the wild' with a wide range of organisations across different industry sectors:
- Believing that "Continuous Delivery is not for us"
- Ignoring the database
- Thinking that a deployment pipeline is just a series of chained jobs in Jenkins
- Not funding the build/test/deployment capability properly
- No effective logging or application metrics
By avoiding these pitfalls, we can increase the effectiveness of our software delivery efforts.
TechTalk 2021: Peningkatan Performa Software Delivery dengan CI/CDDicodingEvent
CI/CD atau panjangnya Continous Intergation dan Continous Delivery adalah budaya yang biasa diterapkan dalam pengembangan perangkat lunak. Tapi sejatinya masih banyak programmer atau developer yang belum familiar dengan CI/CD. Padahal CI/CD adalah salah satu praktik yang memungkinkan pengembang untuk fokus pada pemenuhan sayarat bisnis, kualitas kode, dan keamanan. Dan pipeline dari CI/CD ini sangat membantu perusahaan yang sering melakukan perubahaan pada aplikasi dengan proses perngiriman yang andal. Hmm.. ternyata banyak benefitnya ya.
Jadi bagaimana ya kira-kira mengimplementasikan CI/CD dengan baik? Hal ini akan kita bahas bersama 2 orang pembicara yang expert dibidangnya, yaitu Rendra Toro (CTO Perintis Teknologi Nusantara) dan Steven Lewi (Principal Engineer Home Credit Indonesia) pada Tech Talk 2021 Live dengan tema "Peningkatan Performa Software Delivery dengan CI/CD."
Why DevOps?
DevOps principles
DevOps concepts
DevOps practices
DevOps people
DevOps controls
DevOps training and further reading
Where do you start with DevOps?
Feedback on the implementation of an architecture allowing to do some Continuous Delivery in both PHP and Java environments for a leading company in the Telecom Industry. We will describe the methods and tools we have implemented as well as the limitations and difficulties we have encountered. Keywords : Industrialization, DevOps, Continuous Delivery, Ansible, Rundeck, Infrastructure As Code
DevOps represents cultural change. Whether it’s the change of resistant engineers that don’t want to be on-call or the change of Operations teams to have more empathy towards their counterparts writing code, to the willingness of executives to embrace a culture of automation, measurement and sharing. Organizations must overcome the culture war to be able to approach the agility and productivity that organizations following a DevOps model gain. The faster they can get there, the faster these organizations can take the competitive edge away from traditional enterprises.
DevOps is mainstream - at least the tools, the automation and the metrics. But what happened to DevOps Culture? Does it still matter? If yes - how do we achieve it?
Putting Devs On-Call: How to Empower Your TeamVictorOps
A main tenet of DevOps is bridging the gap between the Dev team and the Ops team. One way to accomplish this is to include devs in the on-call rotation. While this may sound difficult, it’s not impossible to do…as our guide demonstrates.
We profile four companies that have successfully transitioned their dev team to being on-call and their stories can provide examples for how you too can do it.
DevOps Beyond the Buzzwords: What it Means to Embrace the DevOps LifestyleMark Heckler
Session presented at CodeMash 2016.
DevOps is a hot topic, but it’s a bit ambiguous. What do developers really need to know about DevOps? What is it? What ISN’T it? What difference does it make? We’ll start by examining “DevOps”, what it means to embrace it, and the various personnel involved. We consider the potential benefits associated with a DevOps approach and the risks associated with adopting it…and with not adopting it. We take a quick look at some of the tools and platforms that can be used to implement a productive DevOps environment, including (but not limited to):
* Continuous Integration/Continuous Delivery (CI/CD) software
* Infrastructure Build Automation tools
* Virtualization, Containerization, and Cloud options
Finally, we run a live scenario using several of the tools discussed to demonstrate the key components of a DevOps-committed lifestyle. We start from nothing, using available tooling to build the target platform in a scriptable, repeatable fashion…then demonstrate effective use of CI/CD software for a more streamlined and effective software build/test/deploy cycle…and finally show how containers and cloud services form the foundation upon which everything else is built.
AWS Community Day: From Monolith to Microservices - What Could Go Wrong?Phuong Mai Nguyen
Almost every tech organisation right from start-ups to unimaginably big ones have had monolithic applications in the past and have moved on to nimbler approaches like microservices, making use of powerful cloud technologies. But not every organisation has made this move yet, with most of them still in analysing phase.
If you are part of this or interested in exploring how major players in the industry have managed to convert monoliths to microservices, join us in the talk to get an in-depth knowledge about things that could go wrong and how to make the right choices using AWS services. On top of practical techniques and real-life case studies, we will also be exploring agile methodologies and discuss if microservices are the right choice for your field of work.
(Talk given at Continuous Lifecycle London 2016)
Continuous Delivery techniques and practices are often misunderstood. This session will explore some Continuous Delivery anti-patterns based on work 'in the wild' with a wide range of organisations across different industry sectors:
- Believing that "Continuous Delivery is not for us"
- Ignoring the database
- Thinking that a deployment pipeline is just a series of chained jobs in Jenkins
- Not funding the build/test/deployment capability properly
- No effective logging or application metrics
By avoiding these pitfalls, we can increase the effectiveness of our software delivery efforts.
TechTalk 2021: Peningkatan Performa Software Delivery dengan CI/CDDicodingEvent
CI/CD atau panjangnya Continous Intergation dan Continous Delivery adalah budaya yang biasa diterapkan dalam pengembangan perangkat lunak. Tapi sejatinya masih banyak programmer atau developer yang belum familiar dengan CI/CD. Padahal CI/CD adalah salah satu praktik yang memungkinkan pengembang untuk fokus pada pemenuhan sayarat bisnis, kualitas kode, dan keamanan. Dan pipeline dari CI/CD ini sangat membantu perusahaan yang sering melakukan perubahaan pada aplikasi dengan proses perngiriman yang andal. Hmm.. ternyata banyak benefitnya ya.
Jadi bagaimana ya kira-kira mengimplementasikan CI/CD dengan baik? Hal ini akan kita bahas bersama 2 orang pembicara yang expert dibidangnya, yaitu Rendra Toro (CTO Perintis Teknologi Nusantara) dan Steven Lewi (Principal Engineer Home Credit Indonesia) pada Tech Talk 2021 Live dengan tema "Peningkatan Performa Software Delivery dengan CI/CD."
Why DevOps?
DevOps principles
DevOps concepts
DevOps practices
DevOps people
DevOps controls
DevOps training and further reading
Where do you start with DevOps?
Feedback on the implementation of an architecture allowing to do some Continuous Delivery in both PHP and Java environments for a leading company in the Telecom Industry. We will describe the methods and tools we have implemented as well as the limitations and difficulties we have encountered. Keywords : Industrialization, DevOps, Continuous Delivery, Ansible, Rundeck, Infrastructure As Code
What are the Cool Kids Doing With Continuous Delivery?CA Technologies
Building a solid application delivery tool chain is no easy task. The popularity of infrastructure configuration management tools like Puppet, Chef, Salt and others are a direct result of the explosion of virtual machines needing to be maintained, configured and provisioned. Learn how you can leverage these trends and combine infrastructure configuration and release automation to build an enterprise class continuous delivery solution for your business.
For more information on DevOps solutions from CA Technologies, please visit: http://bit.ly/1wbjjqX
Continuous Integration promises faster delivery of higher quality software through an integrated automated build, test, and release management.
The greater challenge lies not within a project or team, but as you look to scale this across a larger organization or enterprise-wide. How do you allow teams to choose the tools and processes, yet ensure all stakeholders have full visibility and traceability across all your delivery pipelines and in real time?
In this webinar, we will demonstrate how you can implement a CI environment leveraging popular open source tools (or any tool) using TeamForge.
APIs accelerate agility, empower developers, and enable innovative business strategies. But how do you ensure the security of your API architecture as you expose your corporate data to mobile apps, developers, and partners? Does your API security framework enable DevOps agility and a scalable security model for IT?
Join Apigee’s Tim Mather and Subra Kumaraswamy as they discuss API security considerations for DevOps, CSOs, and security professionals. Learn about API security, threat protection, identity capabilities, infrastructure security, and compliance.
Rundeck + Nexus (from Nexus Live on June 5, 2014)dev2ops
The SimplifyOps team was on Nexus Live talking about how people use Rundeck and the integration between Rundeck and Nexus.
Link to the webcast:
https://www.youtube.com/watch?v=eHaEEBEMRA8
Master Chef class: learn how to quickly cook delightful CQ/AEM infrastructuresFrançois Le Droff
ConnectCon 2014 presentation
Francois and Nicolas share their latest experiment coding AEM 6 infrastructure with Chef. Learn how to start from bare metal - virtual, physical or cloud - servers and turn them, in matter of minutes, into a production ready AEM 6 infrastructure. Think author and publish farms, optional SSL, dispatcher, and clustering with MongoDB) Meanwhile you’ll be given a comprehensive overview of Chef resources and techniques enabling you to accelerate, scale, simplify and secure your development and release workflow.
Continuous Delivery with Jenkins and Wildfly (2014)Tracy Kennedy
A presentation on a continuous delivery pipeline that leverages Jenkins Enterprise, Jenkins Operations Center, Nexus, HAProxy, and Wildfly. Pipeline components run in Docker containers along with SkyDock/SkyDNS for service discovery and NSEnter for command-line access to containers.
As SDN technologies become more mainstream, it is imperative to replicate the success of DevOps techniques from the IT world to bridge the gap that few envisioned in the first place –between the Application/Service and the Network layer.
This presentation made in the DevNet Zone at Cisco Live, San Francisco, 2014.
Moving to Microservices with the Help of Distributed TracesKP Kaiser
Moving away from a monolith to a microservices architecture is a process fraught with hidden challenges. There's legacy code, infrastructure, and organizational processes that all need to change, in order to make the switch successful.
But microservices come with a huge increase in infrastructure complexity. We'll see how distributed traces empower developers to work with greater autonomy, in increasingly complex deployment environments.
Survey after survey prove that DevOps and Continuous Delivery are quickly moving into the mainstream for one reason: they work! Continuous processes done right will increase productivity, speed up time to market, reduce risk, and increase quality. For more information, visit: http://www.dbmaestro.com/
Confoo-Montreal-2016: Controlling Your Environments using Infrastructure as CodeSteve Mercier
Slides from my talk at ConFoo Montreal, February 2016. A presentation on how to apply configuration management (CM) principles for your various environments, to control changes made to them. You apply CM on your code, why not on your environments content? This presentation will present the infrastructure as code principles using Chef and/or Ansible. Topics discussed include Continuous Integration, Continuous Delivery/Deployment principles, Infrastructure As Code and DevOps.
My talk from DevOpsCon Berlin 2016.
Ansible is a radically simple and lightweight provisioning framework which makes your servers and applications easier to provision and deploy. By orchestrating your application deployments you gain benefits such as documentation as code, testability, continuous integration, version control, refactoring, automation and autonomy of your deployment routines, server and application configuration. Ansible uses a language that approaches plain English, uses SSH and has no agents to install on remote systems. It is the simplest way to automate and orchestrate application deployment, configuration management and continuous delivery.
In this tutorial you will be given an introduction to Ansible and learn how to provision Linux servers with a web-proxy, a database and some other packages. Furthermore we will automate zero downtime deployment of a Java application to a load balanced environment.
Presentasjon fra Smidig Digitalisering i Offentlig Sektor 2016. Basert på blogpost: http://open.bekk.no/orkestrering-av-it-utvikling-i-store-organisasjoner
Både store og små prosjekter forventes å bli ferdige på en eller annen dato. Det er ikke bare størrelsen som er problemet. Det er selve arbeidsformen.
Prosjekt skaper konflikt mellom prosjektmål og virksomhetens mål, stor avstand mellom prosjekt- og linjeorganisasjon, en kortsiktig finansieringsmodell og utfordringer med overlevering og kunnskapsoverføring.
Å behandle leveransene som kontinuerlige produktutviklingsløp i linja gjør det enklere å realisere gevinster kontinuerlig, justere initiativene opp mot virksomhetens mål, involvere hele organisasjonen, løpende finansiering, bedre kommunikasjon og kunnskapsbygging istedenfor kunnskapsoverlevering.
Kontinuerlige Leveranser og DevOps er praksiser som lar virksomheter dytte idéer ut til sine kunder før andre er ferdige med sin første iterasjon. Kvaliteten på det som leveres øker i takt med hyppigheten på leveransene. Tettere samarbeid mellom drift og utvikling bidrar til at alle trekker i samme retning. Det er forretning som bestemmer når noe skal ut i produksjon, ikke IT. Vi er vitne til et av de største paradigmeskiftene innen IT i vår tid. De som ikke transformerer sine IT-organisasjoner risikerer å bli etterlatt for å dø.
Stein Inge vil i dette foredraget forklare hva DevOps og Kontinuerlige Leveranser innebærer og hvorfor det er så viktig å ikke bli sittende på gjerdet. Han vil også presentere egne erfaringer med å levere kontinuerlig.
Zero Downtime Deployment with Ansible - learn how to provision Linux servers with a web-proxy, a database and automate zero downtime deployment of a Java application to a load balanced environment.
These are the slides from a tutorial held at the Velocity Conference in Barcelona November 19th, 2014.
Git repo: https://github.com/steinim/zero-downtime-ansible
Det er mye buzz rundt kontinuerlige leveranser og DevOps blant utviklere for tiden. Men hvorfor er dette også interessant for forretning? Hva gir det av verdi?
Når du driver med kontinuerlig leveranse er det et problem om du har nedetid hver gang du produksjonssetter når målet er å produksjonssette så ofte du kan. I denne lyntalen vil jeg vise hvordan du kan unngå nedetid når du deployer Java-web-applikasjoner. Jeg vil vise hvordan du kan deploye (og rulle tilbake) nye versjoner, og også hvordan du bør håndtere databaseendringer (og rollback) mellom deployments.
Kontinuerlige Leveranser og Devops praktiseres av svært mange skal man tro buzzen. Ved hjelp av nye verktøy og prosesser dytter virksomheter idéer ut til sine kunder før andre er ferdige med sin første iterasjon. Det er kunden som bestemmer når noe skal ut i produksjon, ikke IT. Og dette får de til uten å kompromisse på kvalitet. Hvem kunne ikke tenke seg å ha det sånn? Hvordan får de det til?
Vår erfaring er at det er lite hensiktsmessig, og til en viss grad svært farlig, å forsøke å få til dette i ett jafs. En mer fornuftig tilnærmingsmåte er å bygge stein for stein basert på tilstanden man befinner seg i, og gradvis forbedre situasjonen. Vi har laget en modenhetsmodell for kontinuerlige leveranser som inneholder teknikker og verktøy som bringer en nærmere målet, og det fine med å være på denne "reisen" er at hvert steg gir stor verdi i seg selv. I foredraget vil vi presentere noen erfaringer på godt og vondt med å implementere steg i modellen.
Vi vil starte med å presentere modenhetsmodellen, for deretter å ta for oss noen av teknikkene vi har hatt erfaringer med. Disse er; effektiv bruk av versjonskontroll, branch by abstraction, feature toggles, deployment pipelines med Jenkins, infrastruktur som kode med Puppet, virtualisering av produksjonslike miljøer for utvikling og test (Virtualbox, Vagrant), one-click deploy (og tilbakerulling), nedetidfri produksjonssetting og håndtering av databasemigrering (og tilbakerulling).
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
3. Agenda Who are we, where do we come from and what do we work on? What does Continuous Delivery really mean? Collaboration, Version Control and Continuous Integration. Controlled deployment Zero-down-time redeploy (and roll-back). Robust applications (architecture) Provisioning of Infrastructure for Continuous Delivery. Error handling, Monitoring and health verification. Migrating databases. Summary, organizational impacts and business value.
4. Stein IngeMorisbak Information Science, University of Bergen 10 years + Operator (≈ 2) Consultant (≈ 5) NorgesGruppen Data (≈ 6) Many roles: Developer Operator Tech lead Architect Agile/Tech coach Manager
5. Digipost National service for digital mail. Replacement for physical box. PostenNorge AS. Launched april 4th. Java. 13 developers on the team. I’m tech lead. Agile process. Self organizing. Continuous Delivery. Deployment of new features every week.
6. Ole Christian Rynning Master IT, UiO 5 years + Consultant (≈ 4) Many roles: Developer UI Developer Operator Tech lead Architect Creative Leader
7. Bring Development Team Bring Business side (B2B) of Norway Post Consists of 8 specialists (Express, Parcels, Cargo, Frigo, Mail, …) Several projects Tracking (public, B2B, APIs, mobile applications) (6 rels 2011) Mybring (reports, calculators, APIs) (2 rels 2011) Fraktguide (B2B, B2C, price quoting service) (2 rels 2011) Booking (Order products across all specialists) (42 rels 2011) Java & Ruby 10 developers, 2 UX, 1/3 operators, 4 product managers, … Post-Agile process Delivers Continuously *
10. Principles behind the Agile Manifesto We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
11. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
12. What is Continuous Delivery? Continuousdelivery is about putting thereleaseschedule in the hands ofthe business, not in the hands of IT. Implementingcontinuousdeliverymeansmaking sure yoursoftware is alwaysproductionreadythroughoutitsentirelifecycle – thatanybuildcouldpotentially be released to users at the touch of a buttonusing a fullyautomatedprocess in a matter ofseconds or minutes. - Jez Humble (http://continuousdelivery.com/)
14. It’s all about Business Value Reduce Operational Expenditure (OPEX) Reduce manual bottlenecks Reduce overhead in communication (bust dev-qa-ops silos) Increased control over software’s life cycles Reduce Capital Expenditure (CAPEX) Increase/optimize utilization (i.e. virtualization) Reduce startup costs Increase Customer Satisfaction (Protection) Improve usability, performance, security, requirements Respond quicker to customer demands Increase brand value (Revenue)
15. Questions you need to answer Are you able to put new featuresinto production within a reasonable amount of time (i. e. less than a day)? You don´t have that requirement? What about bug-fixes? Would your customer be happier if she made a decision and saw it in production the same day? Would your customer be happier if you could deploy without down-time? Would you trust your deployment process more if you did it more often? Would you feel more safe if you deployed fewer features to production at a time? Would you feel more safe if you had less things that could go wrong? Would you be happy with a heavy manual deployment process if you where to release several times a week? Would operations be happier (and everyone else safer) if deployment was automated instead of documented. Would you be happier (and not so lonely) if you could deploy during work hours instead of in the middle of the night? Are you able to roll-back (alternatively roll forward) if deployment fails?
17. The Challenge How long would it take your organization to deploy a change that involves just one single line of code? Do you do this on a repeatable reliable basis? - Mary and Tom Poppendieck
18. Conway’s law ...organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations - Melvin Conway, 1968 www.melconway.com/research/committees.html
20. Continuous Delivery team Trust and collaboration. Transparent (big visible displays, demos and retrospects). Releases driven by business needs and fast feedback. Fearless (config. mgmt., automated testing at all levels, CI) Disciplined (don’t break/bend the rules) Self sufficient and cross-functional (devs, customers, testers, ops, dbas) Rehearses deployment and roll back. Everybody is responsible for delivery. Everyone can self-service deployments. Continuously improving automation speed (fast build etc.) The team is continuously improving.
21. Continuous Improvement A self organizing team is like evolution, only with a shorter time span. In biological systems self-organization is a process in which pattern at the global level of a system emerges solely from numerous interactions among the lower-level components of the system. Moreover, the rules specifying interactions among the system's components are executed using only local information, without reference to the global pattern. (Wikipedia) You must improve! Process. Build quality in (don’t waste time on mass inspection). You must become better! Skills. You must learn! Try things you don’t know the outcome from. Fail fast. If it hurts, do it more often, and bring the pain forward.
24. But! That is not my stack! Not all technologiesareeasy to workwithwhenimplementingContinuous Delivery. Whatstackareyou (forced to be) using? Knoweachdependency in anystack Why is it there? Whatdoes it do? Whytheversion?
25. Nightmare Architects Ivory Tower Architects Strives towards higher levels of abstractions portable across platforms and systems. (Believes there is a single “the Solution” to architecture). Loves boxes and straight arrows. May code frameworks that future projects have to use* Usually won’t listen to neither developers nor users / customers. More detrimental to any Enterprise than they will ever realize. Tell-tales: “Use JSF on all web-applications”. “You haven’t used all eight layers that our guidelines prescribe”. “OK. As long as it is Oracle/IBM”. “Everything has to go through the service bus”. “All applications should follow <title of 500 page guideline document>”.
30. Be Cynical with architecture. Whatever you do not test against, WILL happen. Assume all Integration Points will go down, congest, return corrupt data, incomplete data, be slow, … Assume all low-level connections (pools, concurrency, …) will at sometime fail. Assume your application will die. Know your application’s life cycle, and failure modes Keep environments as equal as possible. Attack environment-based configuration with vigor.
31. Choose automatable Technology Use an embedded container. (Executable jar with war) No need to deploy, just start and stop. Trivial to setup. Full control over the JVM. Easy to automate. Easy to post-mortem (kill -3 <pid>) Some containers that work: Jetty Netty / Grizzly Glassfish (at least before Oracle) See: https://github.com/bekkopen/jetty-pkg
32. Understand Application/ Failure modes Traditional (UNIX) application Life cycles start, stop, status, reload Use pidfiles, locks Application-critical life cycles graceful-stop/drain, set-read-only Support inspection of application state (status) health-check, session-status, build version, active feature toggles, configuration Support quick inspection of failed applications thread-dump (kill -3), backup-db, log-backup
33. Understand (and automate) Application Life Cycles Understand logging concerns Operation/application status events (errors) - AUTOMATE Business events/Audit events (warn) Debugging events (info, debug, …) Keep configuration minimal Separate environment and application configuration* Keep environment configuration to an absolute minimum Know your hardware limitations If one of four balanced nodes die, and the nodes are 50% utilized. The load on a single node will be significant (66% utilized). If another dies the system is on the edge.
34. Longevity: Impulse and Strain Impulses (Stress) Christmas Getting Slashdotted Annual settlement adding 100 million transactions to a queue Counter: Heavy load tests, Fallback switches Strain (Longevity) Memory leakage and consumption Data growth Dying connections / low level Counter: Timeouts, Fallbacks
35. Continuous Integration Run against develop branch. Clone builds for long-lived branches. Automate testing (against a production like environment). Unit tests, integration tests, system tests, performance tests, security tests,(functional acceptance tests)… Keep the build fast. Unit tests, integration tests, slow tests. Deploy the latest executable to a repository (Nexus, Artifactory) Visibility (Lava lamps, monitors, air strike alarm…, e-mail) Automate deployment. See: http://martinfowler.com/articles/continuousIntegration.html
36. Safety measures (Continuously run) Fail fast Build Metrics System tests Environment tests Integration tests Application tests
37. Metrics What do you want to measure? Test coverage? Lines of code? Code metrics? Checkstyle violations? Do you automate metrics and create reports (e. g. Sonar)? How often do you look at those reports? Alternative: Automate and break the build if you violate your rules.
40. When to push and when to pull? Push: Allows anyone to push. Automated. Caller configures server. Easier? Pull: Initiated by authorized caller. Same artifact is pulled to different environments. Server configures itself. Safer? Vague difference: Push -> Pull: Server requests a push. Pull -> Push: Sshand issue pull command.
42. What is Version Control? A repository ofcontent. Access to historicaleditionsofeach datum. A log of all changes. A toolthatmanages and tracks different versionsofsoftware or othercontent.
43. Version Control for Continuous Delivery Keep (almost) everything in version control! WiP must be separated from code in production. Hot-fixes must happen on code in production. Release branches prevent freezes and delays. Avoid big scary merges.
46. We have to separate WiP from production ready code Extra production release Master Initial production version Next production release Next production release Bug! Merge Fix Develop F1 F2 F3 F4 F5 F6 F7 F8 F9 F9 Oh no! Release plan 1 Release plan 2 Release plan 3
47. Git – Create development branch $ git checkout -b develop Switched to a new branch ”develop"
48. We have to detach features from the release plans Time Master Initial production version Next production release Next production release Big bug! ! Fix Develop F1 F4 F8 Feature branches F2 F5 F7 F10 F3 F6 F9
49. Git – Feature branches Create: $ git checkout -b <id>_<description> Switched to a new branch "<id>_<description>” Merge: $ git checkout develop Switched to branch ’develop' $ git merge --no-ff <id>_<description> Updating ea1b82a..05e9557 (Summary of changes) $ git push origin develop Delete: $ git branch -d <id>_<description> Deleted branch <id>_<description>
50. We have to detach hot-fixes from production and develop Extra production release Extra production release Extra production release Master Initial production version Next production release Next production release Big bug! ! ! Big bug-fix Hot-fix branches !2 !1 Develop F8 F4 F1 Feature branches F7 F10 F5 F2 F6 F9 F3
55. Git – release branches -> merge and deploy $ git checkout master Switched to branch 'master' $ git merge --no-ff release-<version> Merge made by recursive. (Summary of changes) $ mvn clean release:prepare $ mvn clean release:perform -Dgoals=deploy $ mvn clean deploy $ git checkout develop Switched to branch ’develop' $ git merge --no-ffrelease-<version> Merge made by recursive. (Summary of changes) $ git branch -d release-<version> Deleted branch release-<version> (was ff452fe).
56. Feature branching vs. Continuous Integration Feature 1 BIG SCARY MERGE Feature 2 Feature 1 OK Feature 2
57. Avoiding the Big Scary Merge The problem with continuous integration: Potentially unfinished features in mainline. Hence you can not deploy whenever you want. The Digipost project: 13 developers. uses feature branching and releases to production every week. have never had serious merge problems. Keep your features small! Improve the features iteratively. You can check in unfinished features (!) As long as it doesn’t compromise the rest of the system. Use feature toggles.
58. Feature toggles feature_toggles.properties mail.enabled=true sms.enabled=false send_message.jsp <toggle name=mail.enabled> . mail UI elements </toggle> SmsService.java ... booleansmsEnabled; if (smsEnabled) { sendSms(); } ... Have a common strategy/framework. Configuration in one place. Toggle in as few places as possible. Avoid polluting your code.
62. Sample VO package no.bring.booking.operations; public class Health { final String name; final Boolean status; public Health(String name, Boolean status) { this.name = name; this.status = status; } }
63. Example implementation class ShipmentNumberClient implements HealthCheckable { // initialized from environment cfg private final String healthCheckUri; // ... @Override public Health healthCheck() { return new Health("bring-shipment-number", isHealthy()); } private booleanisHealthy() { try { Client client = HttpClientFactory.createTimingoutClient(2000); WebResourcewebResource = client.resource(healthCheckUri); return fromStatusCode(webResource.head().getStatus()) == OK; } catch (Exception ignored) { return false; } }
64. Build information Maven: buildnumber-maven-plugin Generates ${buildNumber} Can generate timestamp and other build info Maven: git-commit-id-plugin Generates various git metadata. Such as ${git.commit.id} Date: ${maven.build.timestamp} For another example: http://www.blog.project13.pl/index.php/fun/1174/release-maven-git-commit-id-plugin/
66. Tool Chain For Setting up Architecture System configuration Cloud/VM OS Install Application Service Deployment Scripting Fabric Capistrano MCollective ControlTier Go ----------------- Puppet Chef Cfengine ----------------- Kickstart Jumpstart Solaris LiveUpdate tftp…
75. 3 pillars of Continuous Delivery Automationof build, test, deployment, database migrations, and infrastructure Practices, such as continuous integration, good configuration management, and testing People; having everyone involved in delivery work together throughout the software delivery lifecycle.
76. Business Value Reduction of cost (through light-weight infrastructure and simplicity). Reduction of risk (through more automation and practice). But most important: Frequent release of new software functionality. How can we benefit from releasing new functionality monthly, weekly, or even daily? How will our organization and business processes need to change? ?
77. Agile/adaptive maturity Continuous delivery may be the next big step in delivering strategic business value to clients quickly, with lower risk and possibly lower cost. However, it won’t happen unless leadership understands its potential strategic impact and the organizational adaptability necessary to implement it. - Jim Highsmith Many organizations are stuck at Agile 101. the rule-based approach to agile (do this, don’t do that). a necessary first step towards becoming agile, but it’s only a first step. The next step is to embrace change and respond respectively. the entire organization, both delivery teams and management. embrace the process changes required to respond rapidly. engage in the collaboration required between development and operations. embrace an adaptive, exploratory mindset.
79. License & Copyright stuff Images used are either fair use (book covers, Star Wars), public domain or Creative Commons BY-SA licensed. All content in this presentation is Creative Commons BY-SA 2.0. Please credit Ole Christian and Stein Ingeif you decide to use the slides.
1) Innledning- Vi stiller spørsmåltilsalen: Hvoroftedeployererdere? Hardereautomatisertdeployering? - Continuous Delivery vs. CI / CD(eployment), Agile manifest, etc- Automatisering - Viktighetavåvelgeautomatiserbarteknologi, etc- Like miljøer- Gjenproduserbarhet, osv
Eksempelprosjekt:Behov: * En server somkankjøre to-fire ulikevirtuelleservereForslagtilmiljøstack:* Frontend: nginxeller apache* Applikasjon: se under* Database: mysqlellerpostgresql* Automatisert med puppetEnkel CRUD-webapp med litt basis-funksjonalitet* Integrasjon mot eksterntgrensesnitt (f.eks. Bring Fraktguide // postnummervalidering, etc).* Forslagtilenkel stack: Spring(opsjonellt), Spring JDBC, et webrammeverk (Jersey eller Spring MVC), * Deployesienkel jetty-war* Littrammeverkskode for konfigurasjon / init-scriptInteraktive features:* Feature toggle: Slåav / på JSON-grensesnitt* Feature branch: Utvidegrensesnitt med XML-supportEndring 1: Slåpåstylesheet, css, etc
* Usually don’t code
Push vs. pull –basert deploymentKonfigureringavmiljø: Jenkins? Nexus (pull)?
Push vs. pull –basert deploymentKonfigureringavmiljø: Jenkins? Nexus (pull)?
3) Jobbing/Samarbeiditeamet(ne) ogkontinuerligintegrasjon- Innledning: versjonskontrollavprosjektet. Feature branching. Feature toggling. Littomteamsammensetninger: deployeselv, vs. ha en devoppåteamet, etc. Innledningtileksempelprosjektet.- Spm: Hvor mange har en drifter påteamet? Hvor mange brukergit? Hvor mange brukerclearcase? Hvor mange haransvar for ålevere? Hvor mange mener at man erferdignår man leverertil QA? Hvor mange harforretningsutvikling? Kanban? ITIL (UFF)?- Vi demonstrereroppsettav en applikasjoni et gittutviklingsmiljø:* Versjonskontroll for kontinuerlig levering* Byggserversomkjører tester ogdeployertil nexus* Applikasjonsoppsett med maven/rake/etc (applikasjonskonfigurasjon)* environment:setup (klargjøringav server for applikasjonen)- Muliginteraksjon: Vi girhvert team en enkeloppgave (f.eks. team 1 skalendre en kodelinjeog en test, team 2 skalslåpå en feature, team 3 skal merge inn en feature-branch i master/release, ...)
Code base is never production ready!When to release?WIP hinders us from putting ready features into productionWe are never done done!
What happens if you forget to merge the bug fix into development?What happens if features are delayed?
Grey arrows: Potentially shippable
Rember to merge back to develop!
Release branches frees up the development branch for further development.It also frees up the master branch for bugfixes.
- Innledning: Kortinnledningomhvorfordeterviktigåogsåautomatisereverifisering (isåstor grad somdetermulig)- Events vs. logging- Vi demonstrerernoenteknikker for åverifisere at applikasjoneneri god helse (GET http://node/health, GET http://node/version, logger feil =>...)- Enkeleksternovervåkningav http://app/health- Enkelnagios-monitoreringavmiljø- Eks: cucumber-nagios* Feilscenarie 1: Vi demonstrerer en applikasjonsfeilsomskjeri runtime (f.eks. DB-fuckup somkræsjerapplikasjonen) => (ERROR fraovervåkning) red - vi demonstereropprettelseavfiks, test for åhindreframtidigfeilog redeploy => green* Feilscenarie 2: Vi demonstrerer en brukerfeilsomskjeri runtime => red (ERROR iloggen) (f.eks. manglendevalideringoghvordandetteplukkesoppav log-monitorering) - vi demonsterermuligfiks, mer robust test for åhindreframtidigfeil, og redeploy => green
- Innledning: Vi fortellerom et par ulikemuligeløsninger, vi fortellerom de ulikestegene en applikasjonkanfeilei (bygg, test, release, upload, stop, start, verify (health), runtime). Littomsesjonerog draining avsesjoner (ta en node ned -> vent tilallesesjonererferdige -> fortsett redeploy).- Demonstrasjon: Vi deployerernyversjon (uten DB-endring) til de ulikemiljøene* environment:deploy (utrullingtilservere - push - med venting ogverifiseringavstegenei upload, stop, start, verify)* puppet / environment:update (utrullingtilservere - pull fra nexus - med manuellhåndteringav deploy tilnoderogevt. switchover strategi /f.eks. switche QA og PROD)- Muliginteraksjon: Teamene pusher sine endringerog vi demonstrererautomatisertkontinuerligutrullingav de ulikeversjonenesomblelageti 3)
- Innledning: vanskeligheter. It depends! Vanskeligereåautomatisere- Vi demonstrererautomatisering med liquibaseogf.eks. dbdeploy.- Vi demonstrerer expand/contract patternet for DB-migrering.- Vi demonstrerer read-only-state for systemet.
- Littomorganisasjonellekravogutfordringer, f.eks. Lean / Kanban / JIT / etc, ITIL, eksternedriftere, etc...- Littmeromverdien (fåutforretningsverdi, fåned lead time, fånedantallfeili prod, fiksefeil, prodsettepådagtid, sikkerhet
Jim HighsmithThoughtWorksco-author the Agile Manifestoco-founded the Agile Alliance, and the Agile Project Leadership Network.