Many project teams have adopted unit testing as a necessary step in their development process. Many more use a test-first approach to keep their code lean. Yet, far too often these teams still suffer from many of the same impediments: recurrent integration failures with other enterprise projects, slow feedback with the customer, and sluggish release cycles. With a languishing feedback loop, the enterprise continues to put increasing pressure on development teams to deliver. How does an aspiring agile team improve to meet the demands of the enterprise?
Continuous integration is the next logical step for the team. In this talk, you’ll learn how continuous integration solves intra and inter-project integration issues without manual overhead, the value added by continuous integration, and how to leverage tools and processes to further improve the quality of your code. Finally, we discuss the gold standard of agile teams: continuous deployment. You’ll learn how continuous deployment helps close the feedback loop with your customers, increases visibility for your team, and standardizes the deployment process.
Helping Ops Help You: Development’s Role in Enabling Self-Service OperationsRundeck
Presented by Damon Edwards, co-founder of Rundeck, at JAX DevOps and Finance London, April 5, 2017.
DevOps has provided plenty of lessons for how to speed up the pace of delivery and frequency of deployments. But, delivery and deployment only covers one part of the day-to-day life for developers in large enterprises.
What about what happens after deployment? In most cases, increasing the pace of delivery and frequency of deployment just increases the operational support load, work interrupts, and context switching that has always cut deeply into a development team’s time.
This talk focuses on the successful design patterns that high-performing, large scale organizations have applied to reduce the operational burden and support costs across their entire organization. Specifically, we’ll look at how they apply DevOps principles to improving the post-deployment lifecycle and how Developers play the key role in reducing the difficultly and cost of operations activity for everyone.
See a Demo of Rundeck Enterprise :
https://www.rundeck.com/see-demo
--or--
Download Rundeck Open Source here:
https://rundeck.com/open-source
Connect:
Stack Overflow community: https://stackoverflow.com/questions/tagged/rundeck
Github: https://github.com/rundeck/rundeck/issues
Twitter: https://twitter.com/Rundeck
Facebook: https://www.facebook.com/RundeckInc/
LinkedIn: www.linkedin.com › company › rundeck-inc
The practical implementation of Continuous Delivery at Etsy, and how it enables the engineering team to build features quickly, refactor and change architecture, and respond to problems in production.
Presented at GOTO Aarhus 2012.
Like what you've read? We're frequently hiring for a variety of engineering roles at Etsy. If you're interested, drop me a line or send me your resume: mike@etsy.com.
http://www.etsy.com/careers
Etsy deploys code and configuration changes over 40 times per day using a distributed release management system. The process involves automated testing, deployment to pre-production environments, monitoring, and human oversight throughout. Deployments take around 15 minutes on average and involve parallel testing, configuration changes, and code deployment to multiple environments. The system provides improved visibility, communication, and a record for post-mortems. It was developed through iterative improvements over four years.
Principles and Practices in Continuous Deployment at EtsyMike Brittain
This document discusses principles and practices of continuous deployment at Etsy. It describes how Etsy moved from deploying code changes every 2-3 weeks with stressful release processes, to deploying over 30 times per day. The key principles that enabled this are innovating continuously, resolving scaling issues quickly, minimizing recovery time from failures, and prioritizing employee well-being over stressful releases. Automated testing, deployment to staging environments, dark launches, and extensive monitoring allow for frequent, low-risk deployments to production.
The document discusses software testing practices in agile development. It covers the technical and organizational challenges of testing in an agile environment where requirements are changing frequently. It emphasizes the need to test early and often through automation, and describes strategies like test-driven development and maintaining different levels of testing at the iteration and release levels to effectively test in short iterations with changing requirements.
This document provides an overview of test driven development (TDD), continuous integration (CI), continuous delivery (CD) and continuous deployment. It defines TDD as writing tests before code to guide development. CI involves integrating code into a shared repository daily and automating builds and testing. CD allows software to be released to production at any time if all tests pass. Continuous deployment automatically deploys software to production whenever changes are merged into the main branch. The document discusses benefits like higher quality, faster delivery and flexibility, and recommends automating everything and having developers and operations work together.
The document discusses best practices for continuous integration, continuous delivery, and automation in software development. It recommends automating the entire development cycle from build to test to deployment. Changes should be deployed frequently, such as multiple times a day, to catch errors early. All code, configurations, and dependencies should be stored in version control. A deployment pipeline approach is advocated with separate stages for testing, verification, and release to different environments. Rollback and recovery should be planned and tested.
The document summarizes 7 tools for a devops stack:
1) Automation tools like Puppet, Chef, and Jenkins are used to automate deployments and configurations.
2) The Marionette Collective allows orchestrating tasks across servers like checking statuses and restarting services.
3) FPM helps create software packages to address issues with packaging dependencies and versions.
4) Logstash is used for centralized logging and shipping logs anywhere while filtering and indexing them.
5) Graphite and Kibana provide visualization and graphing of metrics at scale for monitoring.
Helping Ops Help You: Development’s Role in Enabling Self-Service OperationsRundeck
Presented by Damon Edwards, co-founder of Rundeck, at JAX DevOps and Finance London, April 5, 2017.
DevOps has provided plenty of lessons for how to speed up the pace of delivery and frequency of deployments. But, delivery and deployment only covers one part of the day-to-day life for developers in large enterprises.
What about what happens after deployment? In most cases, increasing the pace of delivery and frequency of deployment just increases the operational support load, work interrupts, and context switching that has always cut deeply into a development team’s time.
This talk focuses on the successful design patterns that high-performing, large scale organizations have applied to reduce the operational burden and support costs across their entire organization. Specifically, we’ll look at how they apply DevOps principles to improving the post-deployment lifecycle and how Developers play the key role in reducing the difficultly and cost of operations activity for everyone.
See a Demo of Rundeck Enterprise :
https://www.rundeck.com/see-demo
--or--
Download Rundeck Open Source here:
https://rundeck.com/open-source
Connect:
Stack Overflow community: https://stackoverflow.com/questions/tagged/rundeck
Github: https://github.com/rundeck/rundeck/issues
Twitter: https://twitter.com/Rundeck
Facebook: https://www.facebook.com/RundeckInc/
LinkedIn: www.linkedin.com › company › rundeck-inc
The practical implementation of Continuous Delivery at Etsy, and how it enables the engineering team to build features quickly, refactor and change architecture, and respond to problems in production.
Presented at GOTO Aarhus 2012.
Like what you've read? We're frequently hiring for a variety of engineering roles at Etsy. If you're interested, drop me a line or send me your resume: mike@etsy.com.
http://www.etsy.com/careers
Etsy deploys code and configuration changes over 40 times per day using a distributed release management system. The process involves automated testing, deployment to pre-production environments, monitoring, and human oversight throughout. Deployments take around 15 minutes on average and involve parallel testing, configuration changes, and code deployment to multiple environments. The system provides improved visibility, communication, and a record for post-mortems. It was developed through iterative improvements over four years.
Principles and Practices in Continuous Deployment at EtsyMike Brittain
This document discusses principles and practices of continuous deployment at Etsy. It describes how Etsy moved from deploying code changes every 2-3 weeks with stressful release processes, to deploying over 30 times per day. The key principles that enabled this are innovating continuously, resolving scaling issues quickly, minimizing recovery time from failures, and prioritizing employee well-being over stressful releases. Automated testing, deployment to staging environments, dark launches, and extensive monitoring allow for frequent, low-risk deployments to production.
The document discusses software testing practices in agile development. It covers the technical and organizational challenges of testing in an agile environment where requirements are changing frequently. It emphasizes the need to test early and often through automation, and describes strategies like test-driven development and maintaining different levels of testing at the iteration and release levels to effectively test in short iterations with changing requirements.
This document provides an overview of test driven development (TDD), continuous integration (CI), continuous delivery (CD) and continuous deployment. It defines TDD as writing tests before code to guide development. CI involves integrating code into a shared repository daily and automating builds and testing. CD allows software to be released to production at any time if all tests pass. Continuous deployment automatically deploys software to production whenever changes are merged into the main branch. The document discusses benefits like higher quality, faster delivery and flexibility, and recommends automating everything and having developers and operations work together.
The document discusses best practices for continuous integration, continuous delivery, and automation in software development. It recommends automating the entire development cycle from build to test to deployment. Changes should be deployed frequently, such as multiple times a day, to catch errors early. All code, configurations, and dependencies should be stored in version control. A deployment pipeline approach is advocated with separate stages for testing, verification, and release to different environments. Rollback and recovery should be planned and tested.
The document summarizes 7 tools for a devops stack:
1) Automation tools like Puppet, Chef, and Jenkins are used to automate deployments and configurations.
2) The Marionette Collective allows orchestrating tasks across servers like checking statuses and restarting services.
3) FPM helps create software packages to address issues with packaging dependencies and versions.
4) Logstash is used for centralized logging and shipping logs anywhere while filtering and indexing them.
5) Graphite and Kibana provide visualization and graphing of metrics at scale for monitoring.
Scrum Plus Extreme Programming (XP) for Hyper ProductivityRon Quartel
If you want to go fast with Scrum, then your best option is to compliment it with Extreme Programming (XP). Inside is an activity that you can run your team and management through to prove and sell the concept.
Automate across Platform, OS, Technologies with TaaSAnand Bagmar
Slides and link to audio from my talk + demo on how to "Automation across Platform, OS, Technologies with TaaS" at Agile India 2014, Bangalore on 1st March 2014
Have you ever bumped into a wall with your automated tests? Many developers bump into various roadblocks and hurdles when writing test code. Are your test methods starting to fail because the code-under-test uses the current date and time? Are your automated integration tests failing because the database they integrate with keeps changing? Do you have an explosion of test methods, with the ratio of test code to code-under-test way too high? Is your effort to refactor and improve code overwhelmed by the time it takes to rewrite all those failing unit tests? This presentation is about clearing away Agile testing obstacles, avoiding common pitfalls, and staying away from dangerous practices.
Flexing your Agile Muscle - Agile Technical Concepts ExplainedSandy Mamoli
Continuous integration, acceptance test driven development (ATDD), specification by example and continuous deployment: The list of have-to-know concepts is growing and you have this nagging feeling that you should really get started so you won’t miss out on the fun.
Learn what basic Agile technical concepts mean, understand how you can benefit from using them and get ideas for how you might get started. Also, you will be able to explain to your boss or project manager why Agile technical concepts are well worth the investment.
This session will keep things on a strictly conceptual level - so whether you’re a developer or an interested manager please come along.
QA team transition to agile testing at Alcatel LucentAgileSparks
In this session I will outline/explore the journey of a common QA team without coding skills into Agile testing arena. Main focus on Acceptance Test Driven Development and executable specs. The session will be based on a real case study from Alcatel Lucent Haifa. At the end of the session you will understand the concept of executable specs,and ATDD, You will see real example of test implementation in ATDD tool (Cucumber) and will understand the steps required to make such transition with some do/not do tips in tool and process implementation (based on Alcatel case study).
You will get (printed) the suggested implementation plan and do/not do tips of ATDD automation tools implementation
The document describes WiredReach's process for implementing continuous deployment. It discusses how they moved from bi-weekly release cycles with large releases to releasing multiple times per day with releases containing under 25 lines of code. This was done by setting up automated testing and deployment pipelines. It also touches on some of the challenges they faced in taking this approach and strategies for incrementally building systems to support continuous deployment like adding production monitoring and building a "cluster immune system".
Matt Callanan takes the 15 chapters of the famous "Continuous Delivery" book by Jez Humble & Dave Farey and distills it down into 1 hour of convincing arguments, walking through the pieces involved to make it happen including cultural challenges, automated testing, automated deployment & deployment pipelines. Not sure how to get started with DevOps? Finding it hard to convince colleagues & managers that CD is the way forward? Matt has used this presentation to help facilitate enterprise-wide adoption of Continuous Delivery. Slides from a presentation given at DevOps Brisbane March 2014.
ALE15 The real value of a definition of doneChristian Vos
The document discusses the value of having a Definition of Done (DoD) for software development iterations. A DoD lists all the criteria needed to consider a user story complete. This helps improve quality, deliver features faster, and minimize bugs and rework. It also provides transparency into a team's process and capabilities. The DoD should evolve over time as a team's skills improve to balance delivering quickly while maintaining quality.
The development of a product from the point of view of a technician, starting from the concept, passing to the minimum viable till a management of a fully operational and deployed app.
This document provides an introduction to infrastructure as code and DevOps. It discusses how infrastructure complexity has increased over time from mainframes to multi-tier applications to cloud computing. It also covers how separate development and operations teams can be merged into a unified DevOps team. Infrastructure as code is introduced as treating infrastructure like code by automating server provisioning, configuration, and changes using tools like Puppet, allowing infrastructure to be version controlled and changes to be tested. This enables continuous delivery of infrastructure updates alongside application code changes.
This document discusses how to integrate Scrum and Behavior Driven Development (BDD). It recommends starting with refining the product backlog by splitting user stories, defining acceptance criteria through examples, and collaborating with stakeholders. Examples show how to write specifications using the Given-When-Then format. The document emphasizes starting each sprint by writing automated tests based on the specifications before writing code. This ensures the team builds the right product by focusing on delivering value through small, testable increments.
This document discusses the DevOps movement and related concepts. It provides background on how development and operations teams historically worked separately ("Devs vs Ops") and the problems that caused. DevOps aims to break down barriers between teams through practices like automation, continuous integration/delivery, infrastructure as code, and collaboration between teams from the beginning of a project. The document outlines problems DevOps aims to solve and gives examples of tools and approaches for bringing development and operations cultures together.
Introduction to Continuous Delivery (BBWorld/DevCon 2013)Mike McGarr
This document provides an introduction and overview of continuous delivery. It discusses why releases are difficult, and proposes continuous delivery as an alternative approach where software is always in a releasable state and deployments can occur frequently through automation. It covers principles like automating everything and keeping the build and release process fast and reliable. Specific practices discussed include configuration management, continuous integration, testing, deployment pipelines, and deployment automation using tools like version control systems, build servers, and configuration management tools.
This document summarizes a presentation on best practices for using Selenium for test automation. The presentation covers 12 steps: 1) Admit you have a problem; 2) Take a deep breath; 3) Try looking at things differently; 4) Pump some tech iron; 5) Find your inner Napoleon and develop a strategy; 6) Break down the wall between QA and development; 7) Learn the terrain; 8) Test less but test well; 9) Keep it lean and optimize; 10) Pay it forward by sharing knowledge; 11) Resources for learning Selenium; 12) Recap of the 12 steps. The document provides additional details on each step and recommendations for learning more.
The document provides an agenda and guidance for facilitating a multi-day release planning event involving breakout sessions at both the track and team levels. Key points include:
- The event will use breakout rooms for teams to decompose features into user stories, size stories, identify dependencies, and populate a release plan across 8 sprints.
- Guidance and "cheat sheets" are provided on techniques for feature decomposition, story sizing, and identifying risks. Sample user stories are to be pre-loaded.
- Each day involves breakout sessions, with time for leadership reviews and adjustments. On day 3 teams will present plans to track leads and participate in a confidence vote.
- In breakouts,
This document provides resources for finding sample legal documents including briefs, motions, complaints, settlements, forms and contracts from websites such as PACER, state court websites, JDSupra, Scribed, Findlaw, Nolo, and local law libraries. It also discusses options for finding jury verdicts from free sources like court websites, news stories, and colleagues, as well as paid services like Jury Verdict Research and VerdictSearch.
This document provides tips for how to search more effectively online. It discusses different types of search engines and directories, how search engines work using keywords and Boolean logic, and recommends tools for managing bookmarks, RSS feeds, blogs and podcasts. Specific search engines mentioned include Google, Bing, Ask.com and DuckDuckGo.
Scrum Plus Extreme Programming (XP) for Hyper ProductivityRon Quartel
If you want to go fast with Scrum, then your best option is to compliment it with Extreme Programming (XP). Inside is an activity that you can run your team and management through to prove and sell the concept.
Automate across Platform, OS, Technologies with TaaSAnand Bagmar
Slides and link to audio from my talk + demo on how to "Automation across Platform, OS, Technologies with TaaS" at Agile India 2014, Bangalore on 1st March 2014
Have you ever bumped into a wall with your automated tests? Many developers bump into various roadblocks and hurdles when writing test code. Are your test methods starting to fail because the code-under-test uses the current date and time? Are your automated integration tests failing because the database they integrate with keeps changing? Do you have an explosion of test methods, with the ratio of test code to code-under-test way too high? Is your effort to refactor and improve code overwhelmed by the time it takes to rewrite all those failing unit tests? This presentation is about clearing away Agile testing obstacles, avoiding common pitfalls, and staying away from dangerous practices.
Flexing your Agile Muscle - Agile Technical Concepts ExplainedSandy Mamoli
Continuous integration, acceptance test driven development (ATDD), specification by example and continuous deployment: The list of have-to-know concepts is growing and you have this nagging feeling that you should really get started so you won’t miss out on the fun.
Learn what basic Agile technical concepts mean, understand how you can benefit from using them and get ideas for how you might get started. Also, you will be able to explain to your boss or project manager why Agile technical concepts are well worth the investment.
This session will keep things on a strictly conceptual level - so whether you’re a developer or an interested manager please come along.
QA team transition to agile testing at Alcatel LucentAgileSparks
In this session I will outline/explore the journey of a common QA team without coding skills into Agile testing arena. Main focus on Acceptance Test Driven Development and executable specs. The session will be based on a real case study from Alcatel Lucent Haifa. At the end of the session you will understand the concept of executable specs,and ATDD, You will see real example of test implementation in ATDD tool (Cucumber) and will understand the steps required to make such transition with some do/not do tips in tool and process implementation (based on Alcatel case study).
You will get (printed) the suggested implementation plan and do/not do tips of ATDD automation tools implementation
The document describes WiredReach's process for implementing continuous deployment. It discusses how they moved from bi-weekly release cycles with large releases to releasing multiple times per day with releases containing under 25 lines of code. This was done by setting up automated testing and deployment pipelines. It also touches on some of the challenges they faced in taking this approach and strategies for incrementally building systems to support continuous deployment like adding production monitoring and building a "cluster immune system".
Matt Callanan takes the 15 chapters of the famous "Continuous Delivery" book by Jez Humble & Dave Farey and distills it down into 1 hour of convincing arguments, walking through the pieces involved to make it happen including cultural challenges, automated testing, automated deployment & deployment pipelines. Not sure how to get started with DevOps? Finding it hard to convince colleagues & managers that CD is the way forward? Matt has used this presentation to help facilitate enterprise-wide adoption of Continuous Delivery. Slides from a presentation given at DevOps Brisbane March 2014.
ALE15 The real value of a definition of doneChristian Vos
The document discusses the value of having a Definition of Done (DoD) for software development iterations. A DoD lists all the criteria needed to consider a user story complete. This helps improve quality, deliver features faster, and minimize bugs and rework. It also provides transparency into a team's process and capabilities. The DoD should evolve over time as a team's skills improve to balance delivering quickly while maintaining quality.
The development of a product from the point of view of a technician, starting from the concept, passing to the minimum viable till a management of a fully operational and deployed app.
This document provides an introduction to infrastructure as code and DevOps. It discusses how infrastructure complexity has increased over time from mainframes to multi-tier applications to cloud computing. It also covers how separate development and operations teams can be merged into a unified DevOps team. Infrastructure as code is introduced as treating infrastructure like code by automating server provisioning, configuration, and changes using tools like Puppet, allowing infrastructure to be version controlled and changes to be tested. This enables continuous delivery of infrastructure updates alongside application code changes.
This document discusses how to integrate Scrum and Behavior Driven Development (BDD). It recommends starting with refining the product backlog by splitting user stories, defining acceptance criteria through examples, and collaborating with stakeholders. Examples show how to write specifications using the Given-When-Then format. The document emphasizes starting each sprint by writing automated tests based on the specifications before writing code. This ensures the team builds the right product by focusing on delivering value through small, testable increments.
This document discusses the DevOps movement and related concepts. It provides background on how development and operations teams historically worked separately ("Devs vs Ops") and the problems that caused. DevOps aims to break down barriers between teams through practices like automation, continuous integration/delivery, infrastructure as code, and collaboration between teams from the beginning of a project. The document outlines problems DevOps aims to solve and gives examples of tools and approaches for bringing development and operations cultures together.
Introduction to Continuous Delivery (BBWorld/DevCon 2013)Mike McGarr
This document provides an introduction and overview of continuous delivery. It discusses why releases are difficult, and proposes continuous delivery as an alternative approach where software is always in a releasable state and deployments can occur frequently through automation. It covers principles like automating everything and keeping the build and release process fast and reliable. Specific practices discussed include configuration management, continuous integration, testing, deployment pipelines, and deployment automation using tools like version control systems, build servers, and configuration management tools.
This document summarizes a presentation on best practices for using Selenium for test automation. The presentation covers 12 steps: 1) Admit you have a problem; 2) Take a deep breath; 3) Try looking at things differently; 4) Pump some tech iron; 5) Find your inner Napoleon and develop a strategy; 6) Break down the wall between QA and development; 7) Learn the terrain; 8) Test less but test well; 9) Keep it lean and optimize; 10) Pay it forward by sharing knowledge; 11) Resources for learning Selenium; 12) Recap of the 12 steps. The document provides additional details on each step and recommendations for learning more.
The document provides an agenda and guidance for facilitating a multi-day release planning event involving breakout sessions at both the track and team levels. Key points include:
- The event will use breakout rooms for teams to decompose features into user stories, size stories, identify dependencies, and populate a release plan across 8 sprints.
- Guidance and "cheat sheets" are provided on techniques for feature decomposition, story sizing, and identifying risks. Sample user stories are to be pre-loaded.
- Each day involves breakout sessions, with time for leadership reviews and adjustments. On day 3 teams will present plans to track leads and participate in a confidence vote.
- In breakouts,
This document provides resources for finding sample legal documents including briefs, motions, complaints, settlements, forms and contracts from websites such as PACER, state court websites, JDSupra, Scribed, Findlaw, Nolo, and local law libraries. It also discusses options for finding jury verdicts from free sources like court websites, news stories, and colleagues, as well as paid services like Jury Verdict Research and VerdictSearch.
This document provides tips for how to search more effectively online. It discusses different types of search engines and directories, how search engines work using keywords and Boolean logic, and recommends tools for managing bookmarks, RSS feeds, blogs and podcasts. Specific search engines mentioned include Google, Bing, Ask.com and DuckDuckGo.
The document discusses several current and upcoming online privacy laws and ethics guidelines that impact legal practice, including:
1) The White House's "Privacy Bill of Rights" and existing laws like GLB, HIPAA, COPPA, and the Stored Communications Act.
2) ABA Model Rules regarding competence, communications, confidentiality, and responsibilities of lawyers and non-lawyers.
3) The ABA Commission on Ethics 20/20 examined whether to add technology proficiency to the Rules of Professional Conduct.
4) Issues around using metadata, attorney-client relationships online, lawyer marketing, blogging, and maintaining separate personal and professional online identities.
REST Easy - Building RESTful Services in Zend FrameworkChris Weldon
The epicenter of data sharing in "Web 2.0" are web services. Whether you like it or not, you are consuming literally hundreds of services a day, whether it be searching in Google, running Facebook on your mobile device, or searching the App Store on your tablet. Yet, despite our hunger for services, few have ever written one. In this session, you'll learn what are RESTful web services and how to get started creating them in Zend Framework.
RESTful API Design & Implementation with CodeIgniter PHP FrameworkBo-Yi Wu
This document provides an overview and summary of Bo-Yi Wu's presentation on implementing a RESTful API with CodeIgniter. The presentation covers RESTful API basics like HTTP methods, JSON response format, API design best practices, and using the CodeIgniter REST Server and REST Client libraries to implement and test APIs within the CodeIgniter framework. Examples are provided for creating, updating, deleting and reading data via API requests and responses. Folder structure and routing configurations for organizing API controllers are also discussed.
Web services tutorial slides from my session at DPC 2012 in Amsterdam. In this 3-hour session we built the simplest possible service, and then extended it, looking at RPC, REST and SOAP along the way.
Continuous delivery requires more that DevOps. It also requires one to think differently about product design, development & testing, and the overall structure of the organization. This presentation will help you understand what it takes and why one would want to deliver value to your customers multiple times each day. #CIC
Jeff "Cheezy" Morgan Ardita Karaj
Release software is no less important than activities that precede it.
The Continuous Delivery is a set of practices and methodologies that build an ecosystem for the software development lifecycle.
We will see how to build this ecosystem around the applications developed, for which this release activities becomes a low-risk, inexpensive, fast and predictable.
This document discusses DevOps concepts and best practices. It recommends breaking down barriers between development and operations, treating infrastructure as code, automating processes, implementing continuous integration and deployment, and monitoring systems. The key aspects are adopting a collaborative culture, implementing automation tools, and establishing practices like infrastructure as code, configuration management, and continuous integration, delivery and deployment.
Testing and DevOps Culture: Lessons LearnedLB Denker
This document discusses the speaker's background and experiences with software engineering practices. It covers his education in computational mathematics and computer science, past roles at Universal Instruments developing machine software and at Google and Etsy implementing DevOps practices. Key topics covered include the benefits of continuous integration, deployment and delivery; the importance of testing including test-driven development; and embracing interdependence between developers and other IT roles. Best practices are noted to be situational and relationships must be respected.
This document discusses the benefits of continuous delivery and deployment. It notes that without proper processes, deployments can fail due to crashes, failed migrations, or interrupted updates when introducing new features. Continuous delivery uses tools and methodologies to make releases low risk, fast, predictable, and ensure smooth deployments. The document outlines some of the key aspects of continuous delivery like source code management, continuous integration, automated deployments, monitoring, and root cause analysis. It discusses how these practices can help make software releases cheaper, more frequent, rapid, and reduce stress and errors compared to traditional release processes.
The Continuous delivery Value @ codemotion 2014David Funaro
System Crash, failure data migration, partial update: issues that no one would ever want to meet during the deploy and ... hoping for the best is not enough.
The deployment activity is important as those that precede it. The Continuous Delivery will give you low risk, cheap, fast, predictable delivery and ... soundly.
This document discusses the "You Build It, You Run It" (YBYR) approach where developers are responsible for the full software release cycle from defining requirements to monitoring in production. The approach aims to speed up feature delivery through faster recovery from failures and more frequent releases. While it provides benefits like fewer production failures, adopting YBYR requires cultural change and depends on context, with no single solution. Frameworks and coaching are important to implement the approach successfully over time without making things worse initially.
[Webinar] Test First, Fail Fast - Simplifying the Tester's Transition to DevOpsKMS Technology
DevOps is a spectacular mish-mash of development and operations processes and practices that has been growing increasingly popular in recent years. With the upward trending rate in adoption comes the need for organizations to fully understand the key practices as well as thoroughly integrating team members, especially testers, throughout the delivery pipeline. Getting started with DevOps practices can be a little tricky when choosing the right tools, people, and processes. In this webinar, we’ll focus on helping you make the switch without diminishing the team’s delivered product quality, so that the transition meets the enterprise objectives of speed and reliability.
Tune in to learn:
The biggest concern when moving to DevOps - and how to handle it
Why you need ‘Coding Testers’
The best tools for the job
The process of failing fast, and its significance to testers
Measuring the transition - recommended metrics
The value of DevOps long-term - efficiency, repeatability & reliability
Don’t worry about failing - it’s a part of the process!
This document discusses DevOps, which breaks down the wall between development and operations teams to promote more collaboration and automation. It emphasizes efficiency, predictability, reproducibility, and maintainability. The document outlines different maturity levels for DevOps processes from manual to optimized. It provides examples of building out deployment pipelines and infrastructure as code. Testing, data management, and automated orchestration are also highlighted as important DevOps practices to deploy applications and rollback changes smoothly. The overall message is that DevOps requires collaboration between development, operations, security, and other teams.
Agile development practices - How do they really work ?anand003
Agile development practices are geared towards shorter feedback cycles and allowing teams to learn from failures. Effective practices include short daily standup meetings to communicate status, pairing programming for continuous code review and problem solving, and test-driven development which uses automated unit and acceptance tests to drive design and provide safety nets. Managing technical debt through prioritizing refactoring work and keeping stakeholders aware is also important for sustainable agile practices.
Why your company loves to welcome change but sucks at accommodating itFarooq Ali
The need for sound engineering practices in Agile. A look at a very common Agile anti-pattern (Flaccid Scrum) found in large organizations, and how to fix it.
Keeping Your DevOps Transformation From Crushing Your Ops Capacity Rundeck
Presentation by Damon Edwards, co-founder of Rundeck, at DevOps Enterprise Summit in San Francisco, November 13, 2017
See a Demo of Rundeck Enterprise :
https://www.rundeck.com/see-demo
--or--
Download Rundeck Open Source here:
https://rundeck.com/open-source
Connect:
Stack Overflow community: https://stackoverflow.com/questions/tagged/rundeck
Github: https://github.com/rundeck/rundeck/issues
Twitter: https://twitter.com/Rundeck
Facebook: https://www.facebook.com/RundeckInc/
LinkedIn: www.linkedin.com › company › rundeck-inc
This slide deck is about the production-readiness of software. First it explains why production-ready is more important than just feature-complete.
Then it takes a quick detour to DevOps. It explains the core ideas of DevOps and how this talks relates to the concepts of DevOps (by simulating the feedback loop from ops to dev while the wall between dev and ops still exists).
After this detour the needs of the administrators from the ops department are briefly described and the challenges that arise from that for developers who want to provide production-ready software.
Based on those challenges a selection of design principles are described (mostly in terms of topics to take care of in the design and implementation process). While not being complete by far, taking care of the topics described on these slides are a huge step towards production-ready software based on my experience.
Of course all the information from the voice track is missing, it is slides only. Even though the slides just carry a fraction of the information, I hope they will still contain some good pointers for you that help you to create better production-ready software.
Driving application development through behavior driven developmentEinar Ingebrigtsen
This document discusses Behavior Driven Development (BDD) and how it can be used to drive application development. It introduces BDD, focusing on behaviors of the system rather than tests. It discusses key aspects of BDD like Gherkin, units, test doubles, writing testable code, frameworks like SpecFlow and recommended reading. The overall message is that BDD changes the way software is developed by shifting the focus to behaviors and improving collaboration.
Design patterns for efficient DevOps processes - Rebecca Fitzhugh - DevOpsDay...DevOpsDays Tel Aviv
The document discusses design patterns for efficient DevOps processes including value stream mapping, release engineering, test automation, and change management. It provides recommendations such as collecting current state information directly, ensuring release engineers understand intended deployments, automating error-prone steps, centralizing test coordination, and making change management a priority integrated within the DevOps pipeline. Design patterns that increase efficiency include continuous delivery pipelines, testing all levels from unit to integration to functionality, and establishing different change modes to balance speed, quality, and risk.
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.
Integration testing in enterprises using TaaS Anand Bagmar
The document discusses Test as a Service (TaaS), an approach to testing software across different platforms and technologies. TaaS defines contracts that specify tests and parameters. Test frameworks on different platforms implement the contracts. A TaaS server runs the tests by invoking the contracts and returning results. This allows reusing tests across platforms without duplicating code and decoupling test technologies. The approach is applied to testing different versions of Microsoft Outlook across Windows, Mac, Android and web.
Building QA Team that matters for an Agile WorldMaurizio Mancini
Presentation from Quest 2015 - Covers building a new QA Team that matters, how to approach Agile Testing, and how to present the message to renovate your existing QA team for Agile.
DevOpsDays Baltimore 2017.
In high security environments, we are often behind proxies, firewalls or obnoxious corporate policies that disallow access to Github or RubyGems. What gives?! In this session, I will talk about what problems we need to solve to build and manage environments in an offline world and how infrastructure as code is at the heart of making it happen.
Similar to Beyond TDD: Enabling Your Team to Continuously Deliver Software (20)
John Keats wrote "Ode to a Nightingale" in 1819 after the death of his brother from tuberculosis. The poem explores the speaker's desire to escape from the pains and sorrows of mortal life by following a nightingale into the forest and partaking in its immortal song. Through vivid imagery and symbolic language, Keats depicts the natural world as both a place of refuge and source of melancholy as the speaker wrestles with his own mortality in the face of his brother's death. The shifting tones reflect the emotional turmoil of wishing to find solace in the nightingale's song while still being tethered to reality.
SOLID - Not Just a State of Matter, It's Principles for OO ProprietyChris Weldon
The document discusses the SOLID principles of object-oriented design (OOD). SOLID is an acronym that stands for five principles: Single responsibility principle, Open-closed principle, Liskov substitution principle, Interface segregation principle, and Dependency inversion principle. These principles provide guidelines for creating reusable and maintainable object-oriented code by separating concerns and managing dependencies between modules.
The document discusses SOLID principles of object-oriented design. It provides examples of code that demonstrate poor adherence to SOLID and ways the code can be refactored to better follow SOLID. Specifically, it shows how to apply the single responsibility principle, open/closed principle, Liskov substitution principle, interface segregation principle and dependency inversion principle to structure code for flexibility, reusability and maintainability.
This document discusses unit testing practices for SharePoint 2010. It notes that SharePoint objects are difficult to test because they lack interfaces and are sealed classes. It introduces Pex and Moles mocking frameworks that can generate stubs for SharePoint objects using runtime instrumentation. The document demonstrates using SharePoint Mole Behaviors to pre-generate common SharePoint object behaviors. It observes that this approach saves time but behaviors may not be complete and unit tests can run slowly. It recommends building a facade in front of SharePoint and producing consistent behaviors by disassembling SharePoint if necessary.
The document discusses using inversion of control (IoC) and dependency injection (DI) to decouple classes and make them more flexible and testable in PHP. It provides an example of refactoring an authenticator class to depend on a user repository interface rather than a concrete class. This decreases coupling and allows different repositories to be injected. It then discusses using a service container to further abstract object creation and injection of dependencies defined through code or configuration.
The document discusses Model-View-Controller (MVC), an architectural pattern commonly used for web development. It provides definitions and examples of MVC components including the Model, View and Controller. It also discusses how MVC is implemented in various PHP frameworks and the benefits of using MVC, such as improved code organization, maintenance and extensibility. Popular PHP MVC frameworks mentioned include CakePHP, Symfony, and CodeIgniter.
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
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.
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
GraphSummit Singapore | The Art of the Possible with Graph - Q2 2024Neo4j
Neha Bajwa, Vice President of Product Marketing, Neo4j
Join us as we explore breakthrough innovations enabled by interconnected data and AI. Discover firsthand how organizations use relationships in data to uncover contextual insights and solve our most pressing challenges – from optimizing supply chains, detecting fraud, and improving customer experiences to accelerating drug discoveries.
In his public lecture, Christian Timmerer provides insights into the fascinating history of video streaming, starting from its humble beginnings before YouTube to the groundbreaking technologies that now dominate platforms like Netflix and ORF ON. Timmerer also presents provocative contributions of his own that have significantly influenced the industry. He concludes by looking at future challenges and invites the audience to join in a discussion.
UiPath Test Automation using UiPath Test Suite series, part 5DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 5. In this session, we will cover CI/CD with devops.
Topics covered:
CI/CD with in UiPath
End-to-end overview of CI/CD pipeline with Azure devops
Speaker:
Lyndsey Byblow, Test Suite Sales Engineer @ UiPath, Inc.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
How to Get CNIC Information System with Paksim Ga.pptxdanishmna97
Pakdata Cf is a groundbreaking system designed to streamline and facilitate access to CNIC information. This innovative platform leverages advanced technology to provide users with efficient and secure access to their CNIC details.
Enchancing adoption of Open Source Libraries. A case study on Albumentations.AIVladimir Iglovikov, Ph.D.
Presented by Vladimir Iglovikov:
- https://www.linkedin.com/in/iglovikov/
- https://x.com/viglovikov
- https://www.instagram.com/ternaus/
This presentation delves into the journey of Albumentations.ai, a highly successful open-source library for data augmentation.
Created out of a necessity for superior performance in Kaggle competitions, Albumentations has grown to become a widely used tool among data scientists and machine learning practitioners.
This case study covers various aspects, including:
People: The contributors and community that have supported Albumentations.
Metrics: The success indicators such as downloads, daily active users, GitHub stars, and financial contributions.
Challenges: The hurdles in monetizing open-source projects and measuring user engagement.
Development Practices: Best practices for creating, maintaining, and scaling open-source libraries, including code hygiene, CI/CD, and fast iteration.
Community Building: Strategies for making adoption easy, iterating quickly, and fostering a vibrant, engaged community.
Marketing: Both online and offline marketing tactics, focusing on real, impactful interactions and collaborations.
Mental Health: Maintaining balance and not feeling pressured by user demands.
Key insights include the importance of automation, making the adoption process seamless, and leveraging offline interactions for marketing. The presentation also emphasizes the need for continuous small improvements and building a friendly, inclusive community that contributes to the project's growth.
Vladimir Iglovikov brings his extensive experience as a Kaggle Grandmaster, ex-Staff ML Engineer at Lyft, sharing valuable lessons and practical advice for anyone looking to enhance the adoption of their open-source projects.
Explore more about Albumentations and join the community at:
GitHub: https://github.com/albumentations-team/albumentations
Website: https://albumentations.ai/
LinkedIn: https://www.linkedin.com/company/100504475
Twitter: https://x.com/albumentations
“An Outlook of the Ongoing and Future Relationship between Blockchain Technologies and Process-aware Information Systems.” Invited talk at the joint workshop on Blockchain for Information Systems (BC4IS) and Blockchain for Trusted Data Sharing (B4TDS), co-located with with the 36th International Conference on Advanced Information Systems Engineering (CAiSE), 3 June 2024, Limassol, Cyprus.
12. Overview
• No code or demonstrations
• TDD in your current environment
• Continuous Integration
• Continuous Delivery
• Is it worth it?
• Your next steps
33. using System;
namespace BeyondTDD
{
public class StringUtils
{
/// <summary>
/// Strips double quotes from the provided <paramref name="sourceString" />.
/// </summary>
/// <param name="sourceString">The source to strip quotes from.</param>
/// <returns>A string without quotes.</returns>
public string StripQuotes(string sourceString)
{
if (string.IsNullOrEmpty(sourceString))
throw new ArgumentNullException("sourceString");
return sourceString.Replace('"', string.Empty);
}
}
}
34. using System;
namespace BeyondTDD
{
public class StringUtils
{
/// <summary>
/// Strips double quotes from the provided <paramref name="sourceString" />.
/// </summary>
public string StripQuotes(string sourceString) {
if (sourceString == null) {
throw new ArgumentNullException("sourceString");
}
return sourceString.Replace('"', "");
}
// Look at all the spaces, ma!
}
}
35. using System;
namespace BeyondTDD {
public class StringUtils
{
/*** I had to change this method cause I'm a n00b.
public string StripQuotes(string sourceString)
{
foreach(char c in sourceString) {
if (c == '"')
{ sourceString[c] == ""; }
}
return sourceString;
}
*/
// comments? what comments? this makes sense, right?
public string StripQuotes(string sourceString)
{
if (sourceString == null)
{
//throw new ArgumentNullException("sourceString");
// I <3 Exception more than anything else.
throw new Exception("sourceString");
}
return sourceString.Replace('"', "");
} } }
36. I will hunt you down and shoot you like a duck dog.
44. CI is a Practice
• Integrate now, and frequently, rather than
at the end of development
• Smaller surface area for integration
problems
• Devs can rapidly fix when they occur
• Reduces “Integration Hell”
48. What do you need?
Build Server Accessible by
Source Control
Entire Team
Your Shell Scripts
Commit to
trunk / master / mainline
often
49. What do you need?
• Automate your build
• Manual steps increases risk of failure
• Make your build self-testing
• Writing unit tests is not enough
• Must be able to execute tests with a
single command
64. “Fail Fast”
• Every commit (to the trunk) should be
built
• Keep the build fast
• Notify (and make visible to) the entire
team
• Intrusively notify the team of failures
• Make sure to fix the build after it’s broken
68. Other CI
Considerations
• Repeatable & reliable
• Should be able to run the same build
process locally
• Break up large testing suites
• Remember, “Fail Fast”
96. Incomplete Features
• Sometimes a feature is just too big
• Incomplete features across releases
97. Incomplete Features
• Sometimes a feature is just too big
• Incomplete features across releases
• Ship it anyways!
98. Incomplete Features
• Sometimes a feature is just too big
• Incomplete features across releases
• Ship it anyways!
• Beware the Beta
99. Incomplete Features
• Sometimes a feature is just too big
• Incomplete features across releases
• Ship it anyways!
• Beware the Beta
• Solution: Feature Toggles
105. Clear the Delivery Path
• MVP helps to make the team think about going to
production as soon as possible
• Deal with Production Gates
• Work to cut, simplify, or work around
organizational red tape
• Find “creative solutions” that satisfy everyone
while emphasizing the business goals
116. Deployment for
Products
• Windows Installers
• Built-in, InstallShield, Wise,VISE, etc.
• Installer (Mac OS)
117. Deployment Quality
• Important to establish trust
• End-to-end functional tests become more
valuable
• Behavior-Driven Development helps to
realize this
• Other quality metrics become just as useful
• Performance, compatibility, security
118. Deploy
• When you’ve deployed, have automated
smoke tests validate a successful
deployment
• If something’s wrong:
• Turn off the feature or rollback
• Don’t “hack” a fix
120. Is it worth it?
• By removing barriers, rehearsing, and
continuously improving the release
process, the risk of a release is reduced
• Becomes a regular occurrence rather
than a traumatic procedure
• Everyone is involved in making the release
process more automated & efficient
121. Is it worth it?
• Feedback determines the viability of your
feature
• Increases confidence when it’s right
• Decreases cost when it’s wrong
122. Moving Forward
• Identify a single task
• Something that is particularly time
consuming and/or painful
• Automate the task
• Start collecting metrics
• Build team confidence
123. Moving Forward
• You need to talk to the business
• Ask these questions:
• Would you like to set the release schedule?
• Would you like to minimize risk during deployments?
• Would you like to maximize investment on features
our customers really want?
• Be sure to alert them of the up-front investment
required!
124. Moving Forward
• Need help?
• After the talk, or after hours party
• askanagilist@improvingenterprises.com