Continuous Integration

Cloudflare Dev Workshop 2020 In mid-February, I had the privilege to attend the first Melbourne Cloudflare dev event. This was just one of a series of sessions they ran across the country to reach out to developers and help educate people around their thinking and the...

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 suite However, 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.
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 recently had the opportunity to work for a client who wanted to develop what they termed "app indexing". What they meant by this was that they wanted their users to be directed into a specific screen of their iPhone app when they tapped on a particular Google search result. Put differently, they wanted the user to feel as if Google had returned search results specifically for their iPhone app. They also wanted to be able to send out links via email, SMS or other marketing channels. If the app was installed, opening such a link on their phone would result in the user being taken to the relevant points in the iPhone app. If the app wasn't installed then they would just be taken to the mobile website. The way this is achieved is through what Apple refer to as "Universal Links". In this post I'm going to discuss how we implemented Universal Links at a client of ours, some of the obstacles we faced, and how we overcame those obstacles.

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.

Monkey_Office_1A We recently introduced acceptance test driven development (ATDD) at a client. The idea was for the product owners, developers, and testers to work as a team to come up with the acceptance criteria for user stories before development begins. We adopted this approach as an attempt to increase a shared understanding of user stories, as well as a shared agreement on the definition of 'done'. As we introduced more functionality to the application, it became evident that more and more effort had to be put into regression testing prior to a software release. The application has to be supported on mobile (iOS and Android) and desktop (Safari, Chrome, Firefox, IE8 and above). Our team of 2 to 3 testers would spend up to 3 days testing for regressions! In an attempt to reduce the need for talented testers to carry out monkey work, the team began to push for a focus on automated browser-level testing. In this post I will demonstrate the acceptance testing framework we used and describe how the test suite can be tied to a Jenkins build (with a beautiful results page!).