My team currently is using TFS 2010 for source control, builds and project management. We are moving to Git for source control, Cruise for builds, and Redmine for project management. We are using Git-Tfs right now to integrate our source control with TFS, and cruise is a pretty trivial setup, my question is about project management migration.
Are there any processes or tools to migrate the issues, bugs, tasks, and user stories from TFS to Redmine? Has anyone done this before?
Really when it comes to importing into Redmine the best bet is to use the REST API (http://www.redmine.org/projects/redmine/wiki/Rest_api_with_ruby). This requires that you export your data from TFS in some way (best bet is as a csv or tsv) and with a little ruby code iterate through your data and make new issues.
I don't know what tools TFS has built in for exporting data, but as a csv isn't uncommon, and at the least with access to the SQL back-end and an SQL script you could create a csv manually.
The import into Redmine normally requires coding, but there are plugins as well (http://www.redmine.org/plugins/issue_importer_xls).
Related
I created a Project on GCP. It has a postgres database, a node Appengine web app, and some other stuff. Now I am developing the app, and when everything is set up and running nicely I'd like to clone this project somehow and create a staging and a production environment/project.
So my project now is called dev-awesomeapp. Can I somehow make a staging-awesomeapp for staging and a awesomeapp for production from my existing dev-awesomeapp?
Edit: there is an other question from 2017 that asks the same thing, but maybe it's possible now after 2,5 years?
You can't, but if you don't want to configure everything form the beginning each time, you can use "architecture as code" with tools like deployment manager or Terraform.
This could help you in replicating your infrastructure, moreover it can be really helpful in automating any architectural changes if you use it in a CI/CD pipeline, making your release phase quicker and more reliable :)
I've started learning a new stack (oracle-apex-18), and I have a team that is more likely to contribute to my projects. How do I go about having a structure team collaboration in oracle-apex?
This is for team collaboration on oracle-apex projects. I've tried using the team collaboration features, however, this does not solve if someone has to contribute some sort of PLSQL code.
You have to have your database source code (PLSQL and SQL scripts) for all packages, triggers and etc in source files in a Git (or SVN) repository.
If you are talking about source code control, I suggest something like https://liquibase.org/ which should do the trick.
If you are looking for something more in the Git/Free aspect, what I do is export the applications as a ZIP file and upload them to git. The same for CSS, JavaScript a Pl/SQL scripts. I know it is more manual than it should but it works fine for us.
As of today, at the Oracle APEX Road Map they are planning to integrate the tool with GIT in a more direct way, so maybe it would be worth to wait for that
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.
During development, I like the idea of frameworks like Entity Framework 4.3 Migrations (although I need it to work with sql scripts instead of Migration classes) keeping all developer databases up-to-date. Someone does an update to get the latest source, they try to run the application and get an error that they need to update their database to the latest migration (or have the migration happen automatically). Migration files are timestamped so devs don't have to worry about naming two files the same or the sequence the files need to be executed in.
When I get ready to build a WebDeploy deployment package, I want the package to contain the scripts required to move the production database to the latest db version. So somehow, MSBuild or WebDeploy need to make a decision about which scripts must be packaged. For deployment I don't want the application to try to update itself like what EF offers. I want to either hand the package to the IT department or do an auto-deploy through a deployment server.
Some of my questions are:
Can EF 4.3 work with sql scripts instead of DBMigration classes for my development needs (I'm already using it for my ORM so it would be nice if it could)?
Does MSBuild or WebDeploy understand the concept of database migrations (e.g. does it recognize the EF. 4.3 migrationHistory table) or do I have to make sure to give it just the scripts it needs to run that will bring my prod db to the latest migration? Manually deciding which scripts should be pakaged is not something I want to do so is there a MS WebDeploy extension that understands migrations?
Are my concerns and ideas valid? I'm just researching this stuff so I don't really know.
I think that your concerns are valid. During development anything that keeps the developer machines in sync will do. When deploying, more control is needed.
In my project we've decided to only use code-based migrations, to ensure that all databases are migrated in the same order with the same steps. Automatic migration and db creation is disabled by a custom initialization strategy that only checks that the db exists and is valid.
I've written more about the details in Prevent EF Migrations from Creating or Changing the Database. I've also looked a bit into merge conflicts which will eventually happen with multiple developers.
You can run SQL in the classes by calling the Sql method, or generate SQL from a migration by using the -script parameter with the update-database command.
No. They were looking at adding support for webdeploy but apparently decided against it before rtm. They did however release a command line app (and powershell script obviously) which you could call from either.
What I do in my projects is create an startup module in my applications and run any migrations that haven't been deployed automatically - Triggering EF migration at application startup by code. It's not perfect, developers have to run the app after getting latest before changing the db, but it works for both get latest and deployment.
At the moment, we are running our automated (not CI as such) builds via FinalBuilder via a very simple homegrown Apache interface that just launches the FB scripts on our server. (I like FinalBuilder, and will keep it, but it's CI server, FinalBuilder Server just doesn't cut it IMHO -- especially it doesn't support any "agent" concept at the moment to distribute builds across machines.)
We are doing native C++ development on Windows with a bit .NET mixed in where it's needed and makes sense.
Our current FinalBuilder scripts do everything quite well, from creating nightly builds to full releases (build / automated translation / build / unit test / create setup / put created artifacts on a network share / ...), but our webinterface, queuing abilities, user traceability and reporting is pretty limited.
I have looked around and it seems that TeamCity and Bamboo tick similar boxes, but most descriptions I can find cover only Java and/or .NET simple builds.
So my specific question is, given
several (20-30) complicated FinalBuilder Scripts that work to my satisfaction and that I will have to integrate into ("call" from) the new automation/"CI" server
Native Windows C++ and .NET projects
The actual build (= compiler invocation(s)) is done via a few Visual Studio solution files at the moment
Currently one build server machine, wishing to scale to 2-3 atm.
Using JIRA as issue tracker
using AccuRev as SCM
which tool is better suited, and why: TeamCity (currently 6.5) or Bamboo (currently 3.1).
(Note that I also hope to get some highly subjective answers on the TeamCity and Bamboo forums.)
For TeamCity side, it integrates with Jira, has AccuRev plugin, and has a good support for VisualStudio/C++ projects. It can also run arbitrary scripts.
You can trigger a build and obtain some build results via HTTP-based API. In the UI, you can see which changes have been built and in which build configurations. Easily integrate any custom HTML reports into TeamCity UI (no coding), publish artifacts.
Probably, you should try both solutions and see which one is more suitable for you (with Teamcity, you can use full-functional server for free, the only limit is number of build agents and number of build configurations).
Disclaimer: I'm a TeamCity developer
I found Bamboo more credible than TeamCity. Here are my reasons:
Those Jira plugins for VS or Eclipse are Bamboo plug-ins too. :) no extra add-ins needed.
Better support for Jira integration.
Nice user interface, like the one you used for Jira.
Ability to better integration with other Atlassian tools, such as FishEye.
Cheaper. A 10$ license will suffice your company.
More add-ons on Bamboo than TeamCity, lots of plug-ins.
For completeness' sake: I ended up using Jenkins + Finalbuilder. :-)
I worked in a similar environment using FinalBuilder for build automation, AccuRev for source control and a native windows projects.
I ended up selecting Electric Commander as the best CI solution for the job. It is possible to reuse parts of the FinalBuilder scripts and call them from Electric Commander but simply calling the FB script as one build step would result in you missing out on some of the key advantages of using Electric Commander - realtime log file processing, the ability to parallelize right down to individual step levels in Electric Commander and data collection and reporting.
Electric Commander has an API that exposes all product functionality which can be used in combination with AccuRev triggers to achieve a very flexible solution.
Disclaimer - I liked Electric Commander so much I joined the company and am currently employed by Electric Cloud.
You can try Electric Commander by going to www.electric-cloud.com and clicking on "Try It!"