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
DevOps, when done right, usually goes unnoticed. It’s only when something breaks that all eyes turn to IT. If your boss only sees you when the app is down, however, that’s not really doing your career any favors. In this session we’ll talk about how to prove your value to the organization by looking at the positive side – that is, how much money you’ve saved your company. We’ll take a look at how you can use tools like Chef, Puppet, Sensu and Logstash to quantify your value to your company. After this session, you’ll be able to walk into a meeting with your boss ready to talk about your value to the company (and to ask for a raise).
Why devops matters?
Tools of the trade
Chef + Puppet
Logstash + Loggly + SumoLogic + Splunk
Fabric + Capistrano + Jenkins
Sensu + Graphite
Your real value
A case study in the cost of failure
Reactive to production failures
How to win
Maximum Visibility with Minimum Effort
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.
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