Software Release by Customers

Asked

Viewed 121 times

4

The system I develop has several clients who use it. But I have a problem which is this: if I release a new version of the system, I raise it to the ftp, all customers using it have access to this new version and the system is updated.

I don’t even know if here is the best way, but I really need to figure out a way to circumvent this barrier, because if I make a change in code it could affect even customers who don’t need that new version and it would generate a lot of headache.

My question is this: is there any way that I can make this release of the versions so that I choose which customers will have access to that new version?

c# .net winforms versioning svn
  • 1

    Which version control you use?

  • I use the Gypsy svn.

  • Does any version have exclusive features for a particular customer? Paid for by him, for example?

  • @What happens is that depending on the client, some changes made to the code can change the functioning of the system that is already running. No distinction paid between each. But some customers require some extra functionality than others.

  • 1

    Take a look at the Octopus Deploy tool (https://octopusdeploy.com) A tutorial on the use of Octopus with Jenkins (continuous integration tool) can be found at http://www.mobiltec.com.br/blog/index.php/automatizando-deploy-de-application -Asp-net-com-Octopus-deploy/

  • But this Octopus supports windows Forms ?

Show 1 more comment

2 answers

2


What you want is to release the version per client, and for this you need to have a point in common with the client, to work you need to put in the client an item that can indicate that you need to update, so it will indicate the version that the client has to use.

An idea is before downloading the file, the client consults a WEBSERVICE that releases the download of the version corresponding to the client.

So you can have a general version of the versions released to customers, so you can have control of the clients which versions they use, which updated versions, and which need to update, will have a thinner control over the available versions.

  • Luiz, what happens is that I already do this. I wanted to avoid creating many folders. That is, if I have about 100 clients... I’ll have to create 100 ways to make it available. I wanted an easier way to manage. If I got it wrong, I’m sorry!

  • @Érikthiago, I am maintaining a system that contains a form of distribution that is controlled by a file, the client accesses an area and downloads this file, if it contains the download information is carried out and the system is automatically updated. There is a table where it is controlled the client who is entitled to update, and a program that indicates which clients have this right, after updating the text file is released to the client, this generates many files but that’s how it was built.

  • @Érikthiago , continuing, we are thinking of creating a webservice to be consumed in the system load, sends the client code that queries in the client base that is entitled to version update, which version and so updated automatically. Which reduces my number of files in the client area that has little functionality. and do not need to run another system to generate file and distribute....

  • Man, now I get the idea. At first I had found that in the webservice there would be several folders with client executables and that I would have to keep on maintaining them all. Really this way of checking by direct file by webservice is a good choice! Thanks ai guy, thanks even!

2

Make a tag by version

The first step is to keep the application code in the version the customer purchased. The best way is to freeze the code when the version is stable. In your case, which uses SVN, this can be done by tags.

The strategy is as follows:

  • When there is a desire to establish a version, a branch of the current revision of trunk;
  • The branch will be candidate version. Make the release of the version and test;
  • Try to make corrections inside the branch. Reintegrate when possible to the trunk;
  • When there is a good indication of stability, generate a tag of branch. Tags cannot be modified.

In projects I worked on, the following structure was quite common:

  • trunk
  • branches
    • v1.1-RC
    • v1.2-RC
    • v.1.2.1-CR
    • ...
  • tags
    • v1.1
    • v1.2
    • v1.2.1
    • ...

Whereas you are using ASP.NET MVC, Entity Framework and Code First, no other control than the on-screen version number (which may be Hard Coded) it is necessary.

  • 1

    You answered my question by parts. Very good explanation... But how do I release the version for certain customers... I mean, if I made a tag and made it available to ftp. How can I choose which clients will receive this tag ?

  • If you are using FTP you are already a little wrong. ASP.NET MVC should be published by Web Deploy. Another thing is that you never publishes the trunk directly. You open the Solution tag and publish it. Another suggestion is to keep a version table that records versions that have already been applied to the system. Then you flip a screen to see these records.

  • I am currently working with windows Forms. So if you use clickonce put on ftp and client every time it logs in, the system looks for update.

Browser other questions tagged c# .net winforms versioning svn

You are not signed in. Login or sign up in order to post.