Automation- what does that really mean to us

Ok guys…you have to remember I am just a dumb PM trying to make my place in the world…

Can someone explain to me what we (Tangram) mean when we talk about automation within Tangram Pro. I have heard in a meeting or two that our goal is to automate our code gen or workflow capabilities in the future. What does that mean…how can you automate generation of code if you need new code? And workflows are still a squishy subject to me in general…I assume it just means the order/process of working through software development or engineering. So are we automating a process? A tool? A capability? A feature?

Don’t laugh at my stupidity…and thank you for any answers!

1 Like

I would definitely like to learn the answers to @kyle.traver questions as well…

1 Like

Hi Kyle - thanks for posting. And welcome!

I think there are layers to the automation onion and some of our engineers will have more technical ways thinking about it. From where I sit, I see Tangram Pro as a tool that is trying to automate the interactions of complex systems. For instance, code generation is a plug that when run automatically generates a CSI. The user still has to manually configure the plug-in, but once configured the user does not have to manually write the interface code to connect components. So, we are automating the writing of interface code in this case.

Another layer of automation occurs when that same code gen plug-in is applied to a component and a webhook is set up. Again, the user has to manually configure the webhook, but once done the code gen plug-in automatically runs any time the code changes at the repository level. In this case, through webhooks, we can automate the running of the code gen plug-in, which we call a "workflow’ in Tangram Pro.

In the first example, we are automating the part of the development process by writing the interface code that manages interactions between components.

In the second example, we are automating the interactions between tools, say my GitLab repo and Tangram Pro.

There are other areas of automation we are working toward, such as automated testing or automated transform generation.

The way I make sense of it as that we are primarily concerned with automating handoffs or interactions, whether it be messages between components, or interactions between tools.

I’d love for an engineer to set me straight or elaborate further. Hope this helps!

1 Like

Automation generally means taking a set of steps and running them in some automated fashion. The easiest example would be a deployment of a website to a server. Instead of writing down the steps which may include building the static files, uploading them to a server, maybe invalidating any caches, restarting the load balancer on the server if any configs are changed, etc, we can start automating first by creating a script, often in bash, that does each of these steps for us. Now a deploy to the server is just a script someone needs to run on their machine. This becomes documentation on how the deploy is done but also ensures that anyone can do a deploy without fully understanding it and removes mistakes that can occur from forgetting to do a step or doing a step wrong.

It’s kind of a pain to have to run this script to do a deploy. That means someone needs to be in charge of it or responsible for running the deploy script. Instead of this, why not make the computers do more for us and have them run the script instead. So put this in a pipeline. Here, we use Gitlab CI for this. We can tell the CI to run the script at certain times or when certain things occur, such as a new tag is created in the git repository or a new commit is pushed to master. Now we just interact with git like normal and allow the pipeline to handle all the deployment business. This also ensures the deploy script is put into a git repo to be properly versioned.

We can extend this further by also running tests before/after a deploy. Testing before ensures deploys don’t occur unless a test suite passes. Testing afterward on a live instance of the site can ensure that if any tests fail, we can respond in an automated manner. We can build rollbacks into the CI, meaning if the automated tests fail after the deploy, the new code will be rolled back to a previous version.

This is a simplistic example but can show the power of automating what we can to remove user error and quicker response to issues. The idea is to “shift left” as much as you can. This essentially means do as much as you can in an automated fashion (in pipelines) before actually deploying. This causes bugs and security issues to be caught much sooner and allows us to iterate faster.

In the platform, currently much of the automation is around the generation of transform code. Users can create workflows that take in information about the transforms needed and can create the code and allow it to be downloaded by the user. In addition, we also have the ability to run some fuzz testers and such against existing code. Lastly, we can compile code. Bringing this altogether, we have the ability (with configuration) for users to run a workflow that pulls in new code, generates transform code, runs fuzz testing against the existing code, and then compiles the existing code with the transform code to output a binary that the user can download all from a simple push of new commits to a git repo.


I don’t really know what that means either. My guess is that those kind of comments are getting at what Alex referred to as “shifting left”. That is teaching the computer to automatically do something we are currently asking users to do themselves.

Automation as a term is a funny word when it comes to computers because they’re always engaged in autonomous action following some user action. The early computers could, given two numbers, autonomously act to give you the sum. We figured out how to combine these autonomous additions, subtractions, and so on into classics like Atari’s Battlezone arcade game that would automatically move green tanks around and shoot at you. If you hit a button it would automatically send a shell flying back at the enemy tank. We automated the electro-magnetic manipulations required to display stuff on a computer screen so you can see the tanks move. Since then we’ve gotten better and better at automating this and that to where Siri and the Google assistant can automatically (without my input make an action) to read my calendar and alert me that I need to call into a meeting. All computer action is an automation of something a person once did or at least could theoretically do even if very slowly (manually displaying green tanks via a cathode ray tube would be super tedious). So, to automate anything just means to tell the computer how to do something a person is currently doing.

So, don’t feel bad that the sentence you paraphrased didn’t make sense to you. It doesn’t make sense to me. Automation is all computers do. The key detail left out above is what exactly is being automated about code-gen and workflows. For that sentence to be meaningful, it would need to specify the steps currently required of the user which we will now make the computer responsible for. We don’t “automate” workflows, workflows are already an automation of a previously manual series of steps. “code-gen” is already the automated generation of a code library that facilitates a certain capability. Think of automobiles which autonomously move you around where you used to walk. We don’t automate automobiles. We automate automobile engine ignition via a turn-key, battery, and an electric starter where we used to crank them by hand. We automate automobile steering and braking. We don’t automate automobiles just like we don’t automate code-gen or automate workflows.

I digress. Automation means making a machine (in our case a computer) do something a person is currently required to do.