We have created multiple RAML file in Design Center (Anypoint Platform - Mulesoft). We are working in team so multiple users can edit that RAML file by creating separate branch. Now I want to merge those branches into master branch. How can I do this?
Currently the documentation says that branches can not be merged back:
A new branch is a fork of your project and cannot be merged back into the master branch.
An alternative is to download the API from both branches, uncompress into separate directories, then merge them manually using tools for your operating system, like windiff, command line diff or some other equivalent tools.
Related
I now have several branches that have all been merged into the master branch:
I have yet to create a tag and officially release this edition.
So when is the best time to remove your merged branches? I noticed in TortoiseGit that when you merge the branch there is a check box for Delete Branch.
Thanks for your advice.
Depends on your workflow. But generally after merge.
A common workflow is:
merge to develop (if you have a build server, see that the build is ok)
delete local branch and the tracking remote
Twist to the standard “SQL database change workflow best practices”
Background
ASP.NET/C# Web App
MS SQL
Environments
Production
UAT
Test
Dev
We create patch scripts (XML and sql) that are source controlled in Mercurial. We have cmd line utility that installs patches to DB (utitlity.exe install –patch) from a Release folder the build packages. Patches have meta data that helps with when patch should run and we log patches installed in a table in the target DB. All these were covered in the 3 year old question:
SQL Server database change workflow best practices
Our Problem/Twist
I think this works well for tables, views, functions and stored procedures. We struggle with application configuration data. Here are some touch points on application configurations.
New client. BA performs system study and fit analysis. Out of this comes a configuration word document of what application configurations need to be setup. Note some of these may also come in phases over time. We need to get these new configurations into the system for the developer and client UAT.
Developer works on feature request or bug fix. A new configuration change comes out of that change. The configuration needs to make it into the system for testing and promotion to UAT and up.
QA finds that the developer missed an associated configuration change. That configuration needs to make it into the system for promotion to UAT and up.
Build goes to UAT. Client performs acceptance testing but find they really want to change another unassociated configuration and have it promoted with the changes. In other words they found they want to change a business process by a configuration. The configuration needs to make it into the system for promotion to PRD.
As the client operates in PRD they may tweak application settings. These configurations need to make it into the system for future development and testing.
The general issue is making sure we are accounting for all the configurations and accidently not miss any during promotions which causes grief.
Our Attempts At A Process
a. We have had member of the QA team to write patches (xml and sql) and check those in. This requires a build to make sure those get into the package. With this approach it really just took care of item 1 above and we fell apart on the other items. The nice thing is for the items that made it into the patches it was just an install with the utility.
b. A developer threw together a Config page on the application. All the configurations could be uploaded and downloaded via XML document but it requires the app to be running. For item 1, member of QA team would manually setup configurations in the application and then would download the Config.xml file. This XML file would be used to upload configurations in other environments. We would use text diff tool to look at differences between config.xml files from different environments. This addressed item 1 and the others items but had problems. Problems were not all configurations made it into the XML document (just needs to be fixed by developer), some of the configurations didn’t have a UI in the application so you still had to manually go to the database on some, comparing the XML document with text diff was difficult at time (looked mostly due to sorting but I’m sure there are other issues), XML was not very human readable and finally the XML document did not allow for deleting existing incorrect or outdated configs.
c. Recently we went with option B, but over time for a new client we just started manually tracking configs and promoting them manually by hand (UI and DB) through the promotions. Needless to say lots of human errors.
So we have been looking at solutions. Eventually it would be great to get as much automation in as possible. I’m looking at going with the scripting approach and just focusing on process, documentation and looking at using Redgate data compare in addition to what we had been doing with compare on config.xml. With Redgate we have to create views though and there is no way to create update scripts from that approach except to manually update the scripts. It does at least allow a comparison without the app running. I’m also looking at pulling out the configs from our normal patches and making it a system independent of the build (utility.exe –patch –config). When I say focus on process it will be things like if we compare and find a config change either reported by client or not, we still script it, just means we have to have a process in place to quickly revalidate config install before promoting to the next level. As for documentation looking at making the original QA document a living document instead of just an upfront document. The goal is to try and enhance clarity and reduce missing configurations during promotion. Unfortunately it doesn’t improve speed of delivery.
Does anyone have any recommendations or best practices to pass along. Thanks.
Can I ask exactly what you mean by application configuration. I'm interpreting that as both:
Config files in the web application
Static reference data inside the database
Full disclosure I work for Red Gate. You might be interested in taking a look at Deployment Manager, it's a deployment tool that deploys applications, databases and configuration. It's free for up to 5 projects and target servers.
The approach it uses is to package application code and the database state into packages. These packages can be deployed into dev, test, staging and production environments. The same package is deployed to each environment.
Any application configuration that needs to change between environments is handled in one of the ways below:
Variable substitution in web.config. The tool allows you to specify override values for variables in these files, and set these per environment/server
Substituting the web.config file per environment.
Custom powershell scripts that are run pre/post deploy. You could use these to execute custom SQL based on the environment or server.
Static data within the database, using SQL Source Control's static
data feature. I've written a blog post about how to supply
different sets of static data to different environments/customers.
This allows you to source control the application configurations and deploy them to different environments.
I am running Sitecore 6.5
I have two installations of Sitecore and want to transfer a whole site from one installation to another.
Have found a few articles that go into Serialization and Creating a Package although they don't go into detail about how these two fit together.
How do I transfer a site from one installation to another?
thanks.
Create a package with the package designer.
include these items and their children with the button "items statically". if you have placed your solution specific item in folders, it is only needed to include these.
/sitecore/content
/sitecore/layout
/sitecore/media library
/sitecore/templates/ (only take the templates you have created. e.g. the folder user defined
using the button "files statically", include the folders with you have solution specific changes to like:
/bin
/layouts
/app.config/include (only take the files changed in the solution,
compared to a default sitecore installation)
web.config (if you have made changes to this, compared to default
sitecore web.config)
if you have any user accounts you want to transfer to, you can include them with "security accounts".
then generate zip file and install on empty sitecore and full publish :)
If your systems are similar enough, you may want to consider moving the Sitecore DBs via backup/restore (in SQL) and copying over filesystem assets. Generally I find this faster and less prone to user error than creating/installing very large packages. (Just remember to take back-ups first.)
Large packages have a tendency to break, one option would be to look into this:
http://www.hhogdev.com/Products/Team-Development-for-Sitecore/Overview.aspx
TDS can sync all your items to XML on your dev box and from that you can create a different sort of installation package which is significantly more robust than a regular package you create through the Sitecore desktop. It's the same sort of package that Sitecore use when you upgrade versions.
I believe there is a 60 day trial on this product so plenty of time to try it out.
Note: when transferring user accounts, passwords will not be migrated when using either packages or serialization.
Solution is here - cowboy-aspx from Sitecore :)
https://kb.sitecore.net/articles/242631
I am using ProjectLocker as my SVN server.Stuck at Files Synchronization at run time with Local DB Files. I am using Tortoise SVN.
From your comments, it sounds like you may not be familiar with some version control concepts. For new Subversion users, I recommend Chapter 1 of the Version Control With Subversion book. This will explain what a working copy is in more detail, and how Subversion keeps your data. Chapter 2 has more information on a basic work cycle. ProjectLocker takes care of all the svnadmin steps for you, so you can ignore those and look at how to check out, update, and commit.
The first thing you should do is to create a staging directory where you keep any files that you're doing development on. You may need to copy your PHP, CSS, DB files and so on to that location. You then run the TortoiseSVN equivalent for svn import to upload all the files to your server. Once you've imported them, back up the directory you just created, and create an empty working directory. Run the TortoiseSVN equivalent of Subversion checkout and you will pull down all the files in your repository. Once you have that, Subversion will take care of identifying which changes can be merged and which will need manual intervention as you make changes, run updates to pull changes from other users, and commit.
If you wish to upload files to a remote location after commits and you have a paid account, you can use ProjectLocker's remote deployment solution to FTP a particular Subversion directory over to your actual server for deployment.
I apologize if this is a little vague, but the scope of your question is quite broad, and so I wanted to give you as concise an answer as possible while still addressing your needs.
I'm looking for a tidy way to manage my cross-platform HTML+JS projects in github.
Here's my typical working process:
I complete developing my app for ios
I start working on Android platform version
I start working on XXXXXXX platform
...
From step 2 and further I come out with:
commits that can be merged in the Head repository
commits that can not be merged, so I have at least 2 versions of some of the files that compose the project
My problem is that forking/branching for each platform force me to duplicate changes on the shared part of the project too. Maybe there's something that I'm missing in both branching and forking.
Which method you use to organize your code on github so as to preserve both the differences and the unity of the project?
It sounds like branches might be the way to go: create an android branch, etc., and if you need to branch those further then create android/branch1, android/branch2 and so forth.
When you need to merge files between branches you might want to use the git cherry-pick command to select the commits to merge. I would also probably do this on a temporary local branch before pushing, to make it easy to recover from screw-ups!