Related
Hudson is a great tool, and the emails it sends about failing builds are a great help. However, it can only do this if Hudson itself is in a working condition. It is able to report problems with its own executors like low disk space, unsynced clocks etc. on the web interface, just as it reports build problems, but I couldn't find an option to send email alerts about these. Yet it would be so useful, and seems so logical that this feature should be there.
Am I looking at the wrong place to fix this? Is there another solution to learn about problems with executors without having to poll the web interface every now and then? Am I missing something?
Did you check all of the plugins?
Did you ask on the http://wiki.hudson-ci.org/display/HUDSON/Mailing%20List ?
Personally, much as I love Stack Overflow, I only use it after I have exhausted more dedicated possilities such aa a dedicated foru, mailing lists, emailing the author(s)/maintainer(s) ..
Sorry.
Btw, I have been using Hudson for years and and say that there is - IMO _ mothing better.
As a last resort, maybe you can hack the source code? This sounds like a reasonable feature so I am sure that your code would be slipstreamed into the main build; failiing that, package it as a plug-in
Have a look at the remote API from Hudson. http://wiki.hudson-ci.org/display/HUDSON/Remote+access+API
You can use it to query the statuses you want programatically. You can also file your request as a hudson issue or document it with the The new emailer plugin
We are working in a CI environment, with Enterprise Cruise running our builds. Developers all have CCTray installed locally to notify us if a build breaks.
CCTray has a menu option Volunteer to fix build that you can use to let your team know that you are fixing the build. However this doesn't work in our environment (reasons: Fix build not currently supported on projects monitored via HTTP).
So the question is - does anyone have a technique that they use in their team that allows someone to indicate that they are fixing a broken build?
For me, Continuous Integration is not only about tools, but also about practices. One of them is the responsibility. In others words, the one who breaks the build is also the one who will fix it!
Shooting "I take it guys" is my prefered. ( in addition of the responsability romaintaz describe )
We send an email to the Developer's mailing list to let everyone know you are taking ownership of the build break.
We're co-located, we all run cctray, and when the build breaks we have an audio alert (red alert from the Starship Enterprise). When it breaks we all shout "who broke the build"! Once we figure out who broke the build we harhass them until they tuck their tail between there legs, do that stupid embarassed laugh, and volunteer to fix the build.
It's worth noting that things that aren't monitored by the build and tests can change on a CI box. For example: maybe someone went onto the box and changed a permission. Then when the next checkin is made it looks like the person that made the checkin broke the build when really it was the person that made the manual change without telling anyone.
On the volunteer thing, tools can help but verbal face to face communication is still king.
The onus is usually on who broke the build with their checkin. That's often obvious, even with multiple checkins from different individuals. After that there's a bit of negotiation if the build remains broken. Not particularly scientific or rigorous, but it seems to work.
If the build brokes, then in CCtray there is an option for "Volunteer to fix the build".
And it tells automatically to all the developers who is fixing the build
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What tips and "standards" do you use in your Redmine project management process?
Do you have a standard wiki insert template you could share or a standard way to work a project using bugs features tasks and support issues?
Do you let issues and updates get emailed into Redmine?
Do you use the forums?
Do you use SVN repository?
Do you use Mylyn in eclipse to work the task lists?
I'm trying to drag our dept. into some web based PM instead of emailed Word docs of vague requirements followed by Word docs explaining how to QA and Deploy that all get lost in a pile of competing updates and projects so that by the time I have to fix something, no one can find any documentation on how it works.
I develop and maintain internal applications for a family of manufacturing companies. As of the time of this comment, I'm the only developer/analyst on the IT team. During the worst of the recession my project demands exploded. As such my project AND issue backlog is quite unwieldy. We are currently in the process of restructuring to expand the team.
Here's how I use Redmine to keep my head straight (to the extent that is possible), my users at bay, and hopefully prevent too much hand-holding of new staff in the future.
I use Subversion for source control, with TortoiseSVN and the aptly named Tortoise-Redmine plugin. Refreshing the Repository on the Redmine project after a commit links the issue, which shows the revision on the issue, and updates my stakeholders via email notification.
I treat the project description as a means of communicating the project's purpose, scope, and lifecycle stage to those who are not involved. That way my users know what I've got on my plate, and what's still on the buffet that I'm eyeballing from a distance.
I use specific role names for my permission sets that indicate more than a set of permissions -- again, as a means of documentation. My roles include the following: Project Manager, Project Team Member, Owner, Primary User, Secondary User, Observer, Overlord (for my bosses...both fun and undeniably correct).
I use the Wiki and Documents for documentation, depending on which I feel is appropriate.
Versions are pretty much useless to me, so instead of using that for planned releases, I use it to group related issues into sprints.
I use Eric Davis's fabulous Stuff-To-Do plugin to organize/re-organize the aforementioned sprints before mass-editing the Target Versions on my issues. This also lets my stakeholders know what I'm working on and how I've prioritized their interests (for better or worse).
To encourage user interaction, I added links to the Redmine project into my applications' Help menus. The "About" box also contains a link to the Redmine project.
Future Plans
I hope at some point to finish my Visual Studio extension for Redmine integration.
Build a code library to loosely couple my application with its Redmine project: automate bug submission, alert subscribing stakeholders from system tray, reusable interactive Help menu driven by Redmine's REST API, etc. (Maybe automate portions of documentation with the Wiki?)
I'm a freelance Ruby and Redmine web developer who runs a development business of one (me). So my Redmine is setup to be pretty lightweight and customer focused. My Redmine also serves double duty for hosting my Open Source projects.
I do allow new issues and updates to be emailed and it works great for email connected users (or those who are always on their iPhones).
I've been using the repository view with git repositories and it's working great. With every checkin I reference the issue with #nnn so the actual issue page will show all the commits to implement the feature.
I found the forums are underused. I think if there was some email integration, they would be more useful.
We have found useful the following practices:
1) Hide "Issue" and "Support" tracker, and file everything as a bug:
time-saver for developers, testers, management;
if some activities are to be billed as "extra" or "new feature" or anything else, quick meetings are arranged to assess them.
2) milestones & versions
I love this, you can easily track down the status of each release and at any time you can download an older package, i.e. to test a bug filed by client.
3) "save" function on "issues" tab: another big time-saver, I have different queries saved for many day-to-day reporting tasks and that's all I need.
4) versioning integration, i.e. using "#123" in comments creates a link to corresponding issue: simply clever!
We use Redmine extensively on our system. We have even set up a "Sales" project for our sales team to use as a CRM. We have a heap of custom fields in this project, and it replaces SugarCRM which we were using before.
Within our system, we have projects for Server and Client software. Server project is broken up into submodules, based on how I have structured the system and sub-repositories, since Redmine likes a seperate repo per project.
We use, as others note, #nnn codes in commit messages to reference tickets. What is cool is that it needn't be a ticket in the same project. Thus, a sales ticket can be blocked by a bug issue, or a support request.
We have just started using Documents for agenda/minutes of meetings. We use Versions to group into releases, on both client and server.
To try to use Redmine Time Tracker plugin to track time, but I always forget to click start or end. We get daily emails about issues that haven't been touched in a while (Redmine Whining, I think), and that have due dates in the past or near future (Advanced Reminder).
Support emails go directly into our Support project, and if the email importing was a bit more robust (sometimes it doesn't create new tickets properly if the Project: line is included in the email), we would have website inquiries automatically generate Sales tickets. As it is, we just have to monitor Support tickets, and move them to Sales if applicable.
Things I would like to be able to do:
Have relationships between our system and redmine, so that tickets can be associated with a user or company in our system. Also, so that we can generate a new company from a Sales ticket at the relevant point. This just requires me to do some work.
Have a relationship between our error tracking software (sentry) and redmine, so that server errors generate a redmine ticket. Again, solvable with current technology.
Have a desktop client to redmine. The server is within our LAN, but being able to have a more flexible way to access the data other than the web page would be great. It's not that there is anything I can't really do in the redmine web interface, but something like Things.app is so much nicer to work in.
Have our support documentation all within redmine, and then generated out onto a public-facing server. That way, our support staff can maintain the documentation, edit in a nice way, and deploy changes out to doc-server.
Redmine has been fantastic for us so far. We use it as a multi-tenant ticketing/agile prioritization queue, and have tied it to SVN as well. In particular:
Installing/maintaining via SVN has been a breeze (I've migrated us from 1.1 to 1.2 to 1.3 to 1.4 via the use of svn switch https//.../branches/1.3-stable . commands followed by the rake migrate commands with only occasional gem installations needed in between).
Backups of the database and stored files is a one-line script execution
We love the Time Tracker and Spent Time plugins. I would kill for a Mac OS X time tracking fat client for some of our office users, but that's beside the point :)
We don't use the Forums much, but heavily use Activity and Roadmap. Tying issues to specific versions is a godsend.
We also have Client/Server distinctions, but use the target version to tie the tickets to specify which goes where (and have open ended NEXT CLIENT RELEASE/NEXT SERVER RELEASE) so as to distinguish between while being worked on.
We mix metaphors for statuses - we use our lists first grouped by these ("Immediate", "Rejected", "Blocked", "Working", "On Deck" "The List", "Waiting For Build", "Released To Test", "Verified", "Released to Production", "Closed", "Cancelled).
Then, within each group above, we have this sorted list of Priorities: ("Immediate", "Prioritize Me", "Design And Size Me", "P1"…"P5", "P-Watch List"). This plus the above allow for easy workflow all from the issues area.
For the basic issues list, we do sort by "Priority", "Parent Task", then "Updated Date" - need that middle one so that Redmine indents nicely should there be a child task in the same grouping.
We use checkin commits to tie commits to issues (i.e., svn ci -m "This fixes #1733 #2.5, holy smoke what a weird foo bug. It is now bacon and unicorns.") - and have it move that issue to "Waiting For Build" (That used to be "Resolved", but I got tired of explaining that "Resolved" did not mean someone can expect to see it released yet).
I think I will have to go investigate the Redmine-stuff-to-do plugin though. +1 Question.
My company works with software and hardware developers of international origin. Before I joined the company, email was used with MS Word documents to relay our issues and bugs with software or hardware to request a fix. This process was impossible to track and maintain any kind of process. I implemented RedMine as a means to track the software and hardware bugs and it's been working very well since. There is a major language barrier with my situation. Thankfully RedMine can display in Sipmlified Chinese language and feedback has shown that this is OK so far from my developers.
Status
- When I find a software or hardware issue, Status is "New"
- When my software/hardware developers have seen this issue and they are working on it, they change status to "In Progress." They can use the % done if they wish from 0 - 50. I have them set % Done to 50 when they feel they have resolved the issue.
- I determine if the issue is fixed, and I change Status to "Resolved" and % done to 100%. This allows me to filter out issues < or equal to 50% to find issues that are still open.
Priority
- Low, Normal, High, Urgent, Immediate all translates well into Chinese.
Due Date
- I use this to tell me when the fix was originally uploaded by my software developers. It may take me 4-6 days to test something and close the issue. I like my Gannt chart to reflect the responsiveness of my software team, not how long it took me to approve the fix.
Category
- This always reflects the version of software or hardware where I found the issue. I use this to see which version of software had the most amount of bugs, and to make sure newer versions of software do not suffer from regression.
I have everyone included on the RedMine watchers list for all bugs. The email comes across as (New), (Resolved), or (In Progress) so my supervisors, and the supervisors and head engineers of the teams involved can all see the email and quickly read what progress is currently being made. Most of the other people involved never login to RedMine, I'm typically the only one. The emails serve perfectly to give instant updates to everyone whose only concern is whether or not progress is being made.
As you mentioned sending Word documents back and forward with your QA - I know this feeling, been there, done that.
The main issue for me was: QA people don't like to add issues in any bug tracker, they note them down in an editor next to them during testing.
We are using Redmine now with a nice addon - Usersnap (Disclaimer: We built the tool to solve this problem for ourselves.
Usersnap is great for web developers - add it to your web project and you will get screenshots directly attached to Redmine tickets - including meta information about the used browser, operating system and so on.
Our QAs/customers can enter bugs now directly in the web application and the devs get easier to reproduce bug reports into Redmine.
We are using the Roadmap section as a clear way to display:
bugs
features (that would be references to your word document, or link to html requirement pages)
reconciliations (differences between production values and test values)
and so on...
That is the main point of consolidation for us. The rest is used in relation with that (for instance, the 'announce' section is used to define the main milestone/release dates used in the roadmap)
In addition to the other comments I recommend the use of the "Stuff To Do"-Plugin (written by Eric Davis I think :)
Using that plugin allows you to drag-and-drop sort the order of issues across multiple projects.
https://projects.littlestreamsoftware.com/projects/show/redmine-stuff-to-do
We use Versions as a way to define sprints, so each Version is a sprint with the Roadmap view giving a clear illustration of progress. Issues in sprints are marked as 'ready for review' when completed and then closed when QA has verified.
We use a Version as a backlog for any issues that fall out of scope or lose their priority etc.
We have been using Redmine for about a year now and it has evolved on its own in many ways. We use versions to group issues together for a release, and categories to group issues by discipline.
Each issue goes through a workflow of new > in progress > resolved. Then the tester will close the issue when happy.
We would love to update the way we use Redmine, there seems to be so many great plugins, but we find so many of them are broken or won't install.
We use the wiki comprehensively for developer documentation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
When you are starting a personal programming project, what is your first step? I'm trying to start a project thats just an idea at the moment. I get lots of these and I dive right into the code and after a while just completely lose interest and or just forget about the project.
When you are starting, what is your first step? do you plan out the project? make a diagram? write some code on paper? How do you start a project in a manner that you know you will succeed?
The only thing that works for me: Create the smallest possible implementation of it that's somehow usable and then use it.
From 7 Habits of Highly Effective People, Habit 2: Begin with the End In Mind.
With any project you need a clear goal, a point where you can say "I'm finished". A clear outcome will give you direction. Once you have that, you can start planning how to get there. The size and complexity of the project will determine how much detail your plan needs, but in general you'll want to feel your making progress against your plan quite regularly.
My next step is to sketch out a design of the modules that will be needed and the APIs between each module. If the APIs are clean then the modules are probably right. Then I start implementing the modules, testing as I go.
I spend a lot of time thinking about the various aspects of the project before I even touch a keyboard.
I go through what I've learnt from previous projects and write it down in various categories ('technical', 'promotion', etc)
Personal project or not, I always set up source code control. Git, Mercurial of Bazaar are examples of source code control tools that are not intrusive because you do not need to set up a master server. Just type a simple command to create the project, check your files in, commit. In the future, when you mess up one of your files, you will be able to 'undo'
I also set up a lightweight ticket system to keep track of 1.issues and 2.ideas
By "lightweight" I mean that if maintaining two text documents with these lists works for you, that's good enough.
Hope this helps.
I agree with the already given advice of:
Planning a minimal implementation that does something useful as a first complete release.
Have concrete goals about what you want to achieve to have something to compare your progress with.
I would also recommend beginning with a lightweight design of you overall architecture so you can have a roadmap of how to build your product.
I find it difficult to start building something when I don't have a clear idea about how it should look at least at a first level of decomposition. Think about what do you need besides functionality: high performance?, extensibility scenarios?, which ones?, usability goals?, high scalability?, ease of deployment and installability?, etc. Ask yourself: What components I will have to build in order to achieve those architectural qualities?.
And don't get me wrong, I'm a strong proponent of agile software development. You don't need to spend a lot of times designing your architecture (because it surely will have to evolve as you build and get feedback about what works and what doesn't), but having a blueprint of how to build your product based on its architecture should be useful in for planning your progress and setting realistic goals.
Define the goal for the project. Sounds like you are looking almost exclusively at the solution rather than the problem.
A program isn't useful to you or anyone else unless it addresses some problem. Writing code to get moving is great, but you appear to lose interest and focus after you start -- because you're looking at the code, not the problem.
Spend some time considering what led you to write this code. Ponder how other people might discover the same need, what path might take them to the same frustration you worked to solve.
Then, find some of those people and offer your (partial) solution, and you'll generate interest and suggestions among them all.
THAT will keep you going on your project. The fellow interest, the sharing, even the disagreements -- it's people who need software! Don't create solutions (software) looking for a problem (people). You started with YOU, with your need or desire, but focused on the code, and lost the impetus for the project.
Programming's a lot more fun when you're problem-solving. But you need to keep the problem in front of you. Sharing the problem builds community. That's what this is really all about, isn't it?
For my own personal projects I just dive right in. Of course, none of these have yet been sufficiently large as to require any sort of pre-planning. If this is going to be a serious project or a relatively large scale, it is always a good idea to flush out at least what each part of the program needs to do and a high level view of how they will do it.
Like the others, my personal projects always have:
A Final Goal
A Task List
Small usable units
Source control
As an additional motivator, I try to use a technology that I have never used before. Learning something new generally becomes the largest motivator for me.
Easy - don't start at all projects you're likely to lose interest in. Spend more time to make sure you want to commit yourself to an idea before beginning any work.
It depends on the project - how big is it?
If I'm writing the next Notepad clone I might just dive in, if I wanted to roll my own operating system it'd take a lot more non-coding work.
I like to do a lot of diagrams, the tool I use for most development is clean A4 paper and a pencil. Draw out the UI, workflow, basic classes, and how you're going to store any data - then the coding is just a computer readable way of writing what you drew already.
Source control le.g. SVN is a couple of keystrokes/clicks, so the overhead is low and the benefit is high, its handy to try stuff and just revert to an earlier state if they don't work.
Then just make the most basic protoype that will work - once something is actually going it is much easier to get enthused and add more. If it is overwhelming I'll find I think the problem is solved in my head, and thats enough.
First plan out the basic outline of the final application. Most important features, basic GUI, program flow, etc. Then refine that so that you don't take on too much at first, remove unnecessary features, and add what else you want in the first version. Then use that outline to start a task list to create the smallest possible working version of your application. Then it's much easier to add extra features and make it fully functioning.
I like Maximillian's answer.. to expand a little, my person projects are developed to solve something I'm working on already. So when I get tired of repeat work I'll prototype a solution. and then use it. If Its similar enough to one of my earlier projects I'll borrow as much code as I can and try to improve the level of my work, make it more professional.
Fusion's use of Source Control is important too. Takes 2 minutes to install SVN.
If you want to turn it into a public open source project, Producing Open Source Software is supposed to be a good read (available both online and in print).
If your personal project is similar to an existing open source project, you should consider contributing to that project instead. A couple of small contributions (bug fixes etc.) are
more valuable than a half finished project.
All of the above, but start to cement the plan in place.....
Go for some tools
SmartSheet - even if you are working on your own you should set out some stages and dates
yEd - and Graphity from www.yworks.com
I use cruisecontrol.rb for CI and FogBugz for bug tracking, but the more general the answers, the better.
First is the technical problem: is there an API for FogBugz? Are there good tutorials, or better yet, pre-written code?
Second is the procedural problem: what, exactly, should the CI put in the bug tracker when the build breaks? Perhaps:
Title: "#{last committer} broke the build!"
Body: "#{ error traces }"
I suppose this presupposes the answer to this question: should I even put CI breaks into my bug tracking?
At my company we've recently adopted the (commercial) Atlassian stack - including JIRA for issue tracking and Bamboo for builds. Much like the Microsoft world (I'm guessing - we're a Java shop), if you get all your products from a single vendor you get the bonus of tight integration.
For an example of how they've done interoperability, view their interoperability page.
Enough shilling. Generally speaking, I can summarize their general approach as:
Create issues in your bug tracker (ex: issue key of PROJ-123).
When you commit code, add "PROJ-123" to your commit comment to indicate what bug this code change fixes.
When your CI server checks out the code, scan the commit comments of the diffs. Record any strings matching the regex of your issue keys.
When the build completes, generate a report of what issue keys were found.
Specifically to your second problem:
Your CI doesn't doesn't have to put anything into your bug tracker. Bamboo doesn't put anything into JIRA. Instead, the Atlassian folks have provided a plugin to JIRA that will make a remote api call into Bamboo, asking the question "Bamboo, to what builds am I (a JIRA issue) related?". This is probably best explained with a screenshot.
All the CI setups I've worked with send an email (to a list), but if you did want—especially if your team uses FogBugz much as a todo system—you could just open a case in FogBugz 6. It has an API that lets you open cases. For that matter, you could just configure it to send the email to your FogBugz' email submission address, but the API might let you do more, like assign the case to the last committer.
Brian's answer suggests to me, if your CI finds a failure in a commit that had a case number, you might even just reopen the existing case. Like codifying a case field for every little thing, though, there's a point where the CI automation could be "too smart," get it wrong, and just be annoying. Opening a new case could be plenty.
And thanks: this makes me wonder if I should try integrating our Chimps setup with our FogBugz!
CC comes with a utility that warns you when builds fail, it probably isn't worth logging the failing build in FogBugz - you don't need to track issues that are immediately resolved (as most broken builds will be)
To go the other way round (FogBugz showing checkins that fixed the issue) you need a web based repository browser - FogBugz is easy to configure so that it shows the right changes.