Keeping track
-
Sander Rossel wrote:
At least I'll know which customers or packages need an upgrade.
I suggest you need to keep track of hardware also. And keep the hardware necessary to support it. You might want to consider how active the customer is also. If you haven't gotten any money (significant as defined by you) in say 10 years then maybe time to tell them they need to throw some business your way or future upgrades will be much more expensive.
Sander Rossel wrote:
I can, of course, use Excel
I doubt it. Not for the size that you gave. But you could just add a doc/implementation directory to every source control repo/root and add a text doc(s) with significant information. That is actually probably better than one single Excel for everything. Lets you go more freeform.
jschell wrote:
I suggest you need to keep track of hardware also. And keep the hardware necessary to support it.
I really don't care about the hardware. Pretty much any decent Windows PC will do. Most is hosted in Azure App Services, so I don't even control the hardware.
jschell wrote:
You might want to consider how active the customer is also. If you haven't gotten any money (significant as defined by you) in say 10 years then maybe time to tell them they need to throw some business your way or future upgrades will be much more expensive.
This I know from my invoices.
jschell wrote:
But you could just add a doc/implementation directory to every source control repo/root and add a text doc(s) with significant information. That is actually probably better than one single Excel for everything. Lets you go more freeform.
Yeah, but I'd still have to open and read every repo to find "all applications that are running on .NET < 8."
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Yeah, but I've got private web apps and every customer has their own highly customized app.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Two separate axes here: 1. For each application, you need your release tracking such that you can rebuild any product as delivered to a customer. Source control should help here. Each release is a tag/label. Depending on your setup, you might need to introduce a new folder/area/repo (likely per application) dedicated to release tracking. 2. For each customer, you need to know what application releases they have purchased and installed. You could probably use source control here as well. One possibility: Customer repo, folder for each customer, filename for each application they use, contents of the file is one line that lists the application name and the release number. Everytime they update or purchase a new app, you update their files.
englebart wrote:
For each application, you need your release tracking such that you can rebuild any product as delivered to a customer. Source control should help here.
Got CI/CD, but that still doesn't tell me which .NET or Vue version a customer is on, or if they use any library or framework that requires special attention. Don't much care about which version was running when, we go forward only.
englebart wrote:
For each customer, you need to know what application releases they have purchased and installed. You could probably use source control here as well.
All my customers have highly customized apps that are unique for them. I just want to query the applications I've built, like "SELECT Application WHERE .NET < 8". It's probably going to be a SQL database with a customized front-end.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
visual studio and couple of folders or source control?
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
I have folders and source control, but the problem is that I have nothing that works easy and spans everything. I'm probably going to store everything in a SQL database for easy querying.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Just wondering how people keep track of all the software and versions they wrote for all their customers? For example, I started out using .NET Core 2.2, but I think I've upgraded everything to at least .NET Core 3.1. Save for one or two projects (maybe three?) it's all .NET 6 or .NET 8 (maybe a .NET 5 or 7 project somewhere?). I've also used Vue from the beginning and I think all my projects are Vue 2 and it seems I now have to upgrade to Vue 3. Same for Bootstrap and who knows what I've been using these past years. I own a small company with about ten customers and thirty to fourty software projects, but it's growing rapidly. Since it's still small and doable, I'd like to start keeping track sooner rather than later. At least I'll know which customers or packages need an upgrade. I can, of course, use Excel, but I can imagine there are better tools for this that list the customers or the frameworks/libraries and their versions. Or I could roll out my own (which should then be registered in itself :D).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
It sounds like you need an Application Portfolio Management (APM) tool. These track applications and all the relationships between them and attributes that you'd need. However, they're expensive. I'm only aware of one open source tool, Essential Project. Unfortunately it's a pain to install and a bigger pain to use. There's a paid for version with web tooling but I doubt you want to throw USD $19,000 at this. To be honest your idea of a spreadsheet sounds feasible if you keep your aims basic. Search for APM tools; companies like BizzDesign, Value Blue and Qualiware have decent APM tools and lots of freely available information that'll give you a good idea of what you'll want to track.
-
It sounds like you need an Application Portfolio Management (APM) tool. These track applications and all the relationships between them and attributes that you'd need. However, they're expensive. I'm only aware of one open source tool, Essential Project. Unfortunately it's a pain to install and a bigger pain to use. There's a paid for version with web tooling but I doubt you want to throw USD $19,000 at this. To be honest your idea of a spreadsheet sounds feasible if you keep your aims basic. Search for APM tools; companies like BizzDesign, Value Blue and Qualiware have decent APM tools and lots of freely available information that'll give you a good idea of what you'll want to track.
Sounds like that is what I'm looking for, but all very bloated. Didn't even know such applications existed (well, I could've guessed, but hadn't heard of the term application portfolio). "APM tools" gives me application performance monitoring tools exclusively ;)
Grotsoft wrote:
I doubt you want to throw USD $19,000 at this.
I can confirm your doubt! :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Just wondering how people keep track of all the software and versions they wrote for all their customers? For example, I started out using .NET Core 2.2, but I think I've upgraded everything to at least .NET Core 3.1. Save for one or two projects (maybe three?) it's all .NET 6 or .NET 8 (maybe a .NET 5 or 7 project somewhere?). I've also used Vue from the beginning and I think all my projects are Vue 2 and it seems I now have to upgrade to Vue 3. Same for Bootstrap and who knows what I've been using these past years. I own a small company with about ten customers and thirty to fourty software projects, but it's growing rapidly. Since it's still small and doable, I'd like to start keeping track sooner rather than later. At least I'll know which customers or packages need an upgrade. I can, of course, use Excel, but I can imagine there are better tools for this that list the customers or the frameworks/libraries and their versions. Or I could roll out my own (which should then be registered in itself :D).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
How much do you want to spend? Apparently there are commercial tools available for your purpose, although other posts indicate they may not be affordable for a small business. Create an MS Access DB. From the 1,000 foot view, 3 tables: Customer Projects, Components (software and hardware), and a join table that links Customer Projects and Components, including the specific version number used for each Component. From there you can create reports that list all Projects (including Components) where the version number of a given component is compared to a target value, e.g., .NET Core version = 2.1 *OR* .NET Core version < 6.0. This is from the 1,000 foot view -- the solution may be more detailed, but it may be the start you need to help you understand what you really need. Or it may be exactly what you need, done on a shoestring. And it's the potential for a commercial product geared towards small software businesses.
-
How much do you want to spend? Apparently there are commercial tools available for your purpose, although other posts indicate they may not be affordable for a small business. Create an MS Access DB. From the 1,000 foot view, 3 tables: Customer Projects, Components (software and hardware), and a join table that links Customer Projects and Components, including the specific version number used for each Component. From there you can create reports that list all Projects (including Components) where the version number of a given component is compared to a target value, e.g., .NET Core version = 2.1 *OR* .NET Core version < 6.0. This is from the 1,000 foot view -- the solution may be more detailed, but it may be the start you need to help you understand what you really need. Or it may be exactly what you need, done on a shoestring. And it's the potential for a commercial product geared towards small software businesses.
Yeah, I've opted to create my own. Not using Access though, but SQL Server. I can create a simple front-end for it too.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Just wondering how people keep track of all the software and versions they wrote for all their customers? For example, I started out using .NET Core 2.2, but I think I've upgraded everything to at least .NET Core 3.1. Save for one or two projects (maybe three?) it's all .NET 6 or .NET 8 (maybe a .NET 5 or 7 project somewhere?). I've also used Vue from the beginning and I think all my projects are Vue 2 and it seems I now have to upgrade to Vue 3. Same for Bootstrap and who knows what I've been using these past years. I own a small company with about ten customers and thirty to fourty software projects, but it's growing rapidly. Since it's still small and doable, I'd like to start keeping track sooner rather than later. At least I'll know which customers or packages need an upgrade. I can, of course, use Excel, but I can imagine there are better tools for this that list the customers or the frameworks/libraries and their versions. Or I could roll out my own (which should then be registered in itself :D).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
My company is in a similar situation. We have several large projects that are generic to all clients and over a hundred of small projects that are client specific. We moved to GitHub several years ago and didn't find anything simple to keep track of it all. The missing piece always was the aggregation or list reporting. Using excel always seems too easy to miss something or make a mistake. We wrote a simple app that reads all the csproj files and puts the useful info into a database. For us the key items are the .Net or .Net framework version and all the packages and their versions. It has a simple change log of "new", "updated", "removed" with version info. We use it primarily to track .Net versions and package versions. The cross reference is helpful for looking up where we used some esoteric package. We learned quickly to stay aways from odd numbered .Net versions for client use.
-
My company is in a similar situation. We have several large projects that are generic to all clients and over a hundred of small projects that are client specific. We moved to GitHub several years ago and didn't find anything simple to keep track of it all. The missing piece always was the aggregation or list reporting. Using excel always seems too easy to miss something or make a mistake. We wrote a simple app that reads all the csproj files and puts the useful info into a database. For us the key items are the .Net or .Net framework version and all the packages and their versions. It has a simple change log of "new", "updated", "removed" with version info. We use it primarily to track .Net versions and package versions. The cross reference is helpful for looking up where we used some esoteric package. We learned quickly to stay aways from odd numbered .Net versions for client use.
Exactly what I need as well. I rolled out my own hour registration and billing app, so I'm just adding this to it. Nice side-project for weekends :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Just wondering how people keep track of all the software and versions they wrote for all their customers? For example, I started out using .NET Core 2.2, but I think I've upgraded everything to at least .NET Core 3.1. Save for one or two projects (maybe three?) it's all .NET 6 or .NET 8 (maybe a .NET 5 or 7 project somewhere?). I've also used Vue from the beginning and I think all my projects are Vue 2 and it seems I now have to upgrade to Vue 3. Same for Bootstrap and who knows what I've been using these past years. I own a small company with about ten customers and thirty to fourty software projects, but it's growing rapidly. Since it's still small and doable, I'd like to start keeping track sooner rather than later. At least I'll know which customers or packages need an upgrade. I can, of course, use Excel, but I can imagine there are better tools for this that list the customers or the frameworks/libraries and their versions. Or I could roll out my own (which should then be registered in itself :D).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
The place where I am working had the same problem, but across 100s of applications. These are all in Azure DevOps repos, so I wrote a tool to scan every repo and save to a DB a lot of metadata on each. Things like dotNet version, DLLs and packages included with version, etc. Very useful to generate report on EOL packages and frameworks. The company made it available on Github as open source if you are interested... UPDATE: The app is called AzureDevOps.Technology-Framework-Monitor in Github.
-
I have folders and source control, but the problem is that I have nothing that works easy and spans everything. I'm probably going to store everything in a SQL database for easy querying.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
u could create a build management server , check this diagram -- [Automated deployment from Jenkins - Octopus Deploy](https://octopus.com/jenkins) .. that can also generate xml xsl report when builds complete ..those could document details of libs etc used...........its sort u making your own alm tool for your company...that you can tweaking and improve...
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
-
Mostly in repos I control, though not all in the same tenant or system (I've got two Azure DevOps accounts and a GitLab repo). Having to search in and open separate files doesn't sound that appealing though.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Sander Rossel wrote:
Having to search in and open separate files doesn't sound that appealing though.
Just throwing ideas out there... if they be sucky let me know... But what about a git hook then? Not a commit one, but a push one. So, every time you push commits to a remote server you can also call a second endpoint to update metadata in some NoSQL db somewhere. Then just query that. There is one caveat to hooks though, they can be overridden by the command line. But this isn't security or anything like that, just tell peeps to not use `--no-verify`, etc. when pushing code.
Jeremy Falcon
-
Just wondering how people keep track of all the software and versions they wrote for all their customers? For example, I started out using .NET Core 2.2, but I think I've upgraded everything to at least .NET Core 3.1. Save for one or two projects (maybe three?) it's all .NET 6 or .NET 8 (maybe a .NET 5 or 7 project somewhere?). I've also used Vue from the beginning and I think all my projects are Vue 2 and it seems I now have to upgrade to Vue 3. Same for Bootstrap and who knows what I've been using these past years. I own a small company with about ten customers and thirty to fourty software projects, but it's growing rapidly. Since it's still small and doable, I'd like to start keeping track sooner rather than later. At least I'll know which customers or packages need an upgrade. I can, of course, use Excel, but I can imagine there are better tools for this that list the customers or the frameworks/libraries and their versions. Or I could roll out my own (which should then be registered in itself :D).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I use the code repository API (in this case Azure DevOps) to scan all our projects for a `.csproj` files to get the .NET version being used. It can be modified if we have other Languages/SDKs/Frameworks in use. For example reading the `package.json` for the ***node*** and ***npm*** versions.
-
I use the code repository API (in this case Azure DevOps) to scan all our projects for a `.csproj` files to get the .NET version being used. It can be modified if we have other Languages/SDKs/Frameworks in use. For example reading the `package.json` for the ***node*** and ***npm*** versions.
Just saw the reply from Andreas @User-3771503 and will be taking a look the **AzureDevOps.Technology-Framework-Monitor** project. Seems all the meta data could be useful. Mine is much simpler, but does store some details in a [LiteDB](https://www.litedb.org/) database file.
-
Just wondering how people keep track of all the software and versions they wrote for all their customers? For example, I started out using .NET Core 2.2, but I think I've upgraded everything to at least .NET Core 3.1. Save for one or two projects (maybe three?) it's all .NET 6 or .NET 8 (maybe a .NET 5 or 7 project somewhere?). I've also used Vue from the beginning and I think all my projects are Vue 2 and it seems I now have to upgrade to Vue 3. Same for Bootstrap and who knows what I've been using these past years. I own a small company with about ten customers and thirty to fourty software projects, but it's growing rapidly. Since it's still small and doable, I'd like to start keeping track sooner rather than later. At least I'll know which customers or packages need an upgrade. I can, of course, use Excel, but I can imagine there are better tools for this that list the customers or the frameworks/libraries and their versions. Or I could roll out my own (which should then be registered in itself :D).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I think one thing that might both help make that more manageable and also confer supply chain protection for you would be to implement your own internal package stores. Sounds like you'd want one for nuget and one for npm. There will be many companies doing that this year. If this is a new concept to you - The idea is that your solutions only pull from your own internal package stores. You pull new stuff from the public stores and into your own stores on whatever basis you choose. You get a big bit of protection against pulling in tainted packages and having them make it into your releases. With it split in this way, your choice of updating your local package stores can serve as the "low bar". If you then open a solution and it says there are new updates, you know that means that solution is behind your own presently set standard. This also means that you can look at your local stores and determine at least what version of any given pkg that all of your things should be using as well as which versions might possibly have been used at some point.
-
englebart wrote:
For each application, you need your release tracking such that you can rebuild any product as delivered to a customer. Source control should help here.
Got CI/CD, but that still doesn't tell me which .NET or Vue version a customer is on, or if they use any library or framework that requires special attention. Don't much care about which version was running when, we go forward only.
englebart wrote:
For each customer, you need to know what application releases they have purchased and installed. You could probably use source control here as well.
All my customers have highly customized apps that are unique for them. I just want to query the applications I've built, like "SELECT Application WHERE .NET < 8". It's probably going to be a SQL database with a customized front-end.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Just saw the reply from Andreas @User-3771503 and will be taking a look the **AzureDevOps.Technology-Framework-Monitor** project. Seems all the meta data could be useful. Mine is much simpler, but does store some details in a [LiteDB](https://www.litedb.org/) database file.
It's does work, and it generates a lot of metadata that can be useful. I'm still extending it with additional functionality such as documenting pipelines and such...
-
jschell wrote:
I suggest you need to keep track of hardware also. And keep the hardware necessary to support it.
I really don't care about the hardware. Pretty much any decent Windows PC will do. Most is hosted in Azure App Services, so I don't even control the hardware.
jschell wrote:
You might want to consider how active the customer is also. If you haven't gotten any money (significant as defined by you) in say 10 years then maybe time to tell them they need to throw some business your way or future upgrades will be much more expensive.
This I know from my invoices.
jschell wrote:
But you could just add a doc/implementation directory to every source control repo/root and add a text doc(s) with significant information. That is actually probably better than one single Excel for everything. Lets you go more freeform.
Yeah, but I'd still have to open and read every repo to find "all applications that are running on .NET < 8."
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Sander Rossel wrote:
I really don't care about the hardware.
I worked at a company where a customer requested we update an application that was written to run on Windows 3.1. The app was written using Visual Studio 1.52 (I believe that was the number.) Fortunately, since I keep old stuff, I did have a CD with that VS version on it. I think, then, that the computers would run that. Not sure about now. But maybe a VM would. But one would still need to have a CD reader for it. And using 'different' hardware is a problem if they claim that your new release doesn't work. Since possibility exist there is some exotic environment difference. So closer to the actual hardware is more re-assuring for me.
Sander Rossel wrote:
and read every repo to find "all applications that are running on .NET < 8."
I must not understand your support model. I expect on a independent support model if a customer wants an upgrade then you upgrade their product space. If they don't pay then you don't need to touch it?
-
Just saw the reply from Andreas @User-3771503 and will be taking a look the **AzureDevOps.Technology-Framework-Monitor** project. Seems all the meta data could be useful. Mine is much simpler, but does store some details in a [LiteDB](https://www.litedb.org/) database file.
I have made a number of improvements, if you have questions let me know. It is also possible to run this in a Azure DevOps pipeline.
