Jenkins and the Future of Software Delivery
•
1 like•345 views
For Jenkins User Conference Israel 2016.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (8)
Similar to Jenkins and the Future of Software Delivery
Similar to Jenkins and the Future of Software Delivery (20)
More from Anton Weiss
More from Anton Weiss (20)
Recently uploaded
Recently uploaded (20)
Jenkins and the Future of Software Delivery
- 1. Jenkins and the Future of Software Delivery Ant Weiss twitter: @antweiss Otomato - http://otomato.link
- 2. > whoami: “Ant Weiss” • Delivering Software since 2000 (Y2K bug) • Previously @: AT&T,BMC,Comverse,n+ startups • Principal Consultant and CEO @Otomato • CI/CD/DevOps Evangelism & Enablement • Technical Training Enthusiast • Jenkins TLV Area Meetup Organiser • In love with the future. http://otomato.link
- 3. The Future: “The best thing about the future is that it comes one day at a time.” ― Abraham Lincoln
- 4. The Future: Continuous Delivery is about building software for the Future
- 5. The Future??? •We can’t predict the future •We can calculate the odds •It’s a percentage game •We can’t avoid predicting the future •Focus on the large trends
- 6. The Past of Software Delivery: • Co-located Teams • No VCS -> Centralised VCS • Manual Integration • No QA! }8-0 -> Manual QA • Waterfall • Monolithic architectures • Devs Vs. Ops
- 7. The Past of Software Delivery: • Punchcards • Floppy disks (save -> ] • ISO images • Custom Installers • Bare Metal/Big Iron/Distributed Systems • Manual Configuration Management • Synchronous IPC • Focus on: Reliability/Stability ( Past ]
- 8. The Present of Software Delivery: • Geo-Distributed Teams • Distributed VCS • Continuous Integration/Delivery • TDD • Microservices • Agile • DevOps!!!
- 9. The Present of Software Delivery: • Clouds!!! • Virtualisation • [I/P/S]AAS • Infrastructure as Code • Package Managers • Containers • Service Discovery • Message Queues • Mobile Devices
- 11. The Present of Software Delivery: JAVA JAvaScript C++ Rust Go Ruby Erlang Node.js Python Perl Scala Groovy Lisp Android Swift Objective C C# iOS Windows Bash Puppet Chef Ansible SaltStack Jenkins TeamCity GitBazaar Travis RedHat Atomic CoreOS Docker PHP Mesos Kubernetes CloudFormation Terraform Cloud Foundry Openshift Openstack Ubuntu LXC Rocket Nomad Consul gulp Zookeeper Kafka Hadoop Spark Elastic Search YAML CSS Redis MongoDB MySQL Cassandra CouchDB Django Play ZeroMQ etcd Angularreact.js Hive hazelcast webRTC
- 12. The Present of Software Delivery: JAVA JAvaScript C++ Rust Go Ruby Erlang Node.js Python Perl Scala Groovy Lisp Android Swift Objective C C# iOS Windows Bash Puppet Chef Ansible SaltStack Jenkins TeamCity GitBazaar Travis RedHat Atomic CoreOS Docker PHP Mesos Kubernetes CloudFormation Terraform Cloud Foundry Openshift Openstack Ubuntu LXC Rocket Nomad Consul gulp Zookeeper Kafka Hadoop Spark Elastic Search YAML CSS Redis MongoDB MySQL Cassandra CouchDB Django Play ZeroMQ etcd Angularreact.js Hive hazelcast webRTC variety
- 13. The Present of Software Delivery: JAVA JAvaScript C++ Rust Go Ruby Erlang Node.js Python Perl Scala Groovy Lisp Android Swift Objective C C# iOS Windows Bash Puppet Chef Ansible SaltStack Jenkins TeamCity GitBazaar Travis RedHat Atomic CoreOS Docker PHP Mesos Kubernetes CloudFormation Terraform Cloud Foundry Openshift Openstack Ubuntu LXC Rocket Nomad Consul gulp Zookeeper Kafka Hadoop Spark Elastic Search YAML CSS Redis MongoDB MySQL Cassandra CouchDB Django Play ZeroMQ etcd Angularreact.js Hive hazelcast webRTC diversity
- 14. The Trends: •Centralization -> Distribution •Manual -> Automated •Long-term -> Short-term •Synchronous -> Asynchronous •Uniformity - > Diversity •Stability -> Velocity •Order -> Chaos
- 15. The Future: Continuous Delivery is about dealing with Chaos
- 16. The Trends: Organisational Technological organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations — M. Conway[3]
- 17. The Future of Software •Machine learning •Augmented Reality •Data Gravity/Data Mining •IoT •Self-driving vehicles •Singularity
- 18. The Future? •Self-Organising Non-biological Intelligence with Nonlinear Communication Patterns
- 21. The Future of Software Delivery •Computers writing the Code •From non-human Gatekeepers to non-human Contributors •From Monitoring to Self-Healing •Advanced Visualisation •New Control Interfaces •OTA delivery to multiple devices
- 22. Communication •Communication enables Collaboration on Massive Scale •Shared Context is the Key •Common Language •Pattern Recognition
- 23. what about
- 24. Machines Write The Code - Jenkins to provide insights and optimisation suggestions - Automatically fix syntax (finally!!!] - IOT - Trigger re-writing and re-testing of SW based on signals from edge systems. - ever more testing and verification
- 25. Machines Talk To Each Other - unified CI language (Jenkinsfile) - SW components describe how they are built - Pattern recognition - Jenkins understands what a project needs - delivery and automation are a part of application (see Chef’s Habitat]
- 26. Advanced UI - visualisation - shuffle stages around, rewire on the fly, version everything - trigger builds based on chat context (not just commands] - emit events to any communication channel - finally - trigger SW deploys by power of thought
- 27. Speed vs. Control 100s deploys a day production issues resolved in minutes zero-time updates can we release machines from our control?
- 28. The Future: If you think in terms of a year, plant a seed; if in terms of ten years, plant trees; if in terms of 100 years, teach the people. Confucius
Editor's Notes
- Hello, dear Jenkins fans! Hello fellow engineers! How are you today? Are you feeling optimistic? Well, you have all the reasons to be - they’ll be serving beer right after my talk! But that’s short term. And what about the long term? Are you optimistic when you look into the future and try to see what it brings? Do you believe in robot apocalypse or the utopia of singularity? Do you think the world will change to the better or to the worse? Or are you just too busy fixing bugs in production and making sure all your systems are running smoothly? I’m asking all these questions because it’s future I want to talk about here today. But first - a few words about myself.
- So whoami? My name is Anton Weiss, but my friends call me Ant. I’ve been building and delivering software since year 2000 (or since the millennium bug, for those who remember)
- Now talking about the future - I love this quote from Abraham Lincoln - “The best thing about the future is that it comes one day at a time.” Because when you think about it - the guy is actually talking nothing other than Continuous Delivery!
- In a way we could say that doing CD is about building software for the future. As opposed to the way we used to deliver software previously - that was all about the past.
- Now - this is the point where the sceptics among us will say that this whole ‘future’ blah-blah is pretty much senseless. In fact - historians have proven time after time that we can’t really predict the future. History is too complex and non-linear, there are too many factors. Moreover - history is a chaotic system of second order - it gets impacted by our predictions, but - in an unpredictable fashion. :) Nevertheless - financial analysts have taught us that we can calculate the odds, we can estimate the probability and make a couple of bucks in the process. And most importantly - we can’t really help trying to predict the future - because forward is the only direction we can be going and we need at the very least an illusion of control over our faith. So what can we do? Well, common sense says: focus on large, slow-moving trends and you have a good chance to understand where it all is going. At least until the brits suddenly decide to leave the european union and explode the whole thing.
- How do we identify the trends? We look at the past and compare it to the present. So what did we have in the not so distant past? First let’s look at the delivery processes and methodologies.
- Now tools-wise. How did we deliver our software to the end users and target systems? So first we had punchcards, then we had floppy disks, that are probably staying with us forever in the form of the ‘save’ icon. I had to explain my kids recently why this is how the save icon looks - because they never saw a floppy disk in their whole life. Then we had caroms and ISO images and all types of custom installers. And we had all the big and heavy concepts: bare metal, big iron, mainframe and then distributed systems became all the buzz. And all the configuration was managed manually with main focus being stability and reliability of the systems we’re running. As I said - it was all about preserving the past, not about moving into the future, or even staying in sync with the present.
- But - a lot has changed in the last decade! Now we predominantly have geo-distributed teams, distributed VCS systems, CI/CD have become the industry golden standard. Even if we’re not doing it, we at least know that TDD is a good thing. We’re breaking up our monoliths into micorservices, we’re containerising our apps, we’re being agile and we believe that dev and ops can live together in harmony.
- And we have the technology to support all of these: we have cloud computing, virtualization, we have fifty shades of AAS, we have the tools to manage our infrastructure as code, we have great package managers and binary repositories (thank you Frog!), we have containers and service discovery and mobile devices so we can be connected anywhere.
- Hell, we ourselves have changed. Instead of being specialists in our won field we are now expected to be full-stack whatever. Or even better - the T-shaped professionals. You know where we have the wide knowledge throughout the stack and deep knowledge in some specific field of expertise.
- Now this wide knowledge has to be freaking wide. Because we’re not actually talking one stack. We’re talking dozens or even hundreds of stacks. In fact there’s one thing I’m totally certain about when I look at the future is that we’ll continue having even more variety.
- By the way - the trends we’ve outlined are occurring in parallel in the way we build our organisations and in the way we build and deliver our software. All in line with the proverbial Conway’s law.
- So we looked at our past and our present, and we see there are certain trends. But what do we know about the future? How do we see the future when looking at it from today? Well we definitely know that machines will continue learning, we know that our reality will become more and more augmented, we’ll continue genreating, shuffling around and mining our data in a hope of understanding new things about the world and our society. We’’ll have internet of things with with our coffe machine asking our fridge to pass the milk. We’ll be riding around in self-driving vehicles, we’ll be controlling machines with the power of thought and we’ll have nano-bots circulating in our blood stream to make sure we stay healthy and well.
- Or to summarise it all - we’ll have the world swarming with self-organising non-biological intelligence with non-linear communication patterns.
- That was about machines - but what about humans? We’ll definitely also see ourselves evolving from T-shaped professionals into n shaped, m shaped, and octopus-shaped professionals.
- Now how does all this relate to software delivery?
- Now the key to many of these changes - both in how we interact with each other and in how our machines interact with us and each other lies in communication. The medium becomes the message as communication enables collaboration on massive scale. You know they say the arab spring was brought on by the new channels of communication. And for effective communication - shared context is the key. We need to be speaking a common language and share the same abstractions. Or at least have a way to recognise each other’s patterns.
- Are you already envisioning the future. Or just waiting for that beer? Whatever it is - let’s not forget why we are here today. We’re all here because of Jenkins - because we have this great open source project which allows us to be both its users and creators. Because this is a project we can actually take into the future - help it become whatever we want it to be. So let’s think what we can do with Jenkins in order to continuously deliver the future.
- Now all this is great. It’s a vision to follow, but until that happens - we all have a lot of code to write and a lot of problems to solve. And to do that in an efficient matter - we need to continue learning and teaching. After all - the future can never be better if we don’t learn from the mistakes of the past. Before machines can dance we need to grow the humans who can teach them how to dance. That’s the reason we’re having conferences like this one, that’s why we’re giving answers on stack overflow and hold meetups. And this is a great occasion to invite you all to sign up for the Jenkins Tel Aviv Area Meetup Group and start sharing your knowledge for the brighter future of software delivery.