Woodside Energy is replacing its continuous integration tools and infrastructure tools as a code, instead of moving to AWS cloud services.

A senior cloud and cloud architect, Luke Evans, told a recent event in Perth that the gas giant was having a "love / hate relationship" with parts of its DevOps tool chain, distinguishing the CI server. / CD TeamCity and its infrastructure tool as a code. Terraform.

"TeamCity builds our packages [and] Terraform is doing our deployments, "said Evans.

"The spoiler alert is that I still love TeamCity and Terraform. I do not think there is a problem with these technologies or these tools. "

However, with both tools in the process of introducing code into the cloud, Evans felt there was room for improvement.

"It's small things," he said.

"There were a few things we had not noticed before … that started to surface.

"Like any team, we want to improve and improve, and we want to evolve the relationship we have with our technology and tools.

"So we wanted to do more, get more value from our tools and add more automation so we do not have to do basic tasks."

Evans said that automating processes was more difficult than necessary.

"The TeamCity API was not really the best and the Terraform Enterprise API was not really better," he said.

"It was like we had a" sticky tape and glue "style architecture. It did not seem right to me.

Evans added that he also wanted to avoid having to use the server used to host TeamCity.

"I do not like managing servers at all; congratulations to those who do it, "he said.

Evans also wanted a solution to the "extremely complex queue of construction of TeamCity", a reference to the propensity of TeamCity users to encounter problems of delay or to optimize the queuing way. that the new code goes into production.

"If you have TeamCity, you'll know [about] that, he says.

"With TeamCity, your licensing power limits you. Because we shared this instance of TeamCity with other teams, it was either our construction blocking them or their construction blocking us.

"We all just want to code. We do not want to have to manage / tweak the TeamCity server. "

Evans also thought that the existing tools were "a little expensive" and that several teams used them, it was difficult to spread the costs.

"As we shared it with other teams, it was difficult to know who had to pay what and who was paying what," he said.

The company is now taking a big step by replacing TeamCity with AWS CodeBuild and Terraform Enterprise with AWS CodePipeline.

The move is progressive. "We have not changed all our components at the same time," Evans said.

"Even now, we still have some components using TeamCity.

"So, it's a trip, but we made the jump to do it."

Until now, Evans said the change had been helpful in reducing costs ("we only pay when our construction is running") and to reduce blockages.

It had also been easier to automate more parts of the process.

"We do not need voodoo magic to assemble pipelines to create this" glue and tape "pipeline, he said.

"We have traded this against CodePipeline, which means that we can run integration tests, performance tests and any other tests or whatever we want to do sequentially or parallel in this pipeline, which makes it easier to l & # 39; automation. "

Evans noted that the transition was still in progress, in part because Woodside was waiting for new features or features to be introduced into AWS tools.

"No relationship succeeds without compromise, and even if we are on the right track to be happy, we will get there, there are some gaps in CodeBuild and CodePipeline," he said.

"For example, versioning is a bit difficult in CodeBuild, but we are simply finding ways to work around it. In addition, the process of canceling in CodePipeline is not quite ideal. It's a bit manual, but we think "The benefits certainly outweigh the disadvantages in our case.

"We are leveraging AWS to improve CodeBuild and CodePipeline. We think it's just a matter of time [before we get to where we want to be]. "