This year I was incredibly lucky to score a coveted ticket to YOW! in beautiful Melbourne. I was also asked to be a track host for a couple of sessions, so that was quite an honour too. This post is a whirlwind wrap-up of the conference, and only includes my favourite talks from the two day event. If you’re hoping to hear detailed reviews on how the coffee/food/WiFi/venue was, then you’ll be greatly disappointed (it was all great BTW).
A light dew settles on the leaves of the venerable elm trees which track Melbourne’s, St Kilda road. The bulk of the noble Yarra River moves majestically past the Melbourne Convention and Exhibition Centre, as it does every morning unaware about what is about to take place within. Light rail service number 96, which I had boarded at the iconic Luna Park, will carry me on my sovereign journey to the DevOps Talks Conference, 2017.
Yet still, those lingering words circle around my mind, like plastic bags caught in the wind, waiting to be sucked into a stormwater drain. Self-doubt is setting in. Am I clearly delusional?
“You’re going to a DevOps conference? Aren’t you a developer?”
This is something I had been asked on more than one occasion in the lead up to this conference. Each time I’m questioned, I point out that the term DevOps is exactly six characters long, and that more or less fifty percent of those characters are “Dev”. I have at least half a right to be here.
I had the opportunity to attend AWS bootcamp in Sydney a couple of weeks ago. The session I chose to attend was entitled “Securing Cloud Workloads with DevOps Automation”. There were many interesting concepts discussed, all hinging around the new term ‘DevSecOps’. In this post, I’d like to talk about what this is and how it relates to traditional DevOps.
We love Git Flow. It’s awesome to have a standard release process where everybody is using the same terminology and tooling. It’s also great to have out-of-the-box answers to the same questions that get asked at the start of every project. For example:
Now it’s enough to just say ‘We use Git Flow’, and everybody’s on the same page.
Well, mostly. Whilst Git Flow is terrific for managing features and separating release candidates from ongoing development, things get a little hazier when it comes time to actually release to production. This is because of a mismatch between the way that Git Flow works and another practice that is common in large development projects: immutable build artifacts.
We were lucky enough to get an invite to the Google Cloud Live conference this year. Being a private, invite-only event it was difficult to know what to expect, but when you hear Google and Cloud Computing in the same sentence you can’t help but get excited.
As we queued outside the small-looking building in downtown San Francisco the first thing of note was that this was by no means a massive conference – probably less than 500 attendees. With the attendees being a mix of press, partners and developers, I heard one attendee describe it as a “who’s who of cloud computing”.
This year July 24-27 I was invited to speak at the first JavaOne conference held in Shanghai, China. Over the four days the conference delivered a concentrated dose of Java and helped me get a good overview of the current state of Java across all versions. It also showed that the divide between where Oracle thinks Java is going and the reality as I see it day-to-day is getting bigger, with Oracle selling the image of a bright future for Java where I see Java slowly loosing ground against other programming languages.
I work in a team that is constantly faced with the challenge of getting features approved for release into production. This is largely because the business is very fast moving, and business priorities change often. As priorities change, the focus of the business shifts from feature to feature, so resources for testing and approving features can be scarce. Consequently, our trunk codeline contains approved and unapproved features. This becomes a problem during our releases, because unapproved features have to be removed from trunk, which as most developers would know, is a painful process that results in dozens of conflicts.
In this blog I will present a solution to minimise the problems surrounding unapproved features in the codeline at the time of a release. This solution involves having a separate branch that only contains features that have been completed and approved by the business. I will also contrast this approach with popular alternatives like Feature Branching and Feature Toggling.
In my previous post I presented the basics of sharing sessions in a cluster by storing session data in a client-side cookie. In part 2, I’ll talk about the security aspects of this client-side cookie store, i.e. how to protect it from security threats.
To prevent attacks specific to client-side sessions, I’ll add encryption, signing, and session timeout to the code. In addition, I’ll talk about solutions to protect against security threats common to any web application, such as Session Hijacking, Session Replay, and Cross-Site Scripting. The result will be an implementation of the Session-In-Cookie pattern that allows simple and secure session-sharing in a cluster.
This year was my first attendance at the YOW! Conference, and I am very happy I was able to go. The conference was well-organised with great speakers and thought-provoking presentations.
Fascinating to me was that several themes recurred in different presentations at YOW!, with each speaker giving it a unique angle. Watching several presentations from different experts in this conference setting lent itself to a meta-analysis of these themes. One that I found particularly interesting is risk management for software projects; specifically, how development processes can help businesses manage the risks.
The goal of this article is to discuss how improving the automated testing aspects of a continuous delivery project led to dramatic improvements in quality and delivered real business value to a leading bank in Melbourne Australia.
It will cover how the automated testing was integrated into the continuous delivery process to support Scrum, to empower testers and to shorten testing cycles.
