Verwenden Sie SVN / GIT für den Verlauf der Software-Versionierung? Oder etwas anderes?
636
SteveGriff
Derzeit arbeite ich an der Implementierung einer Versionierungsinfrastruktur für unsere geschäftlichen Anwendungen. Sie wissen, V1.1, 1.2 usw. für unsere Apps.
Was ich gerne machen würde, ist ein einfaches Einrichten der Änderungen der Aufzeichnungssoftware und des Versionsverlaufs. Wir verwenden bereits SVN (und gehen zu GIT über), und ein Teil von mir sagt nur, verwenden Sie das. Aber ein anderer Teil nervt mich und sagt, dass das nicht genug ist.
Das Business möchte nicht wirklich durch unser SVN-Repo gehen, oder? Ich habe mich gefragt, ob jemand wusste, wie man besser vorgeht. Irgendwelche Vorschläge?
Danke, Steve
Können Sie eine Beispielsituation nennen, in der ein Nicht-Entwickler ein Repo durchlaufen muss?
Andy vor 13 Jahren
0
Die Apps werden im eigenen Haus entwickelt.
Andy vor 13 Jahren
0
Ja, sie werden im eigenen Haus entwickelt.
SteveGriff vor 13 Jahren
0
Ein Nicht-Entwickler, vielleicht ein Mitglied von Business außerhalb der IT-Abteilung, würde gerne die Änderungen erfahren, die in der letzten Version vorgenommen wurden, Fehlerbehebungen usw. Sie möchten also nicht den Versionsverlauf für das gesamte Unternehmen dort aufbewahren, sondern möglicherweise in einem separaten Ordner System.
SteveGriff vor 13 Jahren
0
Sie können die Fragen mit den zusätzlichen Informationen bearbeiten, die Sie jetzt in den Kommentaren angegeben haben.
Tim Murphy vor 13 Jahren
0
Its been my experience that the commit messages usually contain highly technically details about the changes being committed. Generally they are not suitable for release notes. What I do is keep a more friendly 'release notes' document for this purpose. I am hoping to move over to a web based system like redmine that can track the enhancements and bugs.
If the commit messages are good (i.e. not to technically) there are ways to pull that information from the repo. For example here is the command I used to pull the messages out of svn:
svn log --verbose https://<address to server>/<repo name>/ > svnMessages.txt
1
mindless.panda
I use a changelog to communicate bug fixes, changes, or new features to end users. I model my changelog on tortoisesvn which uses BUG: CHG: NEW:.
I place changelog lines in the repository history via commits, along with the more technical information that goes into commits. This joins the two tasks together in time, recording technical changes as well as what should be visible at a higher level to users.
When I release I can easily pull all the latest changelog lines and update the changelog/website/etc. With the prefixes on any changelog line in the commit history I can also automate it.
I like how this method keeps the two flows of information together, in the repository, where they should be.
0
Josh K
You can use git in house and then simply make cuts out of the repository for major versions (tarballs).
0
Andy
I would choose the source control system that your development team prefers (leaning towards git if they're apathetic!). What you want is a standard method for 'publishing' a major version along with a changelog. This could be done with a script that downloads from the repository and displays the changelog, via a web-based system, it could just be a shared directory on the LAN, an FTP site, etc., etc.
Möglicherweise möchten Sie eine auf Trac basierende Weblösung erstellen: http://trac.edgewall.org
Andy vor 13 Jahren
0
0
ta.speot.is
Your question:
The Business don't really want to go through trawling our SVN repo, do they? I was wondering if someone knew of a better way of going about it? Any suggestions?
The extra information you provided:
A non-developer, maybe a member of Business from outside IT would like to know the changes that went into the last release, bug fixes etc. So you don't want to keep version history for business wide there, but maybe in a separate system
Separate System: Microsoft Exchange
Solution: Email them when a new release goes out.
0
Tim Murphy
All projects I work on have a wiki for use by developers and usera. The wiki is mainly used for documentation/help but it also includes change logs suitable for end users. The change log is updated daily, referring to version control if required, with final edit and polish when the build is released.
Many users, especially the bill payer when working remotely, appreciate the daily updates.