Close

Copyright © RebelMouse 2019

Follow Us:

GIT Workflow

This document is written to give an overview on how to work with your BitBucket on RebelMouse integration.

Using GIT

Since you are using your own GIT repository on Bitbucket which is totally separated from RebelMouse repository , you can maintain your repository as you wish. This allows for a lot of creative freedom in using the environment the way you'd like.

While you can use your own workflows, we still highly recommend our suggested workflow described in next steps.

I am new to GIT

Start by reading this GIT reference first http://gitref.org/. You can skip the part about "Getting and Creating Projects", everything else is quite useful.

Comparing GIT workflows

You can find a really good tutorial about different GIT workflows at https://www.atlassian.com/git/tutorials/comparing-workflows, which we highly recommend reading. especially Feature Branch Workflow. The most vital and necessary commands are listed in this tutorial as well.


Daily workflow example

As mentioned before Feature Branch Workflow is approach which we highly recommend to stick with. It means that for every new feature (or any bug you will fixing) you will create a new branch. All changes for that feature then should be in this branch. This way your master will be always clean and ready for syncing with our master.

This tutorial contains also other commands. Before start please read topics about VIM and Nano and Custom Roar Commands.

Switch to master branch, be sure that you are on it with git status. You can also check if there are any changes with git diff command.

git checkout master

Rebase the master. This will take down all changes (which other developers in your team have pushed to origin) from BitBucket repository to your local repo.

git pull --rebase

Fetch new changes. This will take down all changes (which other developers in our team have pushed to origin) from GitHub repository to your local repo.

roar-fetch

Check if there are any changes.

git status

If there are any changes you need to commit them.

git commit -am "updates from RM repo"

Push new changes from local master branch to your origin master branch.

git push origin master

Let's say you would like to start working on a new feature. Create a new feature branch. Please respect the TICKET_NO-lower_case_with_underscore naming.

git checkout -b 12345-new_branch_name

Open and edit file which you need to update. I will work on article.css with VIM terminal editor for this example.

vim static/css/roar/article.css

Every time you want to check your changes in browser you need to run roar-reload.

roar-reload

All templates are cached. This command reloads your environment and applies your recent changes; without running it you won't see any updates in the browser after refresh. You don't need to run this command when you've edited static files.

Check your beta in browser now. If you are satisfied with your changes and new feature looks okay, you should push this changes to your repo first.

Verify your changes one more time.

git diff

Commit your changes with meaningful commit message. Don't forget to include #TICKET_NO at the end.

git commit -am "updated colors on article page #12345"

Push changes to your repo.

git push origin 12345-new_branch_name

After this you are ready for pushing to stage server. Please note that you can push to stage server from any branch. Branch which you are currently on will be deployed to stage.

roar-push-stage stage_name

URL of stage server will be outputted in this step.

If everything looks okay, you can proceed with pushing to production. Pushing to production is possible only from master branch. Before that you need to fetch latest code from BitBucket and GitHub repo. This way you will be sure that your changes looks well even with latest code. It could happen that in meantime someone else has made changes in the same file you were working on. It is necessary that code is synced. You need to repeat the steps which we made in the beginning.

git checkout mastergit pull --rebaseroar-fetchgit statusgit commit -am "updates from RM repo"git push origin master

Then merge your feature branch into master.

git merge --no-ff 12345-new_branch_name

In most cases everything will be okay after this. But from time to time you will get merge conflicts. You will be notified about them in terminal and you need to solve them manually. This happens because someone else were working in the same time, on the same lines in the same file as you do.

Just before pushing changes live, please verify that everything still looks okay on your beta.

roar-reload

Check your beta in browser. If everything is okay, you're clear to push your updates live.

roar-push-prod "A meaningful message explaining new updates."

Deployment could be blocked by other developers at any given time and deploying itself could take up to 20 min. In this process your feature branch will be also pushed to BitBucket.

When deploying will be done, you are able to check your changes in browser on live site.

You're not required to stick with this workflow, but it is helpful. If you are good with GIT, you can use it on your own way. Then all you need to know are our 4 roar-[...] custom commands.

Publishers No Longer Have to Submit Their Site to Google News

Google's Publisher Center creates new opportunities for audience growth

Just before the start of the next decade, Google announced an important change to its Google News offering with the launch of Google Publisher Center. The new interface merges Google News Producer and Google News Publisher into one to streamline the partnership process for publishers.

Overall, the change should make it easier for publishers to manage their Google News settings, including updating themes, directing URLs to section pages, and configuring user permissions. Read the full list of features here.

Keep reading... Show less

How to Find Work-Life Balance as a Remote Employee

Tips from our CEO on making the most of an office-free lifestyle

Working from home is becoming increasingly popular, with an estimated 66% of companies now allowing remote work and 16% operating completely office-free. RebelMouse is one of those fully remote companies, and over the years we've mastered how to stay close to each other despite being spread across more than a dozen countries. We believe working remotely is good for both our personal lives and our productivity. Read more about this here.

Still, working free from the shackles of an office environment doesn't mean every day is a dance party in your pajamas from 9 to 5. Working from home comes with its own set of challenges just like any other job.

Keep reading... Show less

Inside RebelMouse’s Quality Assurance Operations

How We've Perfected Stress-Free Publishing

At RebelMouse, we like to refer to our enterprise publishing platform as "lean tech." Most publishers have a natural inclination to start doubling down on teams of developers who try to build unique experiences to help stand out above the noise. But they should actually be doing the opposite: Lean tech is the preferred way to cut through content saturation. By allowing RebelMouse to obsess over your product, content producers, editors, managers, and everyone in between can focus on creating quality content and taking advantage of opportunities to leverage distributive publishing strategies that create real revenue growth.

One of the major reasons we're able to maintain a lean tech environment is thanks to our approach to quality assurance (QA). We make updates to our platform daily to ensure our clients always have access to the most robust, high-performing, and secure version of our platform. Behind the scenes, this means having a solid QA structure that's efficient, creates less bugs, and catches the ones that do pop up before they go live. It's a system of checks and balances that's hard and costly to replicate on a custom CMS. Here's a glimpse into how it works.

Our Tech Stack Toolbox

  • Cucumber
  • Java
  • Junit
  • Maven
  • Selenium WebDriver
  • TeamCity
  • Zalenium (Selenium Grid)

Our Checks and Balances Workflow

Automated Regression Testing Cycle

The Lifecycle of a Product Update

When an update is first made to RebelMouse, TeamCity immediately triggers the start of automated tests to review integrity.

TeamCity Build

TeamCity Agent

The tests run in parallel on TeamCity's Build Agent. Next, Zalenium creates docker containers with browsers that matches the count of parallel threads. An Allure report is then generated from the test results, which shows the state of the application after the update.

Allure Report Pass

If a test doesn't complete successfully, the testing framework receives a video with a failed test and attaches it to the Allure report.

Allure Report Issue

Based on the report analysis, a QA specialist will create a "bug" ticket in our product management software to address the issue if needed. Then, information about the bug is immediately sent to the project manager and we begin the process of correcting the problem.

The media powerhouses we power can publish with confidence knowing that any product issues that arise are met with a tried-and-true process to fix the problem with little-to-no disturbance to their workflow. If you have any questions about this process, please email support@rebelmouse.com.

Related Articles

Subscribe to Our Newsletter