Any suggestions on code review and similar coding practices with losant flows?

Hi all,

I am a software developer and really like losants workflows but am looking for some best practices that I normally follow when developing software in teams when using tools like github/bitbucket/etc.

How do people implement code review and release practices? Are there any articles or examples on how to collaborate as a team on losant workflows? I have seen the versioning in the application workflows, and that I can tag a version as the “default” version. So what I can imagine doing is

  1. The version that we are working on, is the develop version
  2. If a version is to be released, mark that as the “default” version, so its used by default. Does that make sense? Can we work on a flow while an earlier version is the “default” (production) version?
  3. And then once a developer works finishes a new version of a flow before it’s “released”, how can you practically implement code review of that flow. The only way I can see at the moment is to put “notes” in the flow, and code comments in the code boxes. But there is no “commenting” functionality in losant workflows, right? So there is no easy way to see for a developer that I left comments and where. And no easy way to reply. The only real solution I see is that I have to make notes elsewhere, and then face2face review it with the developer. That isn’t very conducive to remote/async work. Are there any other interesting suggestions on how to ensure quality on losant flows?

Cheers,

Dolf.

Hello @Dolf_Andringa, and welcome to the Losant Forums.

How do people implement code review and release practices? Are there any articles or examples on how to collaborate as a team on losant workflows?

I would check out our How To Use Import Features to Manage an Application Development Lifecycle guide, which talks about how to set up different environments (staging vs. production applications) and how to use the import/export features to facilitate a development lifecycle, where changes are made and verified on the staging environment before being promoted to the production environment. Setting up this would supplant the other versioning features within Losant - experience versioning, application workflow versioning, etc.).

Some users do bring Git into this flow also, where they export their changed application, unzip the contents, and commit them to a private repo. While that does allow for comments, release tags, changelog, etc., it is only slightly useful as a code review tool as dashboards and workflows are the kind of thing you just have to see to really understand. (Their configuration by itself is difficult to parse without the benefit of the Losant UI.)

Hopefully this helps. Let us know if you have any other questions, and again, welcome to Losant!

Hi Dylan,

Sorry for the slow reaction. I was out last week. Thanks for the response. That page does help a bit. Making separate applications and using the import/export does give at least a way to maintain separate copies of dev/staging/production and push from dev->staging->production. But it does sound like quite a manual and error-prone method. And it doesn’t provide any review system. As you say, reviewing the raw YAML files while you never write them manually, so don’t really know the syntax, is quite hard.
What I would like to see is

  1. Preconfigured import/export jobs where the settings are fixed, and the source and destination applications are also fixed. That would allow a deploy flow where you can just click a button to deploy your dev to your staging, and staging to production. To keep it flexible, I wouldn’t introduce the words dev/stg/prod so users can also choose to skip the staging step, or have other names for the applications, but just a preconfigured set of import/export parameters, and a source and destination application.
  2. Lock an application from making manual changes. This would solve both unintentional mistakes of changing the wrong workflow, and under time pressure, fixing a bug in production directly, but not having that change in dev, and running the risk of undoing it with the next version. That is a recipe for disaster wen not all applications are forced to be evolutions of each other.
  3. Provide some kind of discussion/commenting feature in workflows, so we can easily leave comments on workflows, and have discussion threads. Even if this isn’t based on changes between version, but just on comments in places in the workflows with threads, that at least provides a way to comment and discuss
  4. It would be really cool if you could also visualize differences between versions. Maybe by having a diff between yaml files, and interpreting and visualizing that in the losant UI. At that point, integration with git (any provider) might be the most interesting, where import/export dry-run becomes a pull request, changes to a flow become a commit, and visualizing changes is done through parsing the git diffs. But that is probably a LOT of work.