Video recording and production done by DevOpsDays.
From a QA performance point of view how to integrate performance testing in each of the steps of life product cycle, from developers to production. How to integrate Performance engineering tasks in Kanban and in daily tasks of DevOps team.
I will speak of the Past, Present and Future of Performance Engineering within devops. It is interesting as it is one of the requirements from the market to be competitive. Performance is really important in marketing trends and it is a task that depends not only in developers and QA but as well it relies in the system, perfectly fitting DevOps tasks.
The presentation has been given already in Oslo for Pearson with a telefónica Case of Study so it is not only a theoretical PoV but a practical daily task.
At some point a startup needs to grow, without losing agileness. It needs well-know processes. It needs developers to know about the infrastructure. It needs tools that expose knowledge, not that hide it. It needs scalable wokflows, based on self service tools, so system admins and release managers are not a bottleneck for developers. It needs tools that enforce processes, not tons of documentation.
So we implemented and put to work some systems to allow developers to do that:
-Tuenti-in-a-box: Private, replicable, virtualized development and testing environment, with all the features production platform has. No more shared development environments.
-Configcop: Test your application config changes in your development environment, promote it to staging and then to production. Easy, safe, and logged.
-Flow: Development, integration and release management of code made easy. Promote your own code to main integration branch, build and deploy it, release it, all pressing a button from your preferred ticketing system. Of course transparent information, traceability, stats.
All these tools are developing devops culture inside the company, making easy for developers to deploy and test their code, providing information about all stages and ensuring higher code quality by automating testing and other tedious, risky tasks, such as code versioning, tagging, build and distribution to app markets, etc. We would like to share how this ideas and tools helped in Tuenti's development processed, and allowed us to go from 2 releases per week, with multiple hotfixing in a single project, to a multiple project, multiple releases per day, reducing workload and time that code spends ready but unreleased from some days to some minutes.
The aim is to explain the long and difficult way done in a classical and quite normal IT department in a classical company towards the DevOps philosophy. We would like to present in a few slides: * why we MUST go to DevOps (from a technical and organizational point of view) * What we practiced as technics and different improvements * Which learning way we used, based on agile practices, * The effort done by the people to destroy existing communication and collaboration barriers * What we would like to reach as level in the next months / years
A framework aimed to cover the gap between single agile teams (scrum+something is enough) and traditional IT shops (Prince2/PMBOK/CMMI/ITIL...).
One of the big values of DAD is that is "enterprise enabled" meaning that its proposed lifecycle, goals and roles can be understood and accepted by a medium-to-big IT department. If we consider the change management issues we could find in transitioning such IT departments to DevOps then DAD becomes of a great help.
In short, the presentation would talk about: * Defining Disciplined Agile Delivery (DAD) * Hybrid framework * Lifecycles * Roles * Process goal driven * Enterprise awareness * Scaling and tailoring * Governance
What about DAD and DevOps?
- What is the role of QA/Tester in devops
- How do we integrate QA in the continuous delivery process
- The impact devops has on traditional security/auditing/change control
- How does devops co-exist with ITIL, Cobit
- How about release management ?
- Help prove that devops can scale beyond the 5-8 person web startups, we love traditional IT enterprise cases With all the automation, data is still a hard thing to handle, how does it affect, DBA's, backup strategies, ...
- How to involve the business in devops
- How to get YOUR boss involved, how do you make the business case
Referencing recent unique global market research that surveyed 1200 respondents, this session discusses the levels of DevOps awareness and the varying rates of DevOps adoption across 12 European countries, and how this compares with the US and China for example. This is followed by a deep dive into the varying business drivers, tools vs training vs hiring priorities, how DevOps is being measured (internal vs external KPI's), and the measurement of benefits experienced by organisations that have already started with a DevOps approach. How do these findings compare with your experiences locally? Comments from delegates are welcomed as we hope this will be an interactive and lively debate.
What do you really need to reach Continuous Delivery? You can achieve this based on best efforts, but this does not scale, since time is not infinite. How can you evolve your company to reach it? Avoid the enemies Continuous Delivery:
- Manual testing
- Unstable tests
- Execution time of tests
- Lack of automation (processes and tools)
- Lack of visibility of other's work Bad communication
- No clear responsibilities