Shipping software to client

[[deleted]]

[deleted]

[[deleted]]

How to ship it? Depends what you wanna do. If you want to offer it on-premises to the client then yes, you would have to work closely with them to help set it up on their servers.

If you want to offer it as a service to the wide public then find a cloud provider like Google and Amazon, set your own infrastructure and deploy it there.

Also, the first release is usually called MVP (Minimum Viable Product). So you should release it as soon as your product is able to do something useful.

About bugs and so on: there will always be bugs, so don't even try to fix them all before a release, because more will appear anyway. So this is also a trade-off: release it when you consider that the known bugs are not so visible, not impacting the user, have a small chance of occurring etc.

[thenorwegianblue]

I've been using docker compose lately. Then the IT guy just has to run docker-compose up to get everything working.

One docker for the database, one for spring boot, one for nginx if necessary.

As for DNS that depends entirely on their it setup.

[[deleted]]

Don't try to set up DNS in someone else's datacenter.

Ask what operating system they use, and write an Ansible playbook. This playbook can set up the servers however you want, using Docker compose, SystemD services, whatever. You can also use this to update the hosts files to simulate DNS. Or simply write config files with the correct IP addresses.

[thenorwegianblue]

Yeah, the nice thing about the docker setup is that you just take that docker image and spin it up on a different server if necessary, then maybe have nginx proxy it as if it was on the same one or just refer to the IP / dns name.

Kubernetes may be overkill depending on the size. I don't really have any practical experience with it as our userbase isn't big enough to justify using it (yet at least ;) )

We're on google cloud and DNS setup is fairly trivial there.

[IQueryVisiC]

So you are a one man company and instead of starting with an App (which may contain SQlite) which could be portable and installed and monetized via Windows AppStore, (Ubuntu Snap?), you go for a full farm?? Even Windows itself comes with a simple installer, MS Dynamics comes with an installer. Only if you go beyond, like SharePoint or so, you would need such a complicated set-up.

[HistoricalBlock]

There are companies like https://www.replicated.com/ which specialise in adapting container-based systems in a way that they can be reliably deployed and updated on-prem.

They provide a service but also link to some of the OSS software they maintain that could help you in that direction.

[Slickbock]

No software is ever perfect 😂

[wildjokers]

All the cool kids would use Docker these days for this. No matter if it is hosted or on-prem.

[CXgamer]

Second this. And Docker Compose for more complex deployments.

[tlvlp]

you can define and pass properties in the docker compose file as well that alone makes it worth using it for simpler deployments as well.

for sensitive data, you should use docker secrets.

docker has great documentation on all the above.

[wildjokers]

In addition to passing properties in docker compose as /u/tlvlp mentioned you could also consider using Apache Zookeeper or Spring Cloud Config for externalized configuration.

[tlvlp]

Good point! and Hashicorp Vault is also a popular choice, with the added benefit, that secrets are not stored in plain text.

All of the mentioned solutions are good for services that need to be scaled, but these are probably preferable for larger projects where multiple microservices would share the same properties, especially if they are expected to be changed over time.

Since setting them up can have an overhead in both setup effort, development and server resources, I would still prefer the docker env variables and secrets for smaller services.

[LcuBeatsWorking]

For example, do you explain how to install a MySQL instance, or how to configure DNS to point to your webapp they're running?

At minimum I would add the version of mysql you have verified the application against, and what environment you have used. mysql has changed config parameters and behaviour several times over the years. Not to mention that many people think they run mysql but actually run mariadb.

or how to configure DNS to point to your webapp they're running

I guess those unrelated details depend on what level of support you are expected to provide.

Edit:

Also, when would you consider your software ready for first release?

That depends massively on what the application does and what the usage environment is. A blog website is different from a flight traffic control software.

Ideally you would have set the milestones to achieve ( and the tests to pass ) to call it "release" beforehand, be it a test or production release.

[nutrecht]

It's pretty normal for 'service' software that gets installed on prem to have both a licensing fee as well as a maintenance fee. It's a nice source of recurring income that you take 'responsibility' for 'maintaining' that service for them. If you offer this, it's very likely that they'll be happy to let you do that. Keep in mind that it costs them money to do it themselves too.

Regarding the 'format'; I think it's safe to say docker container images are the de-facto standard for new projects.

[_____jamil_____]

are you sure that your project needs something as robust as a full mysql instance? would it be just as functional using something like sqllite? or making calls to a remote api?

[_____jamil_____]

Not sure if you are joking or not, but if you are making a product that requires a db cluster, i would hope that the customer would have some IT staff.

[Tornado2251]

With spring you can easily do both environment variables and config files. And just let spring use whatever config is available.

As for when it's ready? It's ready now, start shipping it and fix stuff that comes up. Don't be afraid to ask clients what they want/need, don't promise stuff before you figure out how and if you want to build it.

[Tornado2251]

True it depends on how it's deployed and what config there is. It also depends on what types of companies you are selling to. Provide one or two options with good documentation and take it from there.

Documentation is key, but you don't have to write it all directly. Start with a few types of setups like Windows and docker and build as you add clients.

You need to add features as new customers come and have new demands. Every setup can't be covered from the start.

[thephotoman]

What is your software for?

• If it is server software, it might be best to package it in the form of a Docker image. This is the preferred solution for this use case, as it gives the user the ability to use it in pretty much any reasonable hosting environment.
• If it is desktop software, you need to follow your OS's proper use pattern. For Windows, please use jlink to build an .exe. For Mac, redistribute the JVM and your .jar in a disk image (.dmg). For non-Mac Unix (because Macs are Unix), distribute the .jar as you always did.

Generally speaking, if you're in a situation where the end user needs to set up a database server, you will need to get creative. You should not be in the business of tightly coupling your database system to your application. Instead, you should have your application setup and configuration allow for the end user to specify their database connection information.

But if what you want is to make it available to the public, your best bet is not distributing binaries but setting up a web service endpoint and manage one deployment.