Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I'm looking for a good template on server-side installation of software for a project I'm working on.
The client-side is pretty straight-forward. The server-side installation is a little trickier. It is made up of several pieces (services, database connections, dependencies, ports that need to be unblocked, etc.). During a recent test, several undocumented pieces were discovered. Now I need to create installation documentation for our disaster-recovery plans and ways to test the installation without necessarily having a "full-up" system to test on.
I'd really like a suggestion of where I can get a template or a really good example of such a document. I'd like it to be something that an operator could read and comprehend in the heat of a recovery.
[EDIT]
Our current documentation comes mainly from the questions our administrators have had during off-site tests. As new code is written, I'd like to make sure the documentation is written ahead of time. I've been collecting VMWare images to start testing, but was looking for some good examples. It's a Windows Server shop (2000 & 2003). Word templates would be great, but if I could see good documentation, I could create the templates. Any suggestions about what should be tested would be great as well.
[2nd EDIT]
I've gotten several good ideas from the answers posted. After changing my Google search, I came up with some good starting points. They're not perfect, but they are a good start.
Microsoft Exchange - http://technet.microsoft.com/en-us/library/bb125074(EXCHG.65).aspx
iPhone - http://manuals.info.apple.com/en_US/Enterprise_Deployment_Guide.pdf
http://www.novell.com/documentation/gwgateways/gw7_exch/index.html?page=/documentation/gwgateways/gw7_exch/data/ab32nt1.html
http://cregan.wordpress.com/2006/06/22/exchange-2003-step-by-step-installation-instructions/
http://technet.microsoft.com/en-us/magazine/cc160942.aspx
Covers planning in the design stage well - http://www.onlamp.com/pub/a/onlamp/2004/04/08/disaster_recovery.html?page=2
[Edit 10/29/2008]
THIS is the type sample I was looking for. It doesn't have a lot of garbage, but seems to explain enough of the why along with the how http://wiki.alfresco.com/wiki/Installing_Labs_3_Nile
The most complete method that we've come up with for creating our DR documentation, involves going through a full cycle (or two) of installation, and documenting each step along the way.
I realize this can be a bit difficult if you don't have a test (or replacement) system to use to create your documentation - but it's worth lobbying for running through this cycle at least once.
(I recommend twice, the second being done by someone not involved with the project - this is how you test the documentation for future admins, who may not be as experienced with the process.)
A side effect of the above is that your documentation grows fairly large - last I had to do it, I believe the completed installation manual for our database servers was 30+ pages.
What should be tested? Well, in the case of a web site, "can you get to the page?" Include a URL as a starting point and let the admin click through to a certain point. It is not necessary for the admin to go through the whole QA cycle, just a confirmation that what you meant to be deployed is really what got deployed.
Other ideas
Also, we (my team at my last job) had QA test the deployment. As a QA person should be, he was not intimate with the details and as he deployed to QA, we were able to get feedback on what went wrong.
Another thing that is useful is sitting down with the admin(s) before the deployment. Go over the instructions and make sure they understand them the same way you do.
Template? Just make sections that have fields for data such as URL to DEV, QA, and PROD. When you write out the instruction you can refer to those. Just make it clear what is being deployed.
Depending on the admins, automation is helpful. I've had windows admins that want a Word doc with step by step instructions and other admins that wanted a script.
However, some helpful things to include, probably as sections
Database changes
Scripts to run
Verification that they worked
Configuration changes
what are the change
where is a version of the new file (In my case they diffed the two, which helped reduced errors concerning production-specific values)
General verification
what should be different from the user perspective (feature changes)
For web farm deployments, it might be helpful to have a coordination document concerning how the servers need to be pulled in and out of pool.
Related
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 3 years ago.
Improve this question
What are some good procedures to follow when handing a project to another developer, in cases of when the original developer will still be around for a couple of months to aid in the transition? Let's assume a medium-sized web application if a concrete example is necessary.
As a junior developer, I have gotten several projects assigned to me for maintainance that were written by others. I believe the easiest projects to continue are the ones where the code is clean and well documented (meaningful var names and formatting as well), the archetecture is relatively strightfoward, and the developer took some time to write some notes on the use of his components. In Java this would include class-level javadoc; in other languages it may include a header at the top of the source code.
Also, if the original developer is available and open to questions, it makes learning the archetecture much simpler - no puzzling out what he was thinking.
I've been on both ends. Taking over a code base and handing it off.
You should:
Identify areas that aren't completely
obvious. So, if you have a directory
called "xml" but all your flash
object get their data from
"flash/swfs/xml" you should document
that.
Identify parts of the database which
are no longer in use. If there are
tables that simply have no use
anymore.
Identify areas of concern such as
speed/performance of certain pages.
If you have some really backwards
logic on certain pages, explain why,
if it's not been commented in the
code directly.
Any third party vendors should be
identified along with their cost and
use on the site. So if you're using
a delivery network to stream your
flash videos, definitely let that be
known.
If you have pages still in the
project, but aren't being used
anymore, identify them, or simply
remove them.
If you know for a fact that your
database was poorly designed,
contains no constraints or indexes
and has no primary keys on many
tables, mention it. It will let the
new developer know they need to
optimize the database.
If you hardcoded e-mail addresses
within the code and didn't put them
in .config files, identify that as
well.
I'm sure there are more but there are things I wish were brought to my attention on a project I had taken over at one point.
If you have written your code from the start so that it is sensibly architected and fairly simple to understand, and provided adequate documentation, transitional problems should be minimal.
But training is always nice.
For anything that requires a build environment (certain compiler, 3rd-party libraries, opensource libraries, paths, etc.,), have the original developer sit down with the new developer, at the new developer's workstation, and walk through the process of making a simple change, committing to the source control, building, smoke test, etc.. Lots of times projects that are out of the mainstream may have odd procedures for testing, or they may come from an unfamiliar repository branch, may need a specific compiler version, libraries, etc.. Bugs may be tracked differently, it may require specific logins or endpoints for testing, etc.. By walking the new dev through the process, on their workstation, you'll uncover all of those issues, saving the new dev lots of frustration.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Background: On a new project I've found myself 3 levels removed from my actual source of information. I report to my PM, who reports to our contractor, who reports to the actual client. Getting answers to questions has become something of a problem and I'm curious to know what people recommend.
Needs: I'm trying to find a technology or disciplined strategy that will assist me in ensuring that the questions I'm asking are getting answered:
Correctly without much modification of the original question
Quickly so the original context isn't lost
Completely so that if a question is deferred I don't forget about it.
Does anyone know of a software suite that assists in this matter or do you have any personal discipline strategies that worked for you?
Thank you for the guidance
One strategy might be to cut out the middleman. Go directly to the client and ask what s/he wants.
On a slightly less bold note, request that you, your PM, the contractor, and the client all meet at the same time rather than on relying on an email chain or technology (which will undoubtedly not serve everyone's needs) to relay information. This strategy works particularly well in my experience, as long as you have a manager willing to let you tag along.
Best technology I can suggest is the telephone. You've got to open up direct lines of communication. But I guess you know that and are finding it difficult, someone along the line is not helping. So now you have to tackle that person, find out why not, what their reservations are and how you might allay their fears.
As for software, I recommend that you DO NOT look for a software solution to this sort of problem. Suppose you implement a new trouble-ticketing system for capturing client questions and comments and to feed back your questions and comments to your client. Next time you tackle your management about the issue one of 2 things will happen:
-- The response will be 'But you told us installing system TT would fix this !'
OR
-- There must be something wrong with system TT, we'll divert our energy to fixing the software.
Oh, and do write things down, so email might be even better than the telephone.
Regards
Mark
I'm sorry, but this doesn't sound like a technological issue. Good project managers ensure communication and should allow you to work directly with the client where necessary. This is a communicaiton/management problem.
PRINCE2 (the project management methodology) would define your questions as project issues (essentially an issue is anything which needs attention so a question is no different to a software defect).
Based on this I'd recommend tracking them the same way you track any other issue.
In your defect tracking system (you do have one right?) set up a category / classification / whatever "Question" and log them and assign them to either the client (ideally they should be given direct access) or to the Project Manager (who now has a way of tracking them and recording the answers).
As with all issues you should make sure you put in plenty of information and context to ensure you get a good answer (obligatory Jeff / Joel reference: in this case to Jeff's belief that you only get out of a question what you put into it). This will also obviously help if you're not the person actually asking it, though as many people have said do everything you can to get closer to the client.
The key point to remember is that people are lazy.
If you formulate questions through e-mail clearly and in format your contact likes, most likely he'll forward them to the next chain of command unchanged and so on.
Some quick tips on how to structure such an e-mail:
Numerate all your questions. Essential, otherwise all too often only the latest question will been answered
Be very specific in what the actual question you need input on is
If there is a fixed set of alternatives or if you have a clear recommendation, make sure this is clearly stated
Avoid mixing FYI messages with the questions. Instead, send separate e-mails
Carefully read your e-mail before you send and look for content that may be misunderstood
Good luck
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am going to be starting a new job in a few weeks where I will be responsible for both the maintenance and development of a couple of existing web applications and the development of new web applications.
As I will be the only developer on the project and the previous developer was more of a hobbyist, no formal project management or planning techniques have been followed. Additionally no bug tracking has been used or if anything has been recorded its just been notes on paper.
I would therefore like to introduce a better system to help resolve some of the issues and help ensure things run more smoothly. I intend to develop using an agile process (likely scrum) and would therefore like to know what all-in-one solutions people could recommend for me to look into further. I am looking for something which will provide at minimum:
Project Planning
Defining new features
Time estimating
Ability to organise tasks by priority
Project Management
Tracking active tasks
Reporting
Bug Tracking
I would also like to let other staff easily submit new bugs in the applications which they find or customers report. Additionally support for them to add new stories / high level tasks would be of use so they can note down other new requirments/features and I can then work with them to outline more detailed tasks and estimates.
So far I have looked at a number of systems including:
FogBugz - Seems great for bug reporting but would need something else for project planning / management
Agile Buddy - This is probably the best solution I have found so far
Trac
Smart Sheets
Pivotal Tracker
However, as I have not actually used any of these systems myself I do not know what ones would be best or whether there is a better solution out there??? So any recommendations you can provide would be much appreciated.
Actually, FogBugz does project management as well. It will even try to learn how accurate time estimates for features are from each user, and give you estimated milestone completion times accordingly, with probabilities of finishing at various dates. I've used it for the bug tracking, and really liked it, but I've also read enough about its project management features to know that it has them, and they're pretty good.
FogBugz feature list
When I was working as a solitary developer, I picked up a copy of Planning Extreme Programming and bought a pack of 3x5 cards and a plastic box for them. I used those in the Planning Game and stuck the ones I was working on on my wall. My boss could walk by and see what I was working on. This worked well and cost little.
We're currently using Zen at work - it's a web-based Kanban board for planning. This is nice when your stakeholders aren't co-located or if priorities/requirements change frequently.
You can enter bugs as user stories with either system, or you could use a separate defect-tracking system.
I'd question if Scrum is suitable for a one-developer shop. It's targeted towards project management. I'd rather not have a stand-up meeting with myself. ;) XP (minus pair programming) works fine for a solitary developer.
For a one-man show, you don't need any tools to speak of.
Tools -- generally -- are for coordination.
If it's just you, what -- precisely -- are you coordinating?
If you want to make things visible, a pair of simple internally-focused web pages built from static content will do.
Bugs.
Burndown for Features.
That's about it. Use the simplest tools you can possibly use. I recommend using docutils to generate the HTML from plain, simple text.
Don't go tool-happy until you have a large enough team that simple text doesn't work any more.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
So, at my current job we're usually 1-3 developers, 1-2 art directors and 1 project manager on each project, with the smallest ones just being one of each and the larger ones being three developers and two art directors.
I'm looking for a software, combination of softwares or some type of service that will allow us to manage our projects individually, it's important that we're able to manage several projects at once within one system/piece of software (without going through a too complicated setup process for each project) since we usually have 2-3 ongoing projects in parallel.
We need to be able to integrate with SVN, Track bugs/features/request, Put up milestones and some type of agile management a´la SCRUM would be nice.
Preferably it should be able to run on Windows (without to much hassle, ever tried to put up Apache+Python+Svn+Trac on the same Windows 2003 server and get them all to run together? not fun.) since we mostly do .NET development and most of our servers run Windows 2003.
Since you seem to have a maximum of six people working in a single room - I'd give serious consideration to not using software at all.
A whiteboard & cork board for each project, plus a whole lot of index cards / stickies can go a long, long way towards meeting the project management needs of one or two small projects.
(Failing that - I've found basecamp a fairly lightweight tool for small projects - although it doesn't do any sort of source control integration. I've also heard good things about the latest FogBugz - but I've had such bad personal experiences of earlier versions I've not tried it yet myself)
http://www.project-open.org/ covers your requirements and is available for Windows. However it is targeted at larger organizations (>20 employees), so that you might find it overkill for a group of 6.
I personally use BaseCamp for my company and have had great luck with it!
Edit oops, I didn't notice the SVN requirement, BaseCamp can help with the other stuff.
You might want to try out Mantis (www.mantisbt.org). It is a little cumbersome at first, but with a little bit of customization, it will work for you. It has SVN integration, and a bunch of other stuff which I haven't used yet... :|... such as Mobile support, Wiki support, etc.
And it's OSS (Open Source Software). Written in PHP, works with MySQL, or PostgreSQL. Just check it out, it's good.
http://www.mantisbt.org/
Atlassian's Jira Studio sounds like exactly what you need. It's hosted, so there's nothing to install.
If you want something that is quick and easy to work with that integrates well with Windows I would suggest Microsoft Office Groove. I have been using it on my current project and it also easily allows you to start new projects and add members.
It is not the best solution in the world, but it is included with Office '07 and it has tools to help with project management, bug reporting, calendar, meeting summaries, etc.
The one major problem I have found with it is that version control is not included by default. From what I understand you have to setup a SharePoint server to have version control in Groove, but I have not done this yet and have been hoping that my backups will work fine.
+1 for starting out with a whiteboard, stickies and whatever other office supplies you can think of. Being able to visualize the state of your project in a big visible wall can be really useful, more so than software-based tracking, IMHO.
You need to make sure the team is committed to keeping it up-to-date, though.
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 5 years ago.
Improve this question
We have MS Sharepoint -- which isn't all bad for managing a task list. The data's publicly available, people are notified of changes and assignments.
I think that Bugzilla might be a little easier for management and reporting purposes. While there are some nice Open Source Scrum management tools, I've used up a lot of my political capital and can't ask for too much more than what we've got now. Money isn't the object -- obviously -- it's the idea that my team has too many specialized tools.
Will Bugzilla work out as a more general project management tool -- outside the bug fix use cases?
Will I be bitterly disappointed and wish I'd downloaded something else and made my case for a better project management tool?
Bugzilla Is a great bug tracking system. We have tried to use it for other project management tasks and the results are less then stellar. I would recommend finding something designed with your goals in mind.
Try it for yourself.
Get a $15/month account at wush.net and use it yourself for a while (no business relationship besides satisfied customer).
Bugzilla is powerful and has a lot of configuration options, which can be confusing.
I personally used it three years ago on a project I was working on. I had no project manager and I was the developer, so I needed a very-light-overhead systtem. Bugzilla gave me that. I put my main goal as an enhancement "productionalized system" and then I made dependencies to reach that point. I ended up having 160 nodes all dependent on each other. This essentially was a work breakdown structure. I didn't bother with time estimates, and I didn't bother with creating any other kind of project documentation.
A cool advantage was that as I coded, if I noticed something needed to be done, I would just pop it into bugzilla (20 second process once it's set up), tie it as a dependency, and go back to what I was doing.
Whenever I completed a task, I would look at the dependency diagram and find the outermost leaves (bugs that blocked other but weren't themselves blocked), and work at it.
The advantage of this method for me is that if a task had looked simple and had one node associated with it, but when doing the thing itself I realized it was more complex, I would just split it into different subtasks. This took only a minute and absolutely didn't involve a meeting with a project manager.
Other people on the team could track my progress by looking at open bugs, closed bugs sorted by dates, etc. They saw action, they left me alone. When I had external dependecies, I would make a bug, detail the work, and send that person a link via email. They could then see why this was needed by looking at the dependency diagram.
Note that unless previously agreed upon, I did not assign them the bug.
It worked really well and the system was ready one month early.
How will it work with SCRUM? Having only had a cursory glance at scrum I can't tell you. But that was my experience.
Using a dedicated host will allow you three things:
support
easy upgrades (unless you got gurus in-house, bugzilla management ain't easy--for me at least)
users across organizational boundaries.
Note that bugzilla has all sorts of security features, so it's easy to lock-down the users to what they need to see.
My stand-alone solution is DokuWiki + MantisBT + Subversion + Review Board, which can be integrated with relative ease. Hosted alternative is Bitbucket.org. The rationale is you write user stories on Wiki and can reference them specific tasks. Larger bugs can be collaboratively designed and the "wiki" link is provided on the bug report by Mantis. Review board lets you do peer code reviews against svn diff before change is committed.
We've used Trac and Subversion very successfully for several projects.
The main advantage here is being able to tailor reports, some very Scrum specific, to provide information to management.