Skip to main content

As a Dev Ops Coordinator I would like a tool which allows central creation of diagrams which "live update" in several places.

Part of the CI/CD Development Series

In order to achieve your goal, you need to a) have one and then b) find the best way to clarify that goal into some tangible medium. Paper and doodling is a great start but eventually those doodles need to be put into a some clear communication format which is accessible to yourself, your team and anyone else who needs to see what you are striving for.

There are several diagrams that go into communicating the plans and specifics of software projects. UML has several diagram listings including Deployment Diagrams, such as the one below, Component Diagrams, Activity Diagrams and more.

This inevitably leads to the multiple problems of
 - How to develop the diagrams
 - How to publish the diagrams in locations which can be referenced by the target audience
 - How to update the diagrams which have been distributed or published.

This last item is probably the most difficult since it is easy to put off publishing the new diagrams until it is "finished" or accidentally overlooking locations where it has been published or distributed.

Many of the online documentation tools allow exporting of diagrams  in various formats including a "live embed" such as the one below. This was created with Lucid Chart ( https://lucidchart.com ). I created a draft of this Deployment Chart and then chose the "embed" option which created HTML for a div and an iframe. After copying and pasting that code into this entry, the chart updates automatically each time that the page loads. Using this approach, I was able to also include this into Confluence in a section called Key Diagrams. We'll discuss the specifics of the diagram in a later post but the immediate point is the live updating of diagram in the key locations to allow accurate and timely information to be communicated.

Comments

Popular posts from this blog

Creating Stories and Tasks in Jira: Personas and our Software Development Team

Part of the CI/CD Development Series The next step is developing who is on our hypothetical development team. Given that it has a React front end and ColdFusion as the Server Side language, I came up with the following personas, all of which have their own needs and considerations for our development environment. I've listed all the jobs that need doing, not the people involved since, even on a small team or a team of one, these "hats" are all worn by someone, even if it's the same person. Personas for our Project Dev Ops Coordinator - The person responsible for smooth and accurate deployments CF Developer - The person responsible for the API and fulfillment code development and maintenance. React Developer - The person responsible for the front end development Database Coordinator - The person responsible for the schema, data, up time and, presumably the testing databases used by the developers. Lead Developer - The person responsible for coordinat...

More on Site Architecture / CI/CD / and Repos

We're starting to move from the high level overview and more into the details of our project.  Architecture We established that we using React as our front end technology and ColdFusion as our server side. At a more granular level, we'll be using React with Redux for our front end app and we want our server side to be not just "ajax" enabled but a true REST API. To this end, we're going to incorporate Coldbox from Ortus Solutions. Repos These two code bases have different needs, and possibly locations, when they are deployed. As a result, we're going to have two repositories: one for the React and another for the API. This will allow us to keep our code separated and cleaner all the way through to deployment.  For each of these repos, we'll follow the procedure we laid out previously with the MASTER branch being used to deploy to production and a DEVELOPMENT branch being used for active work which is then fed into the Master branch via pull requests.  Test...

CF: Scripting amidst the tags

Recently I had to do a quick "utility" page where I needed to see how many files from a directory listing had been recorded into a database. I've been writing about 98% of my CF code in script syntax but, since it was quick and easy, I did this quickly in tags because it was outputting directly to the browser. In doing so, I made an interesting discovery in that, when you use closures, even in tag based pages, you can write cfscript. Here's the example Get the directory listing:  < cfset alljs = directoryList(expandpath( '/src' ), true , "path" , "*.js" )> Get the database listings and convert it to an array < cfquery name = "alljsQ" datasource = "blah" > select * from sitefiles where filename like '%.js%' </ cfquery > < cfset recordedFiles = valuelist(alljsQ.filename).listToArray()> Use a filter function to weed out the files I'd already recorded < cfset missingFiles = alljs.fi...