Infrastructure as code

As a release engineer, I design/develop automation to serve core responsibilities when appropriate, and create/Enhance internal automation tools on demand for development/QA and IT teams. Like, automated tools to log bugs, parsing logs, fixing build issues, machines issues, build scripts, tools to maintain source codes, generating reports, etc. I love this job as it help improve the productive of the organization. I found a very interesting post ‘How Infrastructure Engineers are like Drug Pushers‘. In the post, the author said, an infrastructure engineers are just like Drug Pushers. 🙂

Here are their ‘evidences’.

Drug Pusher Infrastructure Engineer
The product can be addictive The tools can be addictive
Users rarely admit we exist Developers rarely admit we exist
Users don’t talk about us openly Developers don’t talk about us openly
The product make most users feel good The tools make most developers feel productive
Users go nuts without the product Developers go nuts without the tools
Users would like these supplies to be free Developers expect these tools to be free
When the product doesn’t work for them anymore, they expect new products that work exactly like the old products, but better When the tools don’t work anymore, new tools are expected, but they must work exactly like the old tools, but better
When the users are under the influence and happy, nothing else matters When the developers are happy and everything is working fine, nothing else matters

The tools can be addictive — In my current company, release team provides tools to manage the dual checkin of source codes. Yes, they love our tool. — They raised more than 30,000 requests in the past year! 🙂 How could we image if they or release team have to do these tedious jobs manually?

Developers rarely admit we exist — Bloody true. Release engineers are not coding for customers (We are coding for developers). Okie, so many people might think, “Release enigneers are not generating profit.” — Too bad. 😦

The tools make most developers feel productive — ASA developers check in codes into repository, it will trigger a checkin build and it will provide feedback quickly. That makes our developers be more confident in their codes and improve their productive. Our tools also help them just focus on programming.

Developers go nuts without the tools — Hahaah, can anyone image that, without the support of release engineers, dev could focous on their programming?

Seriously, let’s come back to the topic ‘Infrastructure as code‘.

In post Concise Introduction to Infrastructure as Code, it has a well defined of what is Infrastructure as Code,

The end goal of infrastructure as code is to perform as many infrastructure tasks as possible programmatically. Key word is “automation.”

Yes, Automation Automation and Automation. Automate Everything if those steps are reproducible. Server configuration, packages installed, dependencies managements, automated testing, reports, build artfiacts, deployments, bugs managements, etc. All of them should be automated and remove all of the manual steps prone to errors. Computers won’t do things wrong unless engineers provides them wrong directives.

I believe that every build team has a lots of internal automated tools work separately. I think we can move further and integrate them into a basic infrastructure platform and unify the data input/outputs (generally, the data is, change set/list, bugs, and build artfacts). We should see infrastructure as a single target and should not treat them separately, like IT, DevOps, QA, Build, Release, and Supports. Ideally, the data flow should be,

a new bug triggered automatically-> notify QA/DEV -> Verified by QA/DEV-> provides environment to QA/DEV to debug-> checkin code-> build the new code-> code quality -> dependencies and changes reports-> deploy new code-> notify QA/DEV the result-> passed -> includes into the build cycle.

In above steps, they should be automated as much as possible.

Yes, it is easier said than done! But as we have already known the direction, ASA we decide to go, we can achieve the goal ‘automated everything’ one day with our hard working!