Salesforce DX? Continuous Integration? Source Controlled Development? Where to start??
Salesforce has recently introduced it’s new Developer Experience (DX) as of October 2017. The purpose of DX is summed up very nicely on the DX homepage
“Welcome to the modern developer experience that will change the way you build Salesforce applications. Whether you’re an individual developer or working in a large team, Salesforce DX provides you with an integrated, end-to-end lifecycle designed for high-performance agile development. And best of all, we’ve built it to be open and flexible so you can build together with tools you love.”
Let’s break this down.
“Do we (still) need QAs?”
… and flavours thereof, is a question I have been hearing for years now.
The same has been asked of Tech Leads, Operations Engineers, “Front End” devs, “Back End” devs, Security, Iteration Managers/Scrum Masters, Business Analysts, etc. Anything that is not a full-stack dev. The #NoOps conversation is interesting research material.
It seems to me that this question stems from a misinterpretation of agile and lean startup materials.
Idealistic hopes of cutting costs, removing waste (and blindly classifying some roles as such), delivering faster, etc., have caused some to think that role specialisations can all be generalised into being “Engineers” and that we can all self-organise and just do it all.
DevOpsGirls started a year ago with a bunch of enthusiastic REA people who wanted to make a difference in diversity in Tech, particularly with women who are interested in DevOps.
After running two highly engaging bootcamps we have been discussing a lot about what’s next for this initiative. REA has been an amazing incubator of the idea and has provided everything that we needed so far to kick-start the movement, but among the organisers we had a feeling that if we wanted to reach the next level we needed bigger support from other individuals and organisations. That’s difficult to do if it’s attached to a single sponsor. With the great response we have had from the industry and the beautiful experience of having external coaches joining the previous boot camp has help us determine the next step.
And so — I am super happy to announce that DevOpsGirls will become part of DevOps Australia – an organisation well know for running conferences like DevOps Down Under! Thanks to Matt Jones for the support and we really believe this is a step in the right direction and would help DevOpsGirls operate in a more effective way.
Only 6 months has passed since our inaugural DevOps Girls bootcamp and on Saturday 12th of August 2017 we had the pleasure of running the second edition. For those new to the bootcamp: it is a free event for women interested in learning more about devops, run by a community of passionate volunteers.
The idea started with a realisation that unless we are proactive about diversity in tech and we make meaningful contributions, it’s going to be hard to move the needle on this. The aim of the event is not only to train women but also to create a community of like-minded people who can provide support to each other.
Our first bootcamp went extremely well. From the moment it finished all the organisers and collaborators, apart from being exhausted, were already thinking: when are we doing this again? And of course, we did. We decided to run another introduction to AWS, iterating on the lessons that we learned in the first edition. Continue reading
Deploying a high traffic website with zero downtime is a challenge – there’s a natural tradeoff between:
- Performance and cacheability.
- Getting updates versions of the application live.
The approach you use to manage your static assets plays a big role in this.
This post explains how we dealt with the challenges in our move from the data centre to a multi region highly available cloud-based architecture.
Developers have – with the advent of DevOps – been working more and more in Operations and Infrastructure. Testers however, have not.
Thus far, the testing personnel have been mostly or wholly assigned to application testing work. As SOFTWARE testers, we have only worked on software – and then mostly only on application software.
I pose the questions: What about infrastructure as code? Should that not be explicitly tested?
And: if Testers are meant to be testing the system, why then have they not explicitly been testing the whole system, infrastructure included?
I am going to make a case here for including QA in Operations and Infrastructure, by clarifying how I see the QA fitting in the DevOps world. Continue reading