I have to say I am fairly new to CI/CD and how to automatically update softwares.
I am developping a monitoring software for industrial customers. We have come to the point where we need to think about an updating strategy to make it easier to deploy our newest version to customers. However, my knowledge on the matter is quite poor and I don't really know where to start.
Our main idea is to have some sort of launcher where, on startup, the software detects that a new version is available and asks the customer if he wants to download it. The problem is that I don't know where to start to put in place that strategy.
Prior to my researches, I had come accross kubernetes, docker, Jenkins, and GitLab but can't figure out if they do actually what I want. Furthermore, I have looked at Microsoft's Configuration Manager but it seemslike you can only update softs that are on your network.
Feel free to ask for any info.
Thank you in advance for your help ! :)
Related
we are planning to install directly from kubernetes.io, instead getting it through vendor, for example open shift, rancher, etc.
How should we go about support if we have problem with our kubernetes cluster?
Of course, vendors also gets their kubernetes source code from kubernetes.io and don't change it.
Thank you.
Using OSS software directly means that whenever you face a problem you need to solve it yourself.
Having said that, there is a very wide array of communities filled with friendly people who would probably be happy to lend a hand, at least that's what I've learned through my experience.
A few places you should try are the issues section of the kubernetes project, kubernetes slack workspace, r/kubernetes.
I'm aware this isn't exactly a programming question, but it directly impacts our developers and the code we're assigned to write. If there's another SO-like forum where this could be better posted, please let me know and I'll take the question down from here & post it there.
Our work environment is a couple of developers creating (20-30%) and maintaining (lion's share) legacy software for factory production floor and test workers to use to calibrate or test the equipment the company sells. We've implemented a very simple Google form based bug reporting page, but we're already running into problems of scale (approx 40:1 them:us and lots of old-old buggy software that we didn't write). The company has tried using Bugzilla before my arrival with little success, the factory folks were apparently intimidated by it and wouldn't use it. However, they seem to like the simple Google form and the wizard-like steps to file a bug or request a feature. We're currently manually cutting & pasting their bug/feature requests from the Google form spreadsheet into Trac, and manually tracking the bugs/feature requests on a white board with magnetic bug cards. We're only a few weeks into this system and it's already showing it fragility and lack of scalability.
Ideally we'd have a Windows >= XP web or desktop client that would provide:
Simplified bug reporting, a Wizard like approach seems to work well
Customizable for our software packages (like drop downs for each)
Bugzilla or Trac integration
Standard bug tracking features developers and management can use
I've found the winners of the "Make Bugzilla Pretty" contest, but coming from a pure software house where we just used straight Bugzilla out of the box, I'm unclear on how to configure and install these skins. Obviously I can figure this out but don't want to go down that path if it's not going to solve our basic problem which is non-technical people reporting bugs.
TaskCompiler, found on the Bugzilla wiki site seemed like a candidate because it talks to both Bugzilla & Trac, but their sales page is offline and the site hasn't been updated since 2012 and I'm unsure as to their viability.
I'm certain we're not the first production facility to run into problems like this, I'm looking for recommendations to help solve both our scalability as well as-ease-of-use problem.
Another thought that occurs to me is a GAS script to push our current Google forms based bug reports into Trac or Bugzilla.
Edit: The decision between Bugzilla/Trac seems to have been made for us. I'm exploring options for using Trac here if you want to follow along.
I've been trying to find a guide on how to get Team Foundation Server to turn on a lava lamp or traffic light to indicate the status of the build. I want to set up something that's visible right across the office so there's some peer pressure to encourage developers not to break the build; but I also want it to be fun.
There's a lot of examples for CruiseControl that use X.10 devices which seems like a good way to go. But I can't find anything similar for TFS. I'm sure that somebody must be doing this somewhere...?
Using X.10 has one problem in that it requires a serial port - but our TFS is completely virtualised in a data centre somewhere. Maybe there is some way to trigger the traffic light via an email?
Any advice appreciated. Thanks.
The TFS have got a nice API for getting the status of recent builds. You can use the API and design your own fun system.
Also take a look at:
TFS Build Monitor
TFS Build Light
At some point I had stumbled upon this youtube-video, where Martin Woodward presents Brian, the funky TFS-build bunny. Might be worth checking. It might also be worth checking this SO post.
The TFS API's are terrible they're a pain to do yourself. You could start with this open source project on Google Code: http://code.google.com/p/siren-of-shame/. That project is designed to work with a couple of different build servers, but everything is broken out, so you could start with the TFS 2010 project (TfsServices.csproj). Or if you don't want to do it all yourself that project is designed to work with a USB Siren that they sell (see http://www.sirenofshame.com/).
I am trying to find the best way to maintain a bug tracker and feature/upgrade requests for clients on web development projects. Ideally it would be an open source system we can have installed on a sub domain of our site.
This will then allow each client to login and add bugs/features/upgrade which we can hopefully keep track of.
I have been trying to use and implement trac but it just feels too "techy" and a little too complex for setup.
Any ideas?
Thanks in advance,
Shadi
UPDATE
Just to clarify, we do want a system to install on our servers, the trouble with trac is the install process in relation to what you get and how clients feel about it is a little poor. But if something is awesome but has a complex setup, that isn't a problem...
Mantis is another. Simple UI.
http://www.mantisbt.org/
If you have Linux boxes, trac is much easier to install. Config takes a bit, but wasn't a problem in my experience.
I've heard good things about FogBugz. :)
If you don't want to install it yourself they have a hosted solution also.
Have you taken a look a Bugzilla? Not sure if it meets all your needs but it is free but you can get paid support. It's an open source project AFAIK.
Im interested in providing part of magento ecommerce as a SAAS solution. However, it would be great to get some clarity around the osl license.
I realise that distributing that actual software requires me to open the source. However, in a SAAS environment, surely I can charge for the software service? As long as I release all changes to the core code etc?
How about using the XML API to provide data - I guess thats ok too?
What about if I decide to let the user have the source code? what would I be obliged to do then? let them have it? release all changes?
Anyone have any experience with this? ps I realise you may not be a lawyer ;]
Cheers
Ke
What I would do is charge the user for the hosting. You can sell your customizations as you please as they technically are not subject to the Magento license.
I would stay away from making changes to the "core" code and instead build off of them. That way you are not selling modified versions of the core software (which would kill your ability to easily upgrade the system).
You are allowed to license your extensions however you please so you would not have to worry about the open source model.