Current Articles | RSS Feed RSS Feed

Using Assembla Repositories with Jenkins via the CloudBees Platform

Posted by adam feber on Wed, Sep 04, 2013
  
  

As a CloudBees Technology Partner, connecting your Assembla Git & SVN repositories with Jenkins CI via the CloudBees Platform is pretty straightforward. The video below or verified CloudBees documentation will walk you through the setup.

By utilizing Jenkins CI in the CloudBees DEV@cloud, you eliminate the need for additional infrastructure and administration. Simply sign up online and configure. Once up and running, the build possibilities are endless. Happy coding!


0 Comments Click here to read comments

Power Up Bitbucket Mercurial with Assembla Tickets

Posted by Sergiy Golub on Fri, Jun 21, 2013
  
  
Tags: 

Integrate your Bitbucket repository into an Assembla project workspace. 

Today, we are glad to announce an integration with Bitbucket that allows you to keep your code in Bitbucket’s Mercurial repositories and use the power of Assembla's Tickets Tool for project management.

Configure in three easy steps

1. Install the Bitbucket Tool by visiting the Admin tab of your project workspace > Click the "More" button within the Tools section > Under the Repositories section, click "Add" next to Bitbucket.

2. Put your Bitbucket URL in Bitbucket Tool Tab:

assembla bitbucket

3. In Bitbucket, configure Post service by copying URL from Assembla Config:

assembla bitbucket2

Update tickets with Bitbucket commit messages

assembla bitbucket3

  • Link tickets to commits - use “re #1” or “re assembla-1” to reference a ticket in a commit message. A comment will be created on the ticket notifying everyone about the commit

  • Change ticket statuses - just naming a ticket status - “Fixed #1” - will place a link in the ticket to the commit and change the ticket status to Fixed.

  • Track time - enter a record of how much time you spent working on a particular task by using  “Fixed #1 Time: 1h30min” to your commit message.

1 Comments Click here to read comments

Server Side Hooks on a SaaS repository? ✓

Posted by Michael Chletsos on Tue, May 07, 2013
  
  

Oh BTW, you can have Server Side Hooks in a SaaS Repository.

Cloud repository hosts have failed us. The power of hosting your repository locally is the ability to implement Server Side Hooks. These hooks allow you to control your repository and the source code contained within.  Its super convenient for an organization with many contributors to a single repository. You can syntax check code, ensure commit messages are proper, add the power of automation or anything else you need your repository to do better than if you were relying on external webhooks.

To add a Server Side Hook in your current Assembla Repository - go to the Settings Page -> Server-Side Hooks:

server side hooks

  • Git: pre-receive, post-receive and update hooks

  • SVN: pre-commit, post-commit, pre-revprop-change and post-revprop-change hooks

  • Community Supported: Submit your own hooks or partake in the fruits of another’s labor

  • Prevent commits that do not comply with your Coding Standards

  • Validate commit messages for status updates and valid ticket reference

  • Create Workflows with specific status and ticket changes or kick off external procs

We are very excited about Server Side Hooks and hope that you find them as useful as we do. Take a look at some of our other available Repository Features.

0 Comments Click here to read comments

Access Control Lists for Your Subversion Repository

Posted by Titas Norkunas on Fri, Mar 29, 2013
  
  

We are happy to announce that we have implemented an Access Control List (ACL) for Subversion directories. ACL workflow allows you to restrict directories so that only certain developers have write permission. This workflow can be enabled at critical times like when there is a feature freeze, or to protect sensitive areas of an application.

Those of you who store multiple projects in a single Subversion repository can now easily configure permissions for your project teams on the directory level. But enough talking, if there isn't a screenshot it didn't happen, right?

Protected Directories ACL Setup

Protected Directories

So how does it work?

  • Specify users who will be able to write to certain directories - they will be the owners of that code
  • Everyone else will be able to see, but if they want to contribute, they will have to send a merge request
  • Directories a person is not allowed to write to are marked with a red lock icon.
  • Directories that a person is an owner of are marked with a green lock icon.
What do you think, do you like this feature? Let us know in the comments!
Learn more about our Subversion features here

3 Comments Click here to read comments

Develop Faster: Set Up Your Git Fork and Merge Network

Posted by Michael Chletsos on Mon, Mar 25, 2013
  
  

A Complete Guide to Setting Up and Working with a Git Forked Network

fork merge smI have spoken often about the Assembla process that we have been working in and how well it works for us, but how can you get the same benefits for your project? Well, there is no secret, its just a matter of setting up a development fork and merge network. The basic idea is to isolate development work from stable work. By isolating, all development work from stable work you have a clear path from developer to production. Although this process is not specific to Assembla, lets see how this will would work utilizing Assembla. One could tailor this process to work in any system, and it would be just as powerful, though not as convenient as with the tools Assembla provides.


  • Setup Development Space

First we need to setup a new space. You can do this from your Assembla start page by clicking the 'Create New Space' button. Depending on your account and plan, you might want to setup a public or private space. It does not matter which type of space you setup.

Create Space

 

  • Setup Origin Git Tool

Great, we now have a place to work within. We need to have a Git Tool, if your space configuration did not have a Git Tool, please add it from Admin tab and then the Tools Heading.

git description

Whether you just created a tool, or it came pre-configured, I highly suggest renaming the Git Tool by going to the Setting subtab. Here you can rename the repository to “origin” and set an extension if you like, for the origin repo, I do not like adding an extension – I like the origin named “project.git”. I like calling it “origin” since this is standard git terminology for the original point of the code.

rename

 

  • Initial Commit to Origin

Now we have a Git Tool renamed to “origin” but no code in it. At this point, we can push code up to this remote repository and utilize it like we would normally utilize a git repo. Just to ensure everything is working, let's make sure we can read and write to the repo. Before you proceed ensure that you have added your public ssh key to your profile (found in the upper-right dropdown menu->Edit Profile->SSH Keys). Once your key is added, follow these instructions (replacing project.git with you appropriate project name) on your localhost to create a local repository that you will sync to the remote repository:


 $ git clone git@git.assembla.com:project.git # will complain that you cloned 
an empty repo
$ cd project
$ echo “Project Readme File” > Readme
$ git add Readme # add Readme file to git tracking
$ git commit -m “Initial commit of Readme file” Readme
$ git push origin master # create a master branch in “origin” repo

 

We have just made our first commit to origin/master. If you prefer you could use the http(s) method to interact with your git repo. Https is particularly useful behind a firewall that does not have port 22 open for ssh (many corporate firewalls are setup this way), while still encrypting your data. Http(s) will have more overhead and therefore slower than the ssh protocol. It does not update your localhost with information as often as the ssh protocol (sometimes it looks like it is hanging when it is working) because it waits between actions before responding to your client.

first commit

You can view this file that was just created in your code browser by navigating back to your Git Tool in Assembla and using the Browse Code subtab. To see the actual commit, take a look at the Commits subtab.

Hint: When committing add status updates such as fixed #123 or re #123 to reference the ticket in your commit message and to post a link and commit message on the ticket.

 

  • Our First Developer Fork

Theory: One could just work in the origin repository. You can branch and commit to origin like you would any other repository, however, this can cause bottlenecks and problems for your development process. Say that developerA commits bad code to origin/master – they discover this through QA, UAT or CI, and developerB needs to perform a critical hotfix to Production. If all are committing to origin/master and deploying this to Production, then we have a bottleneck caused by developerA's bad commit. This commit must be reverted or possibly you could branch before the commit add developerB's commit to this branch, then deploy out to Production this branch. Ugh, that is dirty.

Another model may use release branches to help solve this. Release branches rely on the fact that no-one alters them between releases but takes overhead to cut them, coordinate developers and manage them. This becomes very hard to maintain across many, many developers and does not allow a free-flow of code from developer to Production, instead you must commit to several branches to ensure that you keep your Development branches and Release branches in sync. Often release branches become divergent from Development branches and you cannot patch them easily as there are different codebases and the merge results in conflicts or there is logic missing that is expected.

Instead, we introduce the Developer Fork. The Developer Fork is a repository that is based on origin, but allows the developer to maintain their own repository including branches, tags and commits. It also has one other nice advantage that is a little hard to see at first, but if managed properly, you will not run into strange merge problems with new work – all new work is applied on top of branches that are consistent with your current work. In other words, you will not get any of those annoying, you must merge before you can push errors.

To create the developer fork, go to your origin's Git Tool and then the Fork Network subtab, from here you can choose to fork your project. It does not matter if you do it to another space or within the same space. The considerations made to whether you will fork in the same space or to another space have to do with whether this is a new project being branched, if the developers will work off the same list of tickets, and if you have creation permissions in the space to create this fork amongst many other considerations. For our purposes and the purposes of most teams working on the same list of tickets, it is best to keep this fork in the same space – so that you can reference the tickets in the commits easily.

fork subtab

Once you have forked the repository go to the new Git Tool and rename it and give it an extension that matches the name in the Settings subtab. This will make it easier to talk about and remember where you are pushing code or merging to/from. For our purposes we will call it “fork”.

Advanced: Anytime you clone a repo, you are in fact creating a fork. You can then push this cloned repository to any remote repository. You may also connect any existing repository to any remote allowing you to maintain several remote repositories in a forked network in one local repo, you do not need to create a new tool or new space. If you already have two Git Tools in your Assembla space, you can add a “fork” from one repository to the other repository. Branches in git do not have to have a common ancestor nor do they even have to be related to each other; you can store completely different information in the same repository in different branches for git. So taking our origin/master setup in our space and a new Git Tool called “fork” and with the “fork” extension, we can clone this repository and then push a fork from origin back up to it. There are at least two ways to do it, each with different advantages:


 # Using “origin” repository as your remote origin for your local repository – 
typical for people who have read/write to origin/master
$ git clone git@git.assembla.com:project.git # should have Readme file from before
$ cd project
$ git remote add project_fork git@git.assembla.com:project.fork.git # add remote
for “fork”
$ git push project_fork master # create a master branch in the “fork” repo

# Using your “fork” repository as your remote origin for your local repository –
typical for developer setup
$ git clone git@git.assembla.com:project.fork.git # will complain of cloning
an empty repo
$ cd project.fork
$ git remote add project_origin git@git.assembla.com:project.git # add remote for
“origin”
$ git checkout -b orig_master –track project_origin/master # switch to local
branch “orig_master” and track the origin/master remote repo
$ git push origin master # push the orig_master branch to the “fork” remote
(origin of this repo)

  • Other Developer Forks

You can repeat the process above as many times as you like. I prefer to do this on a per developer basis. But you can easily setup a team that works in branches and has a common fork/master. This is the fork per team methodology. The advantage here is you have a single point of control for batching releases per team. However this same advantage is also a disadvantage where you have a bottleneck if a developer has committed code that is not clean or is waiting on other code.

Theory: The advantage of the fork per developer is that each developer is responsible for their own fork/master, and if they commit bad code or are waiting on other code, they do not block any other developer. This allows releases to occur more often on a per developer basis. If you are not in an environment that can sustain many releases very often, then you would arrange the fork network a little differently. Instead of developers working in the fork of origin, they will work in a fork of the fork – yes a fork of the fork. Just make the fork from the fork of origin, and you will have a repository that can merge easily back to the first level fork (use the fork network for this and just fork from the team fork to create a developers fork that will merge back into the team fork).

 

  • Branching in Forks

Theory: In general it is good to create a new branch for all isolated work, i.e. each ticket that you work on should be in its own branch. This allows a developer to start and stop work, or wait while work is reviewed or QA'ed, but still moving forward with other work.

When working on ticket branches, which I like to call ticket_X where X is the ticket number, are disposable branches. Assembla has created a convenient way of maintaining disposable branches, in your Git Tool Settings subtab, you will see a section that allows you to denote the pattern for naming disposable branches.

disposable

Then when you Merge or Ignore a Merge Request that is based on this branch, the branch is automatically deleted from the repository – truly helps with keeping a clean Development Fork. It is important to understand that even if a branch is deleted, no code is lost, that is the beauty of git, all commits are still present and the branch can be recovered if necessary. Typically, the developer will also have these branches locally still and can push them back up.

delete disposable

 

  • Merging

Theory: The general rule of merging is that you only want to merge from where you branched or to where you branched. If you jump across branches, the merging will work, but it might have seemingly strange results or may affect files that you did not mean to affect. So merge from your fork/branch to your fork/master and from your fork/master to your origin/master but not from your fork/branch to origin/master. That is a simplistic view – I am assuming that fork/branch is always coming from fork/master – but this does not have to be true. And moreover, it will not be true when hotfixes are done.

When merging from a fork upstream to your origin or from a 2nd level fork upstream to the 1st level fork (fork per team), you can create a Merge Request from the Submit Code tab, choosing your fork/branch as the Source (“From”) and the fork/master as your Target (“To”).

merge create

 

  • Code Review

Theory: All code going into your fork/master should be Production-ready code. To ensure this, most teams will need a code review process. The Code Review process in Assembla can be accomplished in the Changeset view, which you can find from the Commits subtab where a reviewer can add comments directly in-line with the code, but more appropriate it can be done from the Merge Request subtab where you will submit a Merge Request from your branch to your master. You will choose your fork/ticket_X branch as the source and fork/master as your target. Then you will set a title and description and have the opportunity to review the new code that is potentially being merged to your fork/master. This is a good time to review that the code is as you expect it, this will prevent any gotchas later.

Hint: Add ticket status updates in your description with the same format that you can use when committing to your repo, i.e. fixed #123 or fixed #tickets to affect all associated tickets, to apply this status update once your Merge Request is Merged. 

Once the Merge Request is created from your fork/branch to your fork/master you will have an interface where the team can have a discussion, including the ability to leave @mentions to alert others to help with code review, a list of the changesets that will be merged, diffs on the files that are changed, and a list of tickets (based on commit messages that include #ticket_num) that are being affected by this Merge Request, in-line code commenting, and of course a place to vote on the Merge Request. If you give it a -1 vote, the system does require you to submit a comment, this is because it is typically not beneficial to just leave a -1 without any comment – whereas a +1 speaks for itself (I highly suggest leaving comments on what is proper in the code with a +1).   

merge request

Hint: Setup your CI server to automatically submit votes to your merge requests utilizing the API and/or JAMRb to run Jenkins builds off of your Merge Request. Authenticate with the Assembla Jenkins Auth Plugin.

If the Merge Request is merged via the “Merge and Close” button, the system will automatically merge to the target repository and the disposable branch will be deleted (if applicable). If Ignored, the disposable branch will be deleted and the Merge Request will be archived.

 

  • Deploying

Deploys should always run from origin/master unless you are doing some creative deploying where you want to test out branches in Production before merging them into origin/master (this is a highly advanced workflow and typically needs a level of coordination and architecture that most projects do not have nor can sustain as they grow). This means that origin/master should always be deployable and developers can trust that if they fork/branch or merge from origin/master it has good, Production-ready code.

 

  • Hotfixes

I mentioned that hotfixes are a bit different from regular merging workflow, well it can be true if you need to make a critical patch immediately. In this case its best to work from a branch of origin/master, even if you only have read access from origin/master this can be accomplished, since it is guaranteed to be in sync with your current Production if you always deploy origin/master. Once you have your fix in your local branch, you can push it up to your fork as a branch and create a Merge Request from fork/hotfix_X to origin/master; since you branched from origin/master you should merge directly back to it. To see how this would work in a developer fork with a remote of origin/master called orig_project and a local branch of orig_master tracking origin/master:


 $ git checkout orig_master # checkout the origin/master tracking branch on a 
remote called orig_project (not the origin of the local repository)
$ git pull # make sure it is up to date
$ git branch hotfix_ticketNum # create new branch locally
$ git push origin hotfix_ticketNum # push hotfix_ticketNum branch up to fork
remote (called origin locally)

 

Now you can create a Merge Request from fork/hotfix_ticketNum to origin/master and have Code Review before merging and then deploy to Production.

 

  • Conclusion

So that is basically how you set up a fork network in git for developers to be able to isolate their work and merge back to origin/master and from origin/master to their development fork.

To Learn more about other workflows, click here.

2 Comments Click here to read comments

Put Down Your Forks - Introducing Protected Branches

Posted by Titas Norkunas on Thu, Mar 21, 2013
  
  
Lets talk about forks. They are so awesome for open source. Why?
  • A fork is a natural way to give external contributors a place to work
  • Really, that is the main reason to fork
Look at the open source projects more closely. Only the external contributors - who are not part of the core team - work in forks. The core team members work with the main repository in branches.

A company does allow their developers to commit to the repository. A company does not want everyone to be able to merge to a release or master branch, using a fork for this is an over-complicated workaround:
  • Developers need to maintain forks
  • Additional setup to CI is required
  • Whenever a change to the repository configuration is made, it needs to be made in all forks (for instance installing a webhook)

Does it have to be so difficult? Not at all. Here is where Protected Branches are awesome and a clean solution to this problem.

A Protected Branch is a branch with limited write access. Specify members (or groups) of your team that will be able to submit code to a branch:

Protected Branches

Now, only these people will be able to push to the Master branch. Everyone else will have to contribute code through merge requests. They will be able to push to any other branch in the repo, but not Master.

Protected Branch

Protected Branches enable various common techniques - mandatory review from a senior developer, release manager that maintains release branches, feature freeze a release candidate. We have no doubt you will find even more use for it.

Sometimes you just have to leave that Social Coding aside and get some work done.

5 Comments Click here to read comments

Keep Your Codebase Maintainable - Introducing Inline Comments in Merge Requests

Posted by Titas Norkunas on Tue, Mar 19, 2013
  
  

Code Review is an essential practice for teams that want to have a Maintainable Codebase. Some teams go as far as instituting peer programming, where two developers to work on a single computer on a single piece of code. However, most of us don't have this luxury. For everyone else, we present lightweight Merge Request reviews with inline comments.

Today, after much experimentation and input from customers like you we are ready to release the fruits of our labor. Merge Request now include inline comments. Thanks go to Kivanio Barbosa and Ghislaine Guerin for their contributions.

mr inline resized 600

Includes, but not limited to:

  • Add Inline Comment by clicking the green comment icon
  • See who participates in the discussion on a specific version of a file

  • Mention people when replying - bring their attention to your Inline Comment

  • Enable Code Review notifications in stream to get emails about comments

We are listening to your feedback. Let us know how we can improve Merge Requests to suit your needs.

Learn more about Assembla Repository features here.


0 Comments Click here to read comments

Removing Web "Site" publishing to Assembla.me

Posted by Titas Norkunas on Mon, Aug 20, 2012
  
  

We are deprecating a feature in our repositories which automatically publishes the current version of of a repository to <myname>.assembla.me.  You will find this feature under the "Sites" submenu option in your repostory tool.  It's a very convenient feature, but over all time, only about 1000 people have used it.  So, we will remove it and replace it with more popular build options.  We will remove it after September 15th.

We apologize if we are causing problems for any users of this feature.  If you have concerns about this plan, please email support@assembla.com, and I will respond personally.

There are more popular options for publishing your repository content as a Web site.

1) "View as Web Page" in the code browser

If you are sharing your site with colleagues and clients, you can go to the Web browser, navigate to a Web page that you want to view, and select the "View as Web Page" button on the top.  This will render the file as a Web page in your browser. If you created the Web site with relative links, you can navigate your site in this view.  It's actually exactly the same as the site view on <myname>.assembla.me, which uses the same rendering mechanism, except that it applies permissions. You can send the "View as Web page" URL link to anyone with permission to view your repository.

2) FTP publishing to your normal Web server

We offer an FTP tool that is quite popular. This tool uses FTP to push the current version of the repository, or any historical version, to a Web server. Most commercial Web server hosts accept FTP.

3) Git publishing to free cloud services, including Heroku

You can get a small free cloud server from Amazon, or a cloud service with ability to run applications from Heroku.  Here are some instructions and links to publish on Heroku in less than half an hour. Using windows and need to set up git? Here is a handy guide.

1. Follow steps 1-3 here. Instead of diving into step 4 (which you might as well do) follow the instructions below.
2. Grab our Free git space here and clone it locally
3. Create an empty index.php and .htaccess files in the repository and add "php_flag engine off" line to .htaccess file.

touch index.php
echo 'php_flag engine off' > .htaccess

4. Move your static content to the repository and make a commit

git add .
git commit -m "First commit"

5. push to assembla, run heroku create, push to heroku

git push origin master
heroku create
git push heroku master

For more options or information, visit heroku documentation or see these blog articles about static content on Heroku with PHP and Apache,  Ruby and Rack.

It took less than half an hour to get static content up and running on Heroku. The service provides nice features, such as .htaccess and scripting in languages like PHP, Ruby, Python and more.

Here is our complete Spring Cleaning list.

1 Comments Click here to read comments

Rename Your Git Repositories How You Like

Posted by Michael Chletsos on Fri, Jul 06, 2012
  
  
Tags: ,


We just released a change to our repositories that allows you to rename your Git repositories to user specified names.  When you create your repository, it gets a name based on your space name.  If you create more repository tools, you get a similar name with a number added to it.  Well this works great for auto-generated names, but it is non-intuitive to the user.

Suppose you have a git repository called: Myspace1.git, the second tools will be Myspace1.2.git.  Your developers will have to checkout from git.assembla.com:Myspace1.git and git.assembla.com:Myspace1.2.git respectively.  Your tickets will have links in them stating Myspace.git and Myspace1.2.git respectively when you commit code:

repos before name change resized 600

This is non-intuitive and could take a moment to decide what is the proper repository this code came from.  Not to mention QA and other team members might have no idea what Myspace1.2.git is referencing.  But by renaming the repository, it becomes much easier to use:

repos after name change resized 600

Here we renamed the first repo to "origin" and the second repo to "Design_Team."  Now the tickets clearly displays which repository is which without having to remember all those numbers.

In order to make this change, you will have to go to the Settings for your repository and update the Repo Name box:

repo settings resized 600

We also suggest that you update the Title to the same name as the Repo Name, though this is not required, it makes it much easier to recognize your repository.

One word of caution, all clients will need to update their git configuration settings to the new repo url after this change.  Otherwise they will not be able to pull or push from your repository.

7 Comments Click here to read comments

Deprecating Trac and Moving to Integrated Tools

Posted by Michael Chletsos on Wed, Jun 20, 2012
  
  

We have stopped offering Trac for new spaces.  We strongly recommend that new users and projects adopt Assembla Tickets with svn or git. We built the integrated Assembla tools as an upgrade to Trac more three years ago.  Now, we will focus on improving the quality of the newer Assembla features.

We will continue to support our existing Trac users with reliable service.  Some of those existing Trac users have been with us for many years.  When we first launched Assembla.com, we wrapped some on-demand features around Trac.  This started as a side project for us that I think was the best on-demand Trac hosting, and eventually attracted more than 100K users.  Now, dozens of vendors provide Trac hosting, and Assembla is no longer the best Trac host.  During the last nine years the Trac Project has helped tens of thousands of teams "write great software while staying out of the way."  We are grateful to the developers, including founders Daniel Lundin and Jonas Borgström, for bringing us this software.

Assembla has outgrown Trac.  We built our own Tickets and Source/repo tools to get better features, integration, localization, multi-tenancy, and spam protection.

Current users of Trac/hg and Trac/git may continue to use these tools for a limited time.  We will no longer offer Trac/hg, Trac/git, and Trac/svn for new installations. We will remove the Trac/hg and the Trac/git tools in the coming months, providing ample time to migrate out of these tools. Trac/svn is very popular at Assembla.  We will maintain it as long as we need to maintain it for existing users.

We highly encourage all users of these tools to switch over to our integrated code browser and ticketing tool.  For more information on migrating from Trac Tool to Tickets Tool, please read Migrating from Trac to Assembla Tickets

We hope that you will find that by removing some tools we are able to deliver a better core product.  If you have any questions or want help migrating to our integrated tools - please contact support (support@assembla.com).

9 Comments Click here to read comments

All Posts | Next Page

Follow Assembla

twitter facebook youtube linkedin googleplus

Subscribe by Email

Your email: