Doing it properly

in ,

When I begin working on Project Rhea, the first thing I remind myself is to do it properly - proper infrastructure, using the tools I pick in the proper way, defining a proper development procedure and only release application with proper testing.

With the project now gone through a couple of sprint, I am seeing "proper" a little differently.

I start off the project with the installation and configuration of Jenkins, which soon I told myself, "Wait a minute! Provisioning and configuration should be automated!" So I steered away from Jenkins to Puppet. And I realize it is a beast quite hard to tame (I will leave it on why I say so in another article) but anyway, I have finally get some configuration written. From there, I realize another thing - I should have the configuration versioned and now I need a GIT server. So there you go, I dropped everything and start working on GIT installation.

Do you still remember what is my original intent? Jenkins installation. But instead of working on Jenkins, I am now dealing with 3 different other things!

All the tasks I mentioned are proper things that should be done but none would resolve my immediate needs - I want to setup a CI server and get a feeling on what it is, how it should blend into our development process.

What's more, the split hinder you from getting the feedback you need and the struggle give you stress (as nothing is achieved), instead of satisfaction.

So here is my first challenge - balancing immediate needs, against taking the time to pave the foundation.

Now with the barrier of adopting Puppet been overcome, the amount of configuration defined start to grow, too. Also, I begin to define the Jenkins pipelines and I am struggling if I should use a single pipeline for all instances or one pipeline for each.

And here comes another challenge on "proper" - am I doing the changes properly?

These conflict lies in the struggle of doing both things on the same environment. And the way I resolved this is, I pulled up a throw away environment so that I could fast track in getting the information I need, while at the same time, I can refine my plan and decide the tasks that needs to be taken. With free starter plan from AWS or Azure, it costs nothing to do experiment. In later stage of my project, I extent this throw away experimental approach to other things as well. For instance, instead of defining the puppet configuration for packages or changes right away, I will first experiment on the sandbox and only until I feel "this is it!", I will then put the changes back into Puppet as configuration.

One day, I came across an article written by an engineer in Google (https://conf-slac.stanford.edu/xldb-2013/sites/conf-slac.stanford.edu.xldb-2013/files/JDean.pdf), talking about the infrastructure development history in Google. It inspired me with my new principle. 

Nothing is final, we can always revisit and refactor as needed. If the Puppet conf growth t oa point of losing control, we refactor.If we rolled out a pipeline that didn't work for the developer, we go back and tune. The flip side of this appraoch is, we got a more concrete statement on what is wrong and what issue to tackle.

Lastly, I want to share with you on how I am seeing "proper" now. Proper, to me, is a state of mind. What is proper depends on what is needed now. Also, don't be afraid of change. Re-define when you feel you are diverting from your original intent.