Continuous Delivery

I had the luck (and I say this considering the number of talented engineers within Shine) of attending AWS re:Invent in Las Vegas recently.For those who don't know, re:Invent is an annual conference held by AWS. It's a chance for customers, vendors and AWS staff...

Adobe Experience Manager (AEM) is an enterprise web content management system that, like many other enterprise applications, is a complex piece of software to set up and configure.We can't eliminate this complexity completely, but we can reduce it for many use-cases. AEM OpenCloud is an open source project being led by Shine Solutions that automates the setup of a complete ready-to-use AEM environment in the cloud within 15 minutes.However, testing and verifying that an AEM installation is working correctly is laborious and time-consuming. Done manually, testing can certainly take longer than the 15 minutes required to actually build the environment in the first place.Fortunately, automated testing was identified early on in the project as an important part of OpenCloud's modular design, as is made clear by this diagram created by Cliff Subagio, one of the project founders:AEM OpenCloud suiteHowever, it's one thing to say that testing is important, it's another thing to actually do it. In this post I'll talk about why and how we used InSpec to implement automated testing in OpenCloud.
I was lucky enough to have the opportunity via Shine recently to attend the inaugural OWASP AppSec Day 2018 (Melbourne) at RMIT. Security professionals from around the globe gave some insightful talks into the state of secure application development in 2018. In this post I'll share you some of the key insights I gained from these talks.
Anyone who has delved into CloudFormation knows its power for describing and managing your cloud infrastructure within AWS. Likewise, if you've spent any time writing CloudFormation templates of any significance you'll know that you'll spend a lot of time duplicating sections of templates.We always aim to reduce repetition in code so this can be a bit grating.In this post, I hope to explore a few technologies that can help with this, primarily a tool called Sceptre from Cloudreach.

No food reviews here I'm afraid

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.

1_5_3_1_Chicken_EggWe 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:
  • "How are we going to develop features in isolation?"
  • "How are we going to separate release candidates from ongoing development?"
  • "How are we going to deal with hotfixes?"
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.

javaone_2

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.