We are already using Redmine internally for issue tracking.
Now we also need to track the inventory and maintenance history of equipments of a customer (which should be able to connect and change the state/location of their equipment).
Which Redmine plugins would you recommend for this purpose?
I don't know your exact requirements but you may find the following plugins helpful. You may build your own plugin on top of these with some customization as per your requirements so that its compatible with the latest version of Redmine.
http://www.redmine.org/projects/redmine/wiki/PluginEzlibrarian
https://github.com/danielanguita/Redmine-Inventory-Manager
Related
I have done quite a bit of looking on the Redmine website, and executed a number of Google searches, but I have not been able to find an answer to the difference between Redmine 2.x and Redmine 3.x
I imagine that, much like Redmine 1 vs Redmine 2, it has to do with the version of Rails that the platform is built on, but I would be interested to know a little more in-depth about the differences and compatibility.
I imagine, also, that plugins are not compatible between the two versions, so this leaves one to wonder, what are the benefits of using one over the other?
Edit: I do see the Rails version difference listed on the Installation page. What is the difference beyond that?
We using Redmine at work, with version 2.3.3
And now we wanted to upgrade to new versions (security updates).
We asked the same question.
And what I founded:
from their news page
This new version brings several improvements to the search engine (it's now much faster and includes new search options) and many new features: default issue status per tracker, multiple emails per user, ability to edit attachment descriptions and more
from their Changelog
...
Feature #13849: Grouped filters in the filter drop-down
Feature #13051: Support any macro in (pdf) export for wiki's and issues
Feature #12097: Multi Thread Support
Feature #8818: Repository user-mapping with multiple email addresses
Feature #11702: Add user/group to multiple projects at once
Feature #4244: Multiple email addresses for each user
Feature #1326: Add / edit an attachment description after upload
...
and more
Recently Sitecore 8 has released and it has came up with lot of exciting new features. So our team decided to move from Sitecore 6.6 to Sitecore 8. Before migrating, i would like to know what all things i should be having in handy. Such as, .net Framework, Hardware configuration, environment etc.
Also, i would like to know the procedure to migrate from 6.6 to 8? I, never involved in sitecore migration project before. Please suggest me some good articles or post here your thoughts.
Thanks in advance. :)
See the Sitecore Compatibility Table for the .NET Framework, SQL Server version and Windows version.
Two common approaches.
1) Follow the Sitecore upgrade path.
2) Package the content, and start with a clean install.
Currently I working on a upgrade with an scripted upgrade that follow the Sitecore path. So I can easy repeat the steps and have the latest content in the databases.
I have some of my findings put down here Sitecore update and modules this article contain also a Related links section. Such as the upgrade white paper from Varun
Depending on how 'cluttered' your existing instance is, you may also want to consider installing a fresh copy of Sitecore 8 and then migrate your data/code to avoid all the hops that would be necessary to get to 8.
May be the following blog might help. Take a look at it.
https://varunvns.wordpress.com/2014/11/11/sitecore-version-upgrade-whitepaper/
I would recommend you make a backup of your site to use as a "sandbox" for the upgrade. Copy your databases and the web root for your site to a new location and then set up an IIS site with appropriate permissions pointing to your copy, and change your connection strings in the copy to point to a copy of the databases you backed up.
Perform the update there and ensure everything is working correctly. Work slowly to make sure you are following instructions correctly and note any special actions you had to take to perform the upgrade. Once you have it upgraded, perform the same process on the "real" site.
If you work with a Sitecore partner, I would highly encourage you to discuss the process with them to learn more specifics about the risks and challenges you may encounter during your upgrade.
The general guidance appears to be to install Sitecore into one folder, e.g. D:\Websites\MyWebSite and then create your Visual Studio project in a separate folder, e.g. C:\Projects\MyWebProject. You would then publish your custom code into the Sitecore folder from Visual Studio (This video explains what I’m describing https://www.youtube.com/watch?v=i3Mwcphtz4w around 13 mins in).
I have the following questions:-
Do people only store their Visual Studio project in source countrol and not the Sitecore code?
The publish option from VS into the Sitecore folder only has options for adding files or deleting anything not in the VS project. How would files removed from the VS project ever get deleted without doing it manually?
We use web-deploy to publish sites to staging and live environments. In this scenario would you publish from your VS project or would you set up a way to publish the Sitecore folder (if so how)?
Is this actually a good set up to have or do you do something different?
I did a lot of research on this when we started Sitecore development a couple of years ago. I remember reading a post from Sean Kearney that made a lot of sense to me: http://seankearney.com/post/Visual-Studio-Projects-and-Sitecore
We ended up using this approach for both large and small scale projects and it has been great. You will also want to look at a couple of other tools:
Team Development for Sitecore (TDS) from Hedgehog Development (http://www.hhogdev.com/products/team-development-for-sitecore/overview.aspx)
CopySauce from Igloo (http://www.igloo.com.au/blog/copysauce-igloos-sitecore-development-utility/)
SitecoreRocks for Visual Studio
So to answer your questions:
All of your code and some of the Sitecore items are stored in source control. The approach you want to take is to only store new Sitecore items (layouts, sublayouts, templates, etc) that you create along with any items you may need to customize. You do not need to store all of the sitecore source, content or modules...just what you would need to reapply to get a fresh environment up-to-date. You can manage this manually but a tool like TDS makes this MUCH easier.
We use TDS to manage the publish/deploy to each of our environments. TDS has configurable settings for handling items that have been deleted, including the ability to move it to the Sitecore recycle bin or simply remove it. You have to be careful with this but it does work.
We use a separate build environment to assemble and run deployments using TDS and Jenkins. Basically, all of the code is retrieved from the source control system to the Sitecore server and built using MSBuild and TDS. In most cases we use a webdeploy directly to the Sitecore webroot, but for production we build TDS packages and then run them on each Content Delivery Server
We have used this setup for 7 sitecore projects so far and I am very happy with how it has worked out. We have questioned whether TDS is worth the license fee but the answer always comes back as a yes. The alternative is not very appealing for our development staff and time savings far out-weigh the costs.
Everything is stored in Source Control!... just not always in the same area as they reside on the web server. Storing the Sitecore folder in source control is a good idea as there are changes that you will have as you install modules, but you do NOT add the Sitecore folder as part of your solution/project and should really be there to pull from if need be and not something that is even tracked/monitored.
Once Sitecore is installed, create a new project that resides in the website folder and only add things like the properties folder, layouts, xml and other folders that you want. I don't even include the app_config in my project. Oh and to be clear, it's probably best to just keep the Sitecore folder as a sort of reference folder in your source control but not as part of your website trunk. We have it on the ignore list for website folder in source control. However, that being said, keep in mind that you will NEED to have it in your website folder.
Technically speaking, the recommended approach is to install Sitecore on to the server itself as a stand alone empty instance.. like using the installer with the client mode (not full) so that you get the framework for an empty site in place. Then you can create the deployment package/packages/whatever and it will all be your own code. You should really never have to mess with changing/removing the base Sitecore file system manually.
See above. Generally speaking, unless you have a reason to do so: install Sitecore as an empty instance... then manage your code/files via deployment and just leave the Sitecore folder files alone. You will have very little reason to ever touch them or the Sitecore folder itself outside of an upgrade.
Adding Sitecore itself to source control should be avoided, since you won't be deploying Sitecore as part of your implementation. For modifications to Sitecore itself, you would need a way of handling those inside your implementation, but the config patch system and other mechanisms provide the means for this.
Redundant files in the web site folder will only be a real problem in your development environment. When publishing to a demo environment or to a live environment, you will only publish the material that you actually want. And the deployment-based setup opens up the possibility of always starting from a clean Sitecore installation - as long as you include your Sitecore modifications as part of your implementation (which is not covered in the video). So there is little risk of this being a problem in real life, and the development method in the video makes eliminating this risk entirely possible.
The Sitecore installation should be handled outside of the deployment of your implementation.
It's a good setup, because the method in the video is the method Sitecore recommends for development, and it is also the method Sitecore teaches to developers in development courses. The most obvious advantages of this method are
Clean separation between your web site implementation and the Sitecore installation. There is no risk of accidentally mangling the Sitecore installation, and there is no risk of forgetting unmanaged manual modifications to Sitecore that are needed to run your site. This separation is hard to accomplish if you're not using the method in the video.
By using publishing to deploy your implementation, you know that your implementation is deployable on top of a clean Sitecore installation - and works. This means when deploying to a production or demo server in the future, things will work the same and there will be no surprises. This is very hard to be confident about if you're not using the method in the video.
To test your implementation on a different version of Sitecore, you can just deploy to a clean installation of a different version. This is very hard to test if you're not using the method in the video.
There is sample source code for the video on GitHub, along with instructions on how to set up the development environment, including the publishing parts. This sample source directly and indirectly answers some of your questions.
We are planning to move over our project management to Redmine and also our Git repositories from Github to Redmine. Are there any potential hazards or drawbacks we should consider? We are a growing team. We will be using these across cross functional teams. Members will range from 20 to 60 or more (in all teams).
I can only suggest you look at this list of issues on the Redmine project's site - naturally, they use Redmine to track them.
We have been using Redmine for a year now (although not with git), we have about 15 users, and have not experienced any issues with it.
If you are concerned about stability, it might be an idea to use an older version with no known serious bugs, rather than the latest version.
I have customized Redmine for our team here. It is a great piece of Software with some really useful and agile-focused plug-ins. We use Redmine Backlogs, stuff-to-do plugins which are great. I was wondering if anyone was successful in setting multiple repositories in a single project? I know that I can create a sub-project and set up a different repo. But there could be cases where there is a need to have more than one repos in the 'Repository' tab of Redmine(For example code might be in development environment initially and then moved to staging and production and so need for two repos for a project) and also to get the issues associated with the commit messages. That is one of the drawbacks for some people.
This could get mandatory if you have a pre-commit hook to refer to issue numbers.
I'm attempting to get an understanding of what is a best practice / recommended setup for moving information between multiple Sitecore installations. I have a copy of Sitecore setup on my machine for development. We need a copy of the system setup for demonstration to the client and for people to enter in content prelaunch. How should I set things up so I people can enter content / modify the demonstration version of the site and still allow me to continue development on my local machine and publish my updates without overwriting changes between the systems? Or is this not the correct approach for me to be taking?
I believe that the 'publishing target' feature is what I need to use, but as this is my first project working with Sitecore and so I am looking for practical experience on how to manage this workflow.
Nathan,
You didn't specify what version of Sitecore, but I will assume 6.01+
Leveraging publishing targets will allow you to 'publish' your development Sitecore tree (or sub-trees) from your development environment to the destination, such as your QA server. However, there is potential that you publish /sitecore/content/home/* and then you wipe out your production content!
Mark mentioned using "Sitecore Packages" to move your content (as well as templates, layout items, etc...) over, which is the traditional way of moving items between environments. Also, you didn't specify what version of Sitecore you are using, but the Staging Module is not needed for Sitecore 6.3+. The Staging Module was generally used to keep file systems in sync and to clear the cache of Content Delivery servers.
However, the one piece of the puzzle that is missing here is that, you will still need to update your code (.jpg, .css, .js, .dll, .etc) on the QA box.
The optimal solution would be to have your Sitecore items (templates, layout item, rendering items, and developer owned content items) in Source control right alongside your ASP.NET Web Application and any class library projects you may have. At a basic level, you can do this using built in "Serialization" features of Sitecore. Lars Nielsen wrote an article touching on this.
To take this to the next level, you would use a tool such as Team Development for Sitecore. This tool will allow you to easily bring your Sitecore items into Visual Studio and treat them as code. At this point you could setup automated builds, or continuous integration, so that your code and Sitecore items, are automatically pushed to your QA environment. There are also configuration options to handle the scenario of keeping production content in place while still deploying developer owned items.
I recommend you looks at the staging module if you need to publish to multiple targets from the same instance, i.e. publish content from one tree over a firewall to a development site, to a QA site, etc.
If you're just migrating content from one instance to another piecemeal, you can use Sitecore packages which are standard tools to move content. The packages serialize the content to XML and zip it up and allow you to install them in other instances.