Category: Agile

Categories
.Net Agile General

Last Deployment of 2017


Yesterday we completed our last deployment of 2017. Web sites, WCF services, Web Api, Windows Services, and a PowerBuilder app were deployed without major issues. Our sprints run for 2 weeks and we tried to deploy at least once a month.

In this post, I want to share some of the tools we use at MDBuyline to ship high quality software.

Atlassian Jira
Our business analysts meet with our internal users on a regular basis. Sometimes these conversations take place informally during lunch or when they meet at the hall. The conversation goes something like this: “hey Bob, how are you? By the way, I wanted to show you an issue that I’m having with our website.” During these conversations, our analysts will gather enough information to create a user story. Bob will login to Jira and provide a brief description of the issue or feature request. The more information they provide the better. Adding visual aids also helps developers understand these stories better.

These stories will go to a backlog. Every other week we (developers and BA) will meet to go over these stories and also to set priorities for our next sprint. Currently we are in Sprint 47 and it will end next Thursday. Our sprints are 2 weeks long. We also have a scrum master that helps the team manage stories, priorities and deadlines.

Continuous Integration

We currently use subversion for our source control but will be migrating to git soon. Before we start working on a new story, we create a new branch based on the latest change of trunk (master in git). To continuous build our projects, we use Jenkins to handle our .NET builds and also our deployments. All of our projects have a Jenkins job that is set to build against the trunk version. The hassle with working with branches is that we have to ask our team lead to add a new Jenkins job and point it to our new branch. Hopefully with out Git migration, these setup will be handle automatically.

Continuous Deployment

After Jenkins completes building our projects, we use different PowerShell scripts to deploy web sites and web services to the right environment. We have 3 environments: dev, test, and prod. Let me give you an example so this becomes clear. Let’s say that we have a .NET website and it needs to be setup with Jenkins. Our team lead will add a new Jenkins job and set it up with subversion authentication, msbuild arguments, and PowerShell scripts. This job is build against the trunk version. Since we have to create a branch, our team lead will create a new Jenkins job based on the job that points to trunk. After creating the new job, the team lead will modify the url to point to the branch instead of the trunk url. At this point, we should be able to trigger a build and create artifacts. To move these artifacts from our Jenkins server to the correct environment, we use PowerShell scripts to copy files from Jenkins to server dev-win for example.

Summary

This year is coming to an end. For me personally, it has been a great year adding new features to our software products. Our production environment is in great shape since we ship high quality code. Jira helps us create sprints with the right items to work on. Jenkins helps us with our continuous integration. PowerShell scripts deploy our software efficiently and in a timely manner.

 

Categories
.Net Agile code review

Benefits of Performing Code Reviews

The only constant is change. In 2015, we did not have a formal code review process. However in 2016, we decided to change how we build software. Reliable software. Now we have introduced a formal code review process. In a nutshell, we have to pull down the subversion branch or branches and review each revision. The review process also involves compiling code, running unit tests, and trying to break the code. With this in mind, I wanted to share the benefits of performing code reviews.

Reduce Bugs

While performing code reviews for a year, we have concluded that bugs have been reduced significantly. The developer looking at the code changes is wearing a quality analyst hat during this time. If the code review is done correctly, he or she should find bugs. Sometimes it is a simple misspelled word, other times code won’t compile, or a unit tests fails. Many studies have found that finding bugs during development is less expensive than finding the same bug in production. If we encounter a bug six months from now, the developer will have to spend more time understanding the bug and trying to come up with a feasible solution.

Get Familiar with Code

Many times we have to review code that we have never seen. This is a great opportunity to learn about it. Sit down with the developer and ask questions. In our team, we have a developer who is in charge of applications written with PowerBuilder. He asked me to review his code and we sat down together to complete this important step in our development process. Most of our applications are written with .Net but having the knowledge of the PowerBuilder applications allow us to get familiar with all of our applications. Don’t be afraid to learn something new.

Learn New Tips and Tricks

Recently we had the opportunity to use PostgreSQL within a .Net application. Our team spent a lot time looking at syntax because it was our first time using PostgreSQL. One of the things we had to figure out was how to set the primary key. At the beginning we created sequences and it was a 2 step process. However when I had to do a peer review, I did not see a sequence created but a serial. Using serial was much simpler and the team liked the simplicity of using serial vs sequence. We also learn new tips when reviewing code together. Developer and reviewer sitting next to each other discussing code changes. Many times we picked keyboard shortcuts and tricks that improved how we built software.

Keep Code Consistent

If you look at our code base, it looks like the same developer wrote it. It contains the same architecture. It uses the same naming convention. Having a formal peer review process has allowed our team to keep the code consistent. This also helps new developers jump right into our code and be productive. The new developer does not have to learn 3 or 4 different architectures.

There are many benefits in doing code reviews. In our experience, we have seen the number of bugs reduced because bugs were found during development. Our developers were able to fix the bugs while we were in development. We have also be able to keep a consistent code base with the same architecture.

 

Categories
Agile

It is crucial to be agile

agile

Agile is defined as able to move quickly and easily. When we apply this definition to software development, we can see the benefits of delivering software quickly and easily. Being agile helps you release software sooner rather than later.

How to move quickly in software development?

When I worked at Ristken, we had 1 week sprints and daily scrum meetings. This setup allowed us to release software features quickly to our customers. After our customers started using the new features, we received valuable feedback. This feedback enabled us to modify software quickly and easily.

At Verizon, we had a longer sprint. In average they ranged from 3 to 4 weeks. In my opinion, we delivered great software but our feedback loop was longer.

As a general rule, smaller teams are more agile than bigger teams. This might be related to communication and logistics. It is easier to communicate with 1 person in comparison to 10. Scott Hanselman said that at the beginning of his career at Microsoft, getting things done was like moving the Titanic. Change is happening but it’s slowly happening.

How do we move easily in software development?

I think having scrum meetings everyday is crucial when it comes to “move easily”. Usually the scrum master would say at the end of the meeting “any road blocks or impediments”. The sooner we removed those road blocks, the better.

Open communication is very important here. Are you encourage to communicate problems? Do you have the resources needed to remove problems? Are you willing to solve your own problems? Having a work environment that removes obstacles quickly and encourages employees to solve problems will help you move easily and create quality software.

We can see how agile plays a key role when it comes to mobile apps. The most popular apps release software quickly. The app owners read comments and ratings so that they can fix bugs or add new features. It is in their best interest to keep their customers happy.

Conclusion

Moving quickly and easily in software development allows your team to deliver quality software applications. The end user (customer) plays a key role since their feedback allows us (developers) to improve our software applications.